| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-19 | |||
| 16:54:59 | sean-k-mooney | to keep it entirly off by defualt | |
| 16:55:13 | bauzas | if that's purely additive and host-config based only, doesn't sound a big deal | |
| 16:55:23 | yoctozepto | i.e., "do not touch this part of libvirt's xml" by default? | |
| 16:55:30 | bauzas | correct | |
| 16:55:34 | bauzas | no upgrade impact | |
| 16:55:34 | yoctozepto | makes sense | |
| 16:55:38 | sean-k-mooney | right we cuurrently dont generate the elements | |
| 16:55:44 | sean-k-mooney | so we coudl continue to do that by default | |
| 16:55:51 | yoctozepto | agreed | |
| 16:55:58 | gibi | I'm OK to grant the exception for this. | |
| 16:56:13 | bahnwaerter | sean-k-mooney: Yeah, I could change that. It makes more sense to only set the libvirt entries if they are specified in a nova.conf | |
| 16:56:20 | bauzas | yoctozepto: do you have open changes against it ? | |
| 16:56:33 | bauzas | oh, that's bahnwaerter's question then | |
| 16:56:41 | sean-k-mooney | there is a nova change and nova-specs change open | |
| 16:56:50 | yoctozepto | ++ | |
| 16:56:52 | sean-k-mooney | so if we grant the excption we can update the sepc before we merge it | |
| 16:56:54 | bauzas | ok, so there is already a poc | |
| 16:57:01 | sean-k-mooney | yes | |
| 16:57:10 | bahnwaerter | bauzas: Yeah, I was invited to this dicussion today ;) | |
| 16:57:10 | bauzas | all the planets are aligned then | |
| 16:57:27 | bauzas | let me take my baton then... | |
| 16:58:23 | bauzas | #agreed https://review.opendev.org/c/openstack/nova-specs/+/849488/ granted as a spec deadline exception, sounds reasonable provided there is no upgrade impact and the change being purely self-contained and additive | |
| 16:58:38 | bauzas | cores, I'd appreciate if you could review it ASAP | |
| 16:58:54 | bauzas | (the spec, tbc) | |
| 16:59:18 | bauzas | that's it I guess for today | |
| 16:59:20 | sean-k-mooney | ill drop +2 given the pending change to the config behavior | |
| 16:59:28 | sean-k-mooney | not quite | |
| 16:59:37 | bauzas | sean-k-mooney: about the spec itself | |
| 16:59:47 | bauzas | (sean) there seams to be considerable outstanding question with regards to Configurable instance domains | |
| 16:59:50 | sean-k-mooney | oh ya so that it for that topic | |
| 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 | sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/850352 is the revert of the revert with some issues adressed | |
| 17:00:48 | dansmith | yeah I still (heartily) question the approach in general | |
| 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 | |