| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-19 | |||
| 17:11:37 | sean-k-mooney | you can | |
| 17:12:12 | bauzas | if you want to have your domains managed by OpenStack services, then this is Designate | |
| 17:12:17 | sean-k-mooney | just a note that while these neutron apis existed for a long time they are relitively new to backend like ovn | |
| 17:12:31 | bauzas | if you don't want them, then you can use the entryknobs we currently have | |
| 17:12:45 | sean-k-mooney | bauzas: well right now this is a one way path | |
| 17:12:52 | sean-k-mooney | form nova to neutron to designate | |
| 17:12:59 | dansmith | sean-k-mooney: right, but if the operator has chosen a network backend that doesn't support this, then I think it's reasonable to say that it's not supported to manage this for the user on those deployments | |
| 17:13:04 | sean-k-mooney | no infor ever flows the other way | |
| 17:13:23 | dansmith | if they do, then you can, and if a popular backend doesn't have support for this, but should, then ... work should be done :) | |
| 17:13:32 | dansmith | especially for something as important as OVN | |
| 17:13:42 | sean-k-mooney | it only got this in yoga | |
| 17:13:50 | sean-k-mooney | with some support added in backport ithink | |
| 17:14:00 | sean-k-mooney | at least the per-port dns info only got added in yoga | |
| 17:14:00 | bauzas | I have to quit by now | |
| 17:14:07 | johnsom | Just a note, the guest VM FQDN used for the hostname in the kernel is not related to the FQDN(s) configured for the host in DNS/BIND/Designate. Very different things | |
| 17:14:15 | sean-k-mooney | intenrl dns supprot is in progress for zed | |
| 17:14:47 | sean-k-mooney | johnsom: well by definiti8on the hostname used by the kernel should not be an FQDN | |
| 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 | bauzas | hostnames are host names | |
| 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: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 | |