| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-19 | |||
| 17:33:09 | dansmith | and that's not where cloud-init is looking, correct? | |
| 17:33:31 | sean-k-mooney | not sure about that last bit i think its looking for FQDN as a sibling of meta | |
| 17:33:36 | sean-k-mooney | but not sure | |
| 17:33:44 | dansmith | oh okay good | |
| 17:33:49 | sean-k-mooney | hostname is at the same level | |
| 17:34:01 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L349= | |
| 17:35:36 | sean-k-mooney | vm is booting now we will know shortly | |
| 17:40:26 | sean-k-mooney | ubuntu@meta-test:~$ sudo cat /var/lib/cloud/data/set-hostname | |
| 17:40:29 | sean-k-mooney | { | |
| 17:40:31 | sean-k-mooney | "fqdn": "meta-test", | |
| 17:40:33 | sean-k-mooney | "hostname": "meta-test" | |
| 17:40:35 | sean-k-mooney | } | |
| 17:40:50 | sean-k-mooney | what the special adress again ill see what in teh api with curl | |
| 17:41:21 | sean-k-mooney | 169.254.169.254 perhaps | |
| 17:42:54 | sean-k-mooney | odd im not seeing it where i expect too | |
| 17:44:39 | sean-k-mooney | https://termbin.com/n7bk | |
| 17:44:47 | sean-k-mooney | so its set on the instance | |
| 17:44:55 | sean-k-mooney | but i dont se fqdu anywhere | |
| 17:45:36 | sean-k-mooney | isnte server metadata ment to be discoverabel via the metadtaa api endpoing | |
| 17:45:52 | sean-k-mooney | im expecting to see it somewhere under curl 169.254.169.254/latest/meta-data | |
| 17:52:54 | sean-k-mooney | so that would be a no | |
| 17:53:23 | sean-k-mooney | unless im missing somthing im not sing where we expose the userdata or metadata at that url | |
| 17:54:30 | dansmith | sean-k-mooney: https://github.com/openstack/nova/blob/c53ec4e48884235566962bc934cbf292ad5b67b8/nova/api/metadata/base.py#L317-L318 | |
| 17:55:10 | dansmith | launch_metadata comes from utils.instance_meta() which should be the user's k=v metadata they provided | |
| 17:56:45 | sean-k-mooney | yes and we regeister that fucntion as a path handeler here https://github.com/openstack/nova/blob/c53ec4e48884235566962bc934cbf292ad5b67b8/nova/api/metadata/base.py#L221= | |
| 17:57:07 | sean-k-mooney | so with meta_data.json" as the route | |
| 17:57:10 | sean-k-mooney | ill check that | |
| 18:00:42 | sean-k-mooney | so the instance metadta is not part of the ec2 info https://github.com/openstack/nova/blob/c53ec4e48884235566962bc934cbf292ad5b67b8/nova/api/metadata/base.py#L235-L303= | |
| 18:04:31 | sean-k-mooney | im not really sure what to say to be honest | |
| 18:08:59 | sean-k-mooney | ok its there | |
| 18:09:08 | sean-k-mooney | not that i can find via curl but | |
| 18:09:28 | sean-k-mooney | cloud-init query -a sees it | |
| 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. | |