| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-19 | |||
| 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 | |
| 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 | |