| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-19 | |||
| 17:00:07 | sean-k-mooney | yep so just want to make sure we disucssed ^ | |
| 17:00:09 | bauzas | https://review.opendev.org/c/openstack/nova-specs/+/850048 revert was merged | |
| 17:00:23 | bauzas | do we want to grant an exception for it ? | |
| 17:00:30 | dansmith | are we on to the domains thing? | |
| 17:00:33 | bauzas | yup | |
| 17:00:38 | gibi | I do apologize pushing the spec through within such a sort timeframe last week | |
| 17:00:39 | bauzas | dns domain this | |
| 17:00:48 | dansmith | yeah I still (heartily) question the approach in general | |
| 17:00:48 | sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/850352 is the revert of the revert with some issues adressed | |
| 17:00:59 | sean-k-mooney | yes | |
| 17:01:04 | bauzas | fwiw, we're overtime | |
| 17:01:11 | bauzas | so we'll need to end the meeting | |
| 17:01:18 | dansmith | I know it will/would be more work to do this via integration with neutron, but it seems like it would be a lot better to do so | |
| 17:01:25 | bauzas | but I'd appreciate if people could continue the convo | |
| 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 | |