| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-19 | |||
| 17:01:38 | sean-k-mooney | bauzas: well we can extned | |
| 17:01:43 | sean-k-mooney | its in the nova changel now | |
| 17:01:46 | sean-k-mooney | but eitehr way | |
| 17:01:49 | bauzas | yeah | |
| 17:02:03 | bauzas | this is just we try to stick with one hour | |
| 17:02:05 | bauzas | anyway | |
| 17:02:14 | sean-k-mooney | dansmith: so do you think we shoudl take a step back and spend more time looking at this | |
| 17:02:24 | dansmith | personally I do, yeah | |
| 17:02:28 | bauzas | me too | |
| 17:02:38 | bauzas | I feel we require a proper brainstorming about it | |
| 17:02:39 | sean-k-mooney | then that fine we can defer to AA | |
| 17:02:41 | dansmith | I'd like to understand more of what we can and can't do with help from neutron | |
| 17:02:44 | sean-k-mooney | and not rush this | |
| 17:02:51 | dansmith | codifying this in our API is just a hack, IMHO | |
| 17:02:55 | dansmith | sounds good to me | |
| 17:03:21 | bauzas | yup, sounds we need a bit of a design time | |
| 17:03:25 | sean-k-mooney | im partly worried that we made dission in this space in the past that tie our hand but we may want to revaulate those | |
| 17:03:41 | sean-k-mooney | so i think we shoudl spend some time between now and ptg evaulating this again | |
| 17:03:47 | sean-k-mooney | including the previous desision | |
| 17:03:48 | bauzas | sean-k-mooney: tbh, one week ago, we were still reviewing some metadata API change IIRC | |
| 17:04:12 | sean-k-mooney | bauzas: yes which we new would not work for quite a while | |
| 17:04:24 | bauzas | which, by reading the superseding spec, I understand why this approach is no longer possible | |
| 17:04:43 | sean-k-mooney | we can do the metadta change too | |
| 17:04:49 | sean-k-mooney | but it wont help the usecasue | |
| 17:04:58 | sean-k-mooney | its just providing more info to the domain | |
| 17:05:01 | sean-k-mooney | ... vm | |
| 17:05:06 | sean-k-mooney | which it will ignore | |
| 17:05:15 | bauzas | but yeah, sounds to me that domains are some information given by the network, not the user | |
| 17:05:33 | sean-k-mooney | bauzas: i would disagree with that | |
| 17:05:40 | sean-k-mooney | but it really depend on the config | |
| 17:05:57 | sean-k-mooney | in generally the domain is carried by the port/floating ip and a default domain can be added to the netowrk | |
| 17:06:05 | sean-k-mooney | anyway we are over time | |
| 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 | bauzas | #endmeeting | |
| 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 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-19-16.00.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 | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-19-16.00.log.html | |
| 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 | 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 | |