| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-19 | |||
| 18:37:45 | sean-k-mooney | this is all based on aws by the way | |
| 18:37:50 | sean-k-mooney | the example | |
| 18:38:03 | sean-k-mooney | and they have obviouly changed there mind over time | |
| 18:38:10 | johnsom | dansmith I am 100% on board with allowing fqdn in the hostname field and just pass it to cloud-init to deal with. That would solve the problem a customer was having. If there is an issue with neutron, that should be easily fixable. | |
| 18:38:41 | dansmith | johnsom: agree | |
| 18:38:44 | sean-k-mooney | johnsom: that customer issue is why we are talking about this | |
| 18:39:01 | johnsom | Yeah, I guessed as much | |
| 18:39:11 | sean-k-mooney | we had the option of doing that in wallaby and agreed to add the display name sanatiation | |
| 18:39:37 | sean-k-mooney | we aslo had a mailing list thread on this topic | |
| 18:40:09 | sean-k-mooney | so we cloud just allow fwdns again and strip or pass the domain when talking to neutron | |
| 18:40:36 | sean-k-mooney | our consern with that is we have shipted the normaliasation for 3 releases now | |
| 18:40:41 | dansmith | no | |
| 18:40:43 | sean-k-mooney | so we dont knwo who we will break | |
| 18:40:48 | dansmith | we should not parse the hostname and split out domains | |
| 18:41:05 | sean-k-mooney | dansmith: so neutron should? | |
| 18:41:07 | dansmith | we should take that string, pass it to cloud-init and/or neutron, and fix whatever the problem is on the neutron side that didn't like it sometimes | |
| 18:41:16 | dansmith | sean-k-mooney: neutron is the networking service | |
| 18:41:26 | johnsom | dansmith +1 | |
| 18:41:36 | sean-k-mooney | right but we are curently setting the dns_name filed in there api | |
| 18:41:44 | sean-k-mooney | to an fqdn when its defiend to take a hostname | |
| 18:42:10 | sean-k-mooney | https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/releasenotes/notes/instance-hostname-used-to-populate-ports-dns-name-08341ec73dc076c0.yaml | |
| 18:42:26 | dansmith | I really think the right thing is for us to take a hostname and get our domain affiliation from neutron, but if we really really need to be able to take an FQDN via nova, we should be as hands-off about it as possible | |
| 18:43:23 | sean-k-mooney | well right now the hostname filed can only be a hostname if passed driectly | |
| 18:43:35 | johnsom | It is common case that the FQDN in the guest does not match the FQDN on the port in neutron. One is an internal view, the other external. | |
| 18:43:36 | sean-k-mooney | if its not passed we generate it form the dispalyname | |
| 18:44:09 | sean-k-mooney | johnsom: sure but the customer in quetion needs it to be resolvable | |
| 18:44:28 | sean-k-mooney | so what ever gets set need to actully reslove in nutrons dns | |
| 18:44:30 | opendevreview | Balazs Gibizer proposed openstack/nova master: Rename [pci]passthrough_whitelist to device_spec https://review.opendev.org/c/openstack/nova/+/843834 | |
| 18:44:30 | opendevreview | Balazs Gibizer proposed openstack/nova master: Rename exception.PciConfigInvalidWhitelist to PciConfigInvalidSpec https://review.opendev.org/c/openstack/nova/+/843861 | |
| 18:44:31 | opendevreview | Balazs Gibizer proposed openstack/nova master: Rename whitelist in tests https://review.opendev.org/c/openstack/nova/+/843862 | |
| 18:44:31 | opendevreview | Balazs Gibizer proposed openstack/nova master: Basics for PCI Placement reporting https://review.opendev.org/c/openstack/nova/+/846187 | |
| 18:44:32 | opendevreview | Balazs Gibizer proposed openstack/nova master: Extend device_spec with resource_class and traits https://review.opendev.org/c/openstack/nova/+/846218 | |
| 18:44:32 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reject PCI dependent device config https://review.opendev.org/c/openstack/nova/+/846435 | |
| 18:44:33 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reject mixed VF rc and trait config https://review.opendev.org/c/openstack/nova/+/846436 | |
| 18:44:34 | opendevreview | Balazs Gibizer proposed openstack/nova master: Ignore PCI devs with physical_network tag https://review.opendev.org/c/openstack/nova/+/846219 | |
| 18:44:34 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reject devname based device_spec config https://review.opendev.org/c/openstack/nova/+/846466 | |
| 18:44:36 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support [pci]device_spec reconfiguration https://review.opendev.org/c/openstack/nova/+/846470 | |
| 18:44:36 | opendevreview | Balazs Gibizer proposed openstack/nova master: Stop if tracking is disable after it was enabled before https://review.opendev.org/c/openstack/nova/+/847009 | |
| 18:44:50 | dansmith | johnsom: I think that's a broken way to think about it in a managed environment, which is why I think you should choose one port to be your primary interface and we get our domain affiliation from that | |
| 18:45:26 | sean-k-mooney | dansmith: perhaps but in general ports and neworks dont have domains | |
| 18:45:30 | sean-k-mooney | they do in the custoemrs case | |
| 18:45:36 | sean-k-mooney | they define them on the network | |
| 18:45:40 | dansmith | but I understand there's practicalities about where we are at the moment, so I'd rather just pass the hostname to the other services and let them handle what to do if it looks like an fqdn | |
| 18:45:51 | sean-k-mooney | and they are expecting the domain to propacate down to all vms on that network | |
| 18:46:16 | dansmith | sean-k-mooney: again, I'm not talking about absolutes about how neutron works today, I'm saying what I think about the way it *should* work | |
| 18:46:24 | sean-k-mooney | dansmith: to make that work both neutron and designate would need to be able to handel that | |
| 18:47:08 | dansmith | sean-k-mooney: I understand | |
| 18:47:22 | johnsom | dansmith Think about the case where the domain is cloud generated based on the project ID, etc. The in-guest name doesn't necessarily need to be resolvable from outside the guest. It can be, but it's not necessary. | |
| 18:48:17 | sean-k-mooney | johnsom: in there paticaly case it needs to be but in general it may not | |
| 18:48:27 | sean-k-mooney | https://github.com/openstack/nova/blob/93a65f06df67ce39d65827692150c78013c7f6d5/nova/network/neutron.py#L1737= | |
| 18:48:37 | sean-k-mooney | this is where we set the dns_name on the port by the way | |
| 18:48:59 | sean-k-mooney | if that just truncated the hostname neutron and designate woudl work | |
| 18:49:49 | sean-k-mooney | we are sanatising the hostname to workaround that bad request form neutron today | |
| 18:49:52 | johnsom | Yep, just split on the first label | |
| 18:52:06 | sean-k-mooney | so we could revert the normalisation we do right now when setting instance.hostname and truncate there and all uscases that work before wallaby would work again however the downstide of that is if your vm is called ubuntu-20.04 in neutron it will have ubuntu-20 set as the domain name | |
| 18:52:09 | dansmith | johnsom: I know, in the most generic cloud case it would also be something other than your own domain. It just seems like we've got all this overly-complex plumbing of networks now, so we should be able to actually manage network things via the network :) | |
| 18:52:15 | sean-k-mooney | and to make that worse it breaks multi create in that casse | |
| 18:52:35 | dansmith | sean-k-mooney: I really don't think we should be normalizing or truncating or splitting the hostname in nova | |
| 18:52:46 | dansmith | perhaps checking that it's a valid hostname (*maybe*) | |
| 18:52:52 | dansmith | but let the other services deal with it | |
| 18:53:13 | sean-k-mooney | dansmith: well we have been since before essexe | |
| 18:53:27 | sean-k-mooney | there was exsitng code that removed unicode | |
| 18:53:29 | dansmith | sean-k-mooney: and look at where we're at :) | |
| 18:53:35 | sean-k-mooney | and some other sepcial charters | |
| 18:53:49 | sean-k-mooney | so just sayign if we revert this it will still exits | |
| 18:54:03 | sean-k-mooney | dansmith: im not disagreeing that its undeisreable | |
| 18:54:07 | dansmith | again, checking for sanity is not such a big deal, but I'd think we'd want to reject the instance boot, not just sanitize-and-go | |
| 18:54:28 | sean-k-mooney | dansmith: that was also something we discuseed | |
| 18:54:40 | sean-k-mooney | psi was unhappy with that proposal | |
| 18:54:54 | sean-k-mooney | but i think that was our first responce | |
| 18:55:08 | sean-k-mooney | "this is invalide sorry neturon told us so" | |
| 18:56:37 | sean-k-mooney | i dont recall all the details but with queens and without designate vms with numeric TLDs booted | |
| 18:56:45 | sean-k-mooney | and with train and designate it did not | |
| 18:57:49 | sean-k-mooney | nova has been seeting the dns_name form instance.hostname since mitaka | |
| 18:57:58 | dansmith | we have friends that work on designate right? :) | |
| 18:58:03 | sean-k-mooney | so that was either a change in neutron or caused by adding designate | |
| 18:58:06 | johnsom | grin | |
| 18:58:10 | johnsom | You do.... | |
| 18:58:19 | sean-k-mooney | pluarl? | |
| 18:58:26 | dansmith | sean-k-mooney: johnsom is worth at least two | |
| 18:58:31 | sean-k-mooney | :) | |
| 18:58:32 | johnsom | lol | |
| 18:58:50 | dansmith | johnsom: that was a comment of your worth, not your waistline, btw ;P | |
| 18:58:53 | sean-k-mooney | i just tought designate was one of the more understaffed project | |
| 18:59:09 | sean-k-mooney | i think this vlaidation change was in neutron to be honest | |
| 18:59:22 | sean-k-mooney | between train and queens | |
| 18:59:29 | johnsom | There are two full time RH folks, and a couple more cores active. | |
| 18:59:45 | sean-k-mooney | oh ok glad that has improved | |
| 19:00:28 | johnsom | But, as dansmith said, the Designate buck stops with me at the moment, so if we need to fix something on the designate side, assign the bug to me. | |
| 19:02:22 | sean-k-mooney | https://github.com/openstack/neutron-lib/blob/f01b2e9025d33aeff3bf22ea2568bda036878819/neutron_lib/api/validators/dns.py#L59-L92= | |
| 19:02:33 | sean-k-mooney | so that apprently is what does the validation in neutron | |
| 19:03:32 | sean-k-mooney | well it starts here https://github.com/openstack/neutron-lib/blob/f01b2e9025d33aeff3bf22ea2568bda036878819/neutron_lib/api/validators/dns.py#L112= | |
| 19:03:46 | dansmith | I just had to: https://imgur.com/a/spREDAg | |
| 19:04:07 | johnsom | lol | |
| 19:04:24 | johnsom | At least it's a $100 | |
| 19:04:41 | dansmith | inflation, yo | |
| 19:05:34 | sean-k-mooney | https://github.com/openstack/neutron-lib/blob/f01b2e9025d33aeff3bf22ea2568bda036878819/neutron_lib/api/validators/dns.py#L50-L52= | |
| 19:05:44 | sean-k-mooney | that is what was rejecting the numeric tlds | |
| 19:06:32 | sean-k-mooney | and that has been in place since pike | |
| 19:06:51 | sean-k-mooney | so the psi issue was caused by turning on the dns extention | |