| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-19 | |||
| 17:06:09 | dansmith | I think bauzas meant the network infra, | |
| 17:06:13 | dansmith | which is what I meant when I said it | |
| 17:06:20 | bauzas | well, unless I'm wrong, DNS is L5 | |
| 17:06:26 | sean-k-mooney | right | |
| 17:06:29 | dansmith | not necessarily "the network object in neutron, distinct from the port object" | |
| 17:06:41 | sean-k-mooney | what is greate is this is not integrated with routed network properly either | |
| 17:06:48 | bauzas | yeah, not the "neutron network" | |
| 17:06:52 | dansmith | and I totally think it does come from network infra, at least in terms of plumbing | |
| 17:07:04 | bauzas | I meant 'the network infrastructure" | |
| 17:07:06 | sean-k-mooney | dansmith: its ment to be self service | |
| 17:07:07 | dansmith | if you override it in your guest OS, that's fine, but we don't need to be involved in that level, IMHO | |
| 17:07:17 | sean-k-mooney | at least with designate the model is bring your own domain | |
| 17:07:42 | bauzas | this is some data Nova doesn't have to deal with | |
| 17:07:43 | dansmith | sean-k-mooney: totally, but we should integrate with the services providing the network infra, even if you took your own domain to them | |
| 17:07:47 | sean-k-mooney | you point your domain mx rcords to desigante and then manage it as an enduser independet of the cloud admin | |
| 17:07:54 | dansmith | yep, understand | |
| 17:08:16 | dansmith | I'm not saying openstack shouldn't handle this, I'm saying I think nova is probably not the right place to set this per-instance | |
| 17:08:17 | bauzas | in theory, you could even have your DNS servers totally uncorrelated from OpenStack services | |
| 17:08:34 | sean-k-mooney | yes. | |
| 17:08:39 | bauzas | but Nova shouldn't be managing it | |
| 17:08:52 | sean-k-mooney | anyway im not going to ask for a spec freeze excption for this | |
| 17:08:58 | bauzas | this could be some "metadata" information | |
| 17:09:10 | bauzas | yeah and we need to end the meeting | |
| 17:09:15 | sean-k-mooney | im not sure i agree with "nova shoudl not be managing this" but i understand why you have that view point | |
| 17:09:24 | sean-k-mooney | so yes lets end the meeting | |
| 17:09:55 | bauzas | let's end the meeting for now | |
| 17:09:57 | bauzas | and we'll continue | |
| 17:10:00 | bauzas | thanks all | |
| 17:10:03 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-19-16.00.log.html | |
| 17:10:03 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-19-16.00.txt | |
| 17:10:03 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-19-16.00.html | |
| 17:10:03 | opendevmeet | Meeting ended Tue Jul 19 17:10:03 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:10:03 | bauzas | #endmeeting | |
| 17:10:34 | bauzas | sean-k-mooney: I meant this can be an instance metadata information | |
| 17:10:56 | bauzas | but I don't want it to be "primer" as officially defined in our instance API | |
| 17:11:23 | bauzas | technically, you can pass your domain information thru userdata too | |
| 17:11:25 | sean-k-mooney | perhaps we have alternitives to not need to encodeing in the instance api | |
| 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 | bauzas | I have to quit by now | |
| 17:14:00 | sean-k-mooney | at least the per-port dns info only got added in yoga | |
| 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 | 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 | |