| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-19 | |||
| 18:09:32 | sean-k-mooney | its in the meta section | |
| 18:09:53 | sean-k-mooney | https://paste.opendev.org/show/bfDEteTetI0rInj8NfBx/ | |
| 18:11:27 | sean-k-mooney | line 57-60 | |
| 18:15:43 | sean-k-mooney | oh its at http://169.254.169.254/openstack/2012-08-10/meta_data.json | |
| 18:16:14 | sean-k-mooney | curl http://169.254.169.254 does not list the openstack directory | |
| 18:16:43 | sean-k-mooney | so that makes sense without openstack im looking at the ec2 part | |
| 18:21:05 | sean-k-mooney | dansmith: https://termbin.com/cxty that is the metadta we generated for that instnace | |
| 18:21:41 | dansmith | that's what I would expect, yeah, | |
| 18:21:53 | dansmith | so does cloud-init look at that meta['fqdn'] properly? | |
| 18:22:02 | sean-k-mooney | no | |
| 18:22:13 | sean-k-mooney | it could but it does not appear too | |
| 18:22:18 | sean-k-mooney | so the openstack data souce could be updated | |
| 18:22:21 | dansmith | could or should? | |
| 18:22:29 | sean-k-mooney | to make keys under meta have precidence | |
| 18:22:38 | sean-k-mooney | could, im not sure it should or not | |
| 18:23:36 | sean-k-mooney | or well we could implement atht too allow keys to be "un namespaced" i.e. not embeded in the metakey | |
| 18:24:00 | sean-k-mooney | asuming the hostname filed there has precinece over the ec2 version | |
| 18:24:01 | dansmith | we really *really* should avoid nova making any contract about the keys in user metadata | |
| 18:24:04 | sean-k-mooney | which im not sure it does | |
| 18:24:18 | dansmith | if it's something cloud-init looks at, then fine, but we should not be touching that stuff | |
| 18:24:30 | sean-k-mooney | ack | |
| 18:25:16 | dansmith | well, still, it seems to me that hostname should be the short part and we should get domain from some primary network affiliation | |
| 18:25:52 | sean-k-mooney | well i belvie they put fqdns in it sometime in the examples | |
| 18:27:10 | dansmith | so remind me again why the user can't just use an fqdn in the hostname field and we just look the other way? | |
| 18:27:59 | sean-k-mooney | it broke desginate | |
| 18:28:01 | sean-k-mooney | or neutron | |
| 18:28:07 | sean-k-mooney | because we passed that directly too them | |
| 18:28:20 | sean-k-mooney | if the hostname hand a numeric tld | |
| 18:28:27 | sean-k-mooney | so ubuntu-20.04 | |
| 18:28:34 | sean-k-mooney | would break neutron | |
| 18:28:45 | sean-k-mooney | because we set the dns_name to that | |
| 18:32:19 | sean-k-mooney | dansmith: https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#example-output was the example i was refering too | |
| 18:33:54 | dansmith | they do show hostname having an FQDN, even though it's a . internal one | |
| 18:34:25 | dansmith | but it also shows the public real hostnames being more associated with interfaces, which seems more right-er to me | |
| 18:34:34 | sean-k-mooney | yep "public_hostname": "ec2-3-89-187-177.compute-1.amazonaws.com", | |
| 18:34:52 | sean-k-mooney | if you look at v1 the hsotnaem was truncated | |
| 18:35:47 | sean-k-mooney | then the top level "local_hostname": "ip-172-31-81-43", is still truncated | |
| 18:36:00 | sean-k-mooney | but hostname is now "hostname": "ip-172-31-81-43.ec2.internal", | |
| 18:36:12 | sean-k-mooney | and they have per network interface info | |
| 18:36:22 | sean-k-mooney | dansmith: the other spec which we abandoned | |
| 18:36:32 | sean-k-mooney | was adding the per networking interface info | |
| 18:36:58 | sean-k-mooney | since that would allow us to pass all the inform form neutron | |
| 18:37:02 | sean-k-mooney | and just get out of thet way | |
| 18:37:08 | sean-k-mooney | but apprenly cloud init wont use that | |
| 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 :) | |