| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-03 | |||
| 17:09:37 | gibi | ^^ +1 | |
| 17:10:02 | sean-k-mooney | do we need a workaround flag for this | |
| 17:10:05 | sean-k-mooney | for the backports | |
| 17:10:05 | artom | Random idea | |
| 17:10:13 | bauzas | (but again, from an ops pov (well from the last decade), I just feel that naming your server with 'x.y' is either very smart or totally crazy | |
| 17:10:18 | artom | You can set the port's dns_name "manually" via the Neutron API | |
| 17:10:23 | bauzas | sean-k-mooney: NO | |
| 17:10:34 | artom | So... why not just stop doing it automagically when Nova creates/updates the port? | |
| 17:10:37 | sean-k-mooney | bauzas: ok | |
| 17:10:50 | artom | And let people pick their own hostname that way | |
| 17:10:53 | sean-k-mooney | artom: only with designate | |
| 17:10:59 | bauzas | yeah | |
| 17:11:07 | sean-k-mooney | well or a vey new extenion i think | |
| 17:11:07 | artom | sean-k-mooney, not based on https://docs.openstack.org/api-ref/network/v2/index.html?expanded=update-port-detail,show-port-details-detail#update-port | |
| 17:11:09 | sean-k-mooney | ill check | |
| 17:11:21 | bauzas | and that's exactly why I think that nova shouldn't deal with TLDs in their server hostnames | |
| 17:11:35 | artom | Like, the original BZ we have is because Neutron exploded | |
| 17:11:38 | artom | Not Designate | |
| 17:11:53 | bauzas | but I can recognize that the dash conversion seems kinda more acceptable to users | |
| 17:12:48 | bauzas | anyway, /me needs to bail out | |
| 17:12:51 | bauzas | ++ | |
| 17:13:07 | gibi | o/ | |
| 17:13:19 | stephenfin | o/ | |
| 17:13:46 | sean-k-mooney | artom: im pretty sure nova used to explode at one point too with some of the shared nova net code | |
| 17:14:02 | sean-k-mooney | artom: the orginal bz was in my dev cloud in intel | |
| 17:14:18 | artom | sean-k-mooney, bz or launchpad bug? | |
| 17:14:20 | sean-k-mooney | it was filed by someone on my team after i told them it was never supported | |
| 17:14:27 | sean-k-mooney | sorry the launch pad bug | |
| 17:14:44 | artom | Well, nova-network doesn't exist anymore, so... :) | |
| 17:16:09 | sean-k-mooney | i think it used to explode somewhere in https://github.com/openstack/nova/blob/stable/train/nova/network/minidns.py | |
| 17:17:27 | sean-k-mooney | this si where we are current failing right https://github.com/openstack/nova/blob/stable/train/nova/network/neutronv2/api.py#L678-L686 | |
| 17:20:03 | artom | sean-k-mooney, no, based on https://bugzilla.redhat.com/show_bug.cgi?id=1872314 we actually make the request to Neutron | |
| 17:20:03 | openstack | bugzilla.redhat.com bug 1872314 in openstack-nova "[OSP 16.1] Can't launch instance if name ends with a number" [Medium,New] - Assigned to nova-maint | |
| 17:20:14 | artom | And bubble up the BadRequest it returns | |
| 17:20:36 | sean-k-mooney | artom: oh i know | |
| 17:21:03 | sean-k-mooney | but back in like havana i think it broken in nova it also broke in neutorn | |
| 17:21:16 | sean-k-mooney | at somepoint neutron started allowing the fqdn | |
| 17:21:35 | sean-k-mooney | but it was never done intentually at least form a nova point of view | |
| 17:22:35 | artom | So https://github.com/openstack/nova/blob/stable/train/nova/network/neutronv2/api.py#L1138 would be where our request to Neutron explodes | |
| 17:23:02 | artom | And https://github.com/openstack/nova/blob/stable/train/nova/network/neutronv2/api.py#L1494 is where we populate the dns_name | |
| 17:23:18 | artom | I'm saying don't actually do that | |
| 17:23:40 | artom | And let the users do a port update manually with the hostname of their chosing, not one that Nova has derived from the VM name | |
| 17:25:05 | artom | And *then* if Neutron isn't happy, it really is user error and WONTFIX :) | |
| 17:27:57 | sean-k-mooney | artom: that wont fix the fact the contend ot the metadata api is not what you expect | |
| 17:28:12 | artom | sean-k-mooney, eh? | |
| 17:28:32 | sean-k-mooney | look at http://lists.openstack.org/pipermail/openstack-discuss/2020-November/019137.html | |
| 17:29:05 | sean-k-mooney | with a default designate domain of cloud.seanmooney.info adn default dhcp_domain of novalocal | |
| 17:29:22 | sean-k-mooney | fi you create a server called test-dns.invalid.dns | |
| 17:30:49 | sean-k-mooney | you will have "test-dns.invalid.dns.novalocal" "test-dns.invalid.dns.cloud.seanmooney.info" "test-dns.cloud.seanmooney.info" and test-dns for hostnames/fqdns | |
| 17:31:14 | sean-k-mooney | but you will never have test-dns.invalid.dns which was the fqdn you uses as the servername | |
| 17:31:17 | artom | sean-k-mooney, I feel like we're conflating many problems into 1 | |
| 17:31:38 | sean-k-mooney | not really | |
| 17:31:58 | sean-k-mooney | if we allow FQDNs we shoudl support them consitently | |
| 17:32:17 | sean-k-mooney | right now you will get 4 possible name for the server none of them will be the one you passed in unless | |
| 17:32:59 | sean-k-mooney | you explcity configure [DEFAULT]/dhcp_domain="" and do not use a default designate domain | |
| 17:33:55 | artom | sean-k-mooney, right, this falls in the wider "our DNS interoperation is crap" problem | |
| 17:34:02 | artom | On which my grip is not great | |
| 17:34:21 | artom | But feels like fixing that would involve a new microversion with a separate hostname and/or fqdn parameter | |
| 17:35:18 | artom | At the tightest possible scope, this bug is caused by Nova deriving a `dns_name` from the display name, and passing it to Neutron, which can then refuse it, despite the display name being perfectly valid | |
| 17:36:03 | sean-k-mooney | if you want real fun read https://review.opendev.org/c/openstack/neutron-specs/+/88623/16/specs/liberty/internal-dns-resolution.rst | |
| 17:36:19 | artom | If I want real fun I'll go do some drugs | |
| 17:36:50 | sean-k-mooney | https://bugs.launchpad.net/neutron/+bug/1459030 | |
| 17:36:50 | openstack | Launchpad bug 1459030 in neutron "Allow nova to feed its hostname to Neutron for eventually integration with Designate" [Medium,Fix released] - Assigned to Miguel Lavalle (minsel) | |
| 17:38:20 | artom | I wonder if anyone's asked PSI whether they actually need the DNS integration :P | |
| 17:38:49 | sean-k-mooney | its quite useful | |
| 17:38:55 | sean-k-mooney | its why i use it | |
| 17:39:11 | sean-k-mooney | but its also not well maintained | |
| 17:39:25 | sean-k-mooney | or rather a very small team | |
| 17:40:09 | sean-k-mooney | no that i have moved my dns to cloudflare most of my issue with updating dns are fixed | |
| 17:40:22 | sean-k-mooney | godda's ui/api was horrible | |
| 17:44:28 | sean-k-mooney | by the way aparet form the backportable solution stephenfin are we also going to add an fqdn or domain field and a new microverion to the server create | |
| 23:11:00 | openstackgerrit | Mamduh proposed openstack/os-vif stable/ussuri: Refactor code of linux_net to more cleaner and increase performace https://review.opendev.org/c/openstack/os-vif/+/765419 | |
| #openstack-nova - 2020-12-04 | |||
| 00:44:59 | openstackgerrit | melanie witt proposed openstack/nova master: Omit resource inventories from placement update if zero https://review.opendev.org/c/openstack/nova/+/759348 | |
| 01:33:16 | brinzhang | gmann: hi, I saw your comments in https://review.opendev.org/c/openstack/nova/+/765315/1 | |
| 01:33:33 | brinzhang | gmann: I think this change is ok, right? | |
| 01:34:25 | brinzhang | of course, I will update your comments, and adding the needed test cases | |
| 01:46:48 | gmann | brinzhang: +1. also we can do all the policy changes in one patch i added other policy also where changes are required | |
| 01:48:28 | gmann | brinzhang: also if you can squash these two 764292 and 765311. having one patch per API will be good and less error prone to review instead of separate patches for request and response change | |
| 01:49:51 | gmann | brinzhang: and on microversion number, stephenfin hypervisor API changes are mre close to merge for 2.88 - https://review.opendev.org/c/openstack/nova/+/764040 | |
| 01:50:18 | brinzhang | gmann: I have already serepate 764292 and 765311, I wonot waste time to merge, the policy changes I just see this api now, if I changes other api that need to be change the policies, I will be add in this patch | |
| 01:50:31 | gmann | brinzhang: if you can use 2.89 then it will be less work for you on rebase things because stephenfin changes are more likely yo be merge before tenant-id one | |
| 01:51:05 | gmann | brinzhang: i mean do these into single one - 764292 and 765311 | |
| 01:51:32 | gmann | otherwise it is hard to review what all things you are taking care or missed unless we check other patches too. | |
| 01:51:51 | brinzhang | gmann: I also would like merge noVNC feature before remove tenant_id, this patch seems too big | |
| 01:52:12 | gmann | this happened to me when I reviewed 764292 and gave comment on missing request body change and then found it is done separately | |
| 01:52:41 | gmann | brinzhang: +1 then you can do 2.90 for tenand-id. i can review noVNC also once you are ready | |
| 01:53:09 | brinzhang | gmann: noVNC patch is ready now, and I added in the runway, you can review | |
| 01:53:14 | gmann | tenand-id changes are huge and we need to carefully review those to avoid regressions as it involve lot of request/responsechanges | |
| 01:53:19 | gmann | brinzhang: cool | |
| 01:53:25 | gmann | brinzhang: will do tomorrow | |
| 01:54:21 | brinzhang | gmann:764292 and 765311 these are two things, 764292 do remove tenant_id and add project_id, 765311 just replace all_projects with all_tenants, it's easy to review | |
| 01:54:58 | brinzhang | gmann: I am appreciate you can review the noVNC patch, thanks | |
| 01:56:17 | gmann | brinzhang: its for one API GET /servers. my point is to divide the changes of 'remove/replace tenant->project' per API. if we do per parameter then it will be very long series and chance to miss the things unless we check all the changes and find all things covered for that API | |
| 01:58:19 | brinzhang | gmann: yeah, if I have time to combine these that I can | |
| 01:58:29 | gmann | brinzhang: thanks. | |
| 01:59:25 | brinzhang | gmann: indeed, I do my plan in my mindmaster, I dont want to break my plan | |
| 01:59:34 | brinzhang | s/do/did | |
| 02:23:32 | brinzhang | gmann: the lock server reason is not required? | |
| 02:23:34 | brinzhang | nova.tests.functional.api_samples_test_base.NoMatch: Dictionary key mismatch: | |
| 02:23:34 | brinzhang | Extra key(s) in template: | |