Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-07-19
17:14:56 johnsom Not true
17:14:58 sean-k-mooney johnsom: that what started this mess
17:15:03 johnsom But, we have had that discussion.
17:15:06 sean-k-mooney form a nova persetive we never supprot that
17:15:10 bauzas yup
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

Earlier   Later