| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-19 | |||
| 17:15:18 | dansmith | johnsom: we're talking about providing some way to say that the former should be set from the latter according to some rule, like "take the first one" or "this one is my primary" | |
| 17:15:18 | bauzas | hostnames are host names | |
| 17:15:26 | johnsom | Yeah, I'm not talking for Nova. Just the kernel UTC | |
| 17:15:29 | bauzas | hostnames aren't FQDNs in Nova | |
| 17:15:47 | dansmith | instead of nova taking a hostname that we set in the guest | |
| 17:16:11 | sean-k-mooney | johnsom: form a kernel UTC perstive the validat of FQDN as a hostname depend on what distro you ask | |
| 17:17:18 | johnsom | sean-k-mooney It's defined and managed in the kernel, so as long as it's running a Linux kernel it will be the same. | |
| 17:17:49 | sean-k-mooney | johnsom: what is allowable and what are recommend are two differnt things | |
| 17:17:56 | sean-k-mooney | https://www.freedesktop.org/software/systemd/man/hostname.html | |
| 17:18:23 | sean-k-mooney | """ The hostname should be composed of up to 64 7-bit ASCII lower-case alphanumeric characters or hyphens forming a valid DNS domain name. It is recommended that this name contains only a single label, i.e. without any dots. """ | |
| 17:18:55 | johnsom | Once again, what systemd does/thinks is not what the kernel does. | |
| 17:19:04 | sean-k-mooney | correct | |
| 17:19:21 | sean-k-mooney | but that is the same recommendation that nova has for how to constuct hostnames | |
| 17:19:26 | johnsom | As I have mentioned before, even RHEL satellite expects a FQDN. | |
| 17:19:46 | sean-k-mooney | yep and we recommend agains using fqdns in our downstream product | |
| 17:19:57 | sean-k-mooney | that recomendation was ignored and that fine | |
| 17:20:46 | sean-k-mooney | but strictly speaking nova orgially did not orgianly intend to supprot having two compute nodes with the same hostname but idffernt fqdns | |
| 17:21:48 | johnsom | Really, I think this is getting over thought a bit. It seems like we should just pass the FQDN in the metadata and let cloud-init figure out what settings need to go where. That way people don't have to change the hostname of the guest to sign up the instance with satellite, etc. | |
| 17:21:53 | sean-k-mooney | dansmith: johnsom for what its worth i think alternitive 3 in my lates revision might be the best path forward | |
| 17:22:09 | sean-k-mooney | johnsom: that is kind of my option 3 | |
| 17:22:29 | sean-k-mooney | johnsom: https://review.opendev.org/c/openstack/nova-specs/+/850352/1/specs/zed/approved/configurable-instance-domains.rst#96 | |
| 17:22:30 | johnsom | I am just now reading through that. | |
| 17:22:52 | dansmith | I don't understand that opinion *at all* :) | |
| 17:22:58 | sean-k-mooney | so we would truncate and set host name to everyting up to the first . and fqdn to the full thing | |
| 17:23:30 | sean-k-mooney | dansmith: did you look at https://github.com/canonical/cloud-init/blob/91fd72c3f5b416b7815314eebea0b82ccd7e3f73/cloudinit/config/cc_set_hostname.py#L25-L32= | |
| 17:24:12 | johnsom | https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-hostname | |
| 17:24:19 | johnsom | That too is a good reference | |
| 17:24:35 | sean-k-mooney | i think? its the same but html version | |
| 17:24:47 | dansmith | cloud-init does that from the user's own instance metadata right? | |
| 17:24:48 | sean-k-mooney | ya it is | |
| 17:25:04 | sean-k-mooney | hum | |
| 17:25:13 | sean-k-mooney | you thinking we can jsut set the fqdn on the instance metadta | |
| 17:25:16 | sean-k-mooney | and it will show up | |
| 17:25:23 | sean-k-mooney | and prefer_fqdn_over_hostname | |
| 17:25:41 | sean-k-mooney | that woudl be worth a try | |
| 17:25:44 | dansmith | I dunno, I'm asking.. if so that seems like a much better deal, | |
| 17:25:58 | dansmith | basically the contract is between the user and cloud-init, with nova uninvolved | |
| 17:26:16 | sean-k-mooney | well its reading those values form the isntance metadata | |
| 17:26:36 | sean-k-mooney | im just not sure if the urls line up | |
| 17:26:40 | sean-k-mooney | but i can try that now | |
| 17:27:03 | sean-k-mooney | im not sure if the servers generic metadata is under a subkey | |
| 17:27:45 | dansmith | right but is "instance metadata" the actual user's metadata blob, or the "metadata blob that nova generates, of which a sub-dict is the user's" ? | |
| 17:28:24 | sean-k-mooney | its not part of user data | |
| 17:28:33 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L161= | |
| 17:29:11 | sean-k-mooney | im just going to boot a vm and see what it looks like | |
| 17:29:52 | dansmith | not user data, user metadata | |
| 17:30:22 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L318= | |
| 17:30:35 | sean-k-mooney | it look like its in a subkey call meta | |
| 17:32:43 | dansmith | right, metadata['meta'] = { .. the stuff I passed to the API as "metadata" .. } | |
| 17:32:47 | dansmith | correct? | |
| 17:32:56 | sean-k-mooney | ya i think so | |
| 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 | |