| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-20 | |||
| 16:43:39 | gibi | sean-k-mooney: yepp, that was my suggestion to obre too, lift the provider.yamls restriction | |
| 16:43:43 | bauzas | placement was designed for such usecases | |
| 16:43:48 | obre | But then you would like to lift that restriction, and then have nova-compute check its inventories before setting the default-values if none exists? | |
| 16:44:34 | sean-k-mooney | yes nova compute | |
| 16:44:46 | sean-k-mooney | would instead of hardcoding its min/max/step values | |
| 16:44:51 | gibi | yepp | |
| 16:44:51 | obre | Basicly similar to how we do allocation_ratios; just without the config-file option. | |
| 16:44:52 | sean-k-mooney | get tehm form provider.yaml | |
| 16:45:26 | obre | Im not entirly sure I am able to figure all this out by myself; but Ill give it a try; and see if I can manage to write such a patch :) | |
| 16:45:59 | gibi | obre: feel free to ping me here with questions. I can try to look at the code and help | |
| 16:46:43 | obre | gibi: Thanks! | |
| 16:46:46 | obre | gibi: I probably will. | |
| 16:46:48 | gibi | I'm sure we have some unit / functional test coveragae on provider.yaml to play with | |
| 16:47:07 | sean-k-mooney | we will need to modify the schma | |
| 16:47:23 | bauzas | looks like we have an agreement and further steps to | |
| 16:47:37 | sean-k-mooney | and introduce a new adjective(exisitng) https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/provider-config-file.html#provider-config-file-schema | |
| 16:47:43 | bauzas | obre: the next step for you I guess is to write a blueprint | |
| 16:48:01 | sean-k-mooney | and then lift the resticion on the resouce_class startign with CUSTOM_ | |
| 16:48:07 | sean-k-mooney | so this would likely need a spec | |
| 16:48:15 | bauzas | I was debating it | |
| 16:48:16 | sean-k-mooney | to spell it out clearly | |
| 16:48:39 | sean-k-mooney | it will need a new schema_version at a minium | |
| 16:49:00 | gibi | I agree to have a small spec if we need to figure out a new schema | |
| 16:49:02 | sean-k-mooney | i think there is enough of a change required that a spec would be helpful for documentation if nothing elses | |
| 16:49:09 | bauzas | #agreed sounds a valid usecase that requires a blueprint and a spec to be filled in order to address how to properly manage inventories override by placement.yaml file | |
| 16:49:33 | bauzas | obre: do you feel comfortable with this process ? do you need help ? | |
| 16:49:50 | bauzas | or is that whole think old greek to you ? | |
| 16:49:55 | bauzas | thing* | |
| 16:50:03 | obre | bauzas: Ill probably need a bit of help yes. | |
| 16:50:11 | bauzas | obre: you got my nick | |
| 16:50:20 | obre | bauzas: Im not really a developer; more a sysadmin :P | |
| 16:50:22 | bauzas | obre: ping me tomorrow and I'll point you some docs and examples | |
| 16:50:32 | obre | bauzas: Whats your timezone? | |
| 16:50:41 | bauzas | obre: well, specs are formal textfiles, so you shouldn't be afraid :) | |
| 16:50:50 | bauzas | obre: CEST | |
| 16:51:06 | bauzas | that matches then | |
| 16:51:09 | obre | So then the workdays probably sync up :P | |
| 16:51:20 | bauzas | I'm more than happy to help you | |
| 16:51:26 | obre | bauzas: Great! | |
| 16:51:41 | bauzas | our processes can look a bit scary but those are just design documents | |
| 16:52:11 | obre | Ill sorta understand why we need the formal process; Its just that I would have preffered an easier solution for _my_ problems :P | |
| 16:52:11 | bauzas | basically, the idea is just to identify all potential design concerns (upgrades or others) before they come up at review time | |
| 16:52:18 | obre | But its fine :P | |
| 16:52:32 | gibi | :) | |
| 16:52:34 | bauzas | obre: you're litterally at the very beginning of the cycle :) | |
| 16:52:45 | bauzas | so, you wouldn't hear 'sorry, too late' | |
| 16:53:08 | bauzas | the point is, you have gibi and me for helping you out | |
| 16:53:14 | obre | \o/ | |
| 16:53:16 | sean-k-mooney | obre: one thing to think about is do you want this to be config driven. api driven or both | |
| 16:53:25 | sean-k-mooney | we will need to document tha tin the spec | |
| 16:53:29 | bauzas | sean-k-mooney: I tought we said config-driven | |
| 16:53:33 | bauzas | as provider.yaml | |
| 16:53:46 | sean-k-mooney | yes but provide.yaml can say -1 | |
| 16:53:51 | sean-k-mooney | which means this is api contoled | |
| 16:53:57 | sean-k-mooney | or something like that if we care about that usecase | |
| 16:54:02 | bauzas | making it api-driven means we accept our inventories to be changed thru osc-placement | |
| 16:54:09 | sean-k-mooney | so im assuming config driven is enough | |
| 16:54:12 | obre | I think it makes sense to be as close to the way we do CUSTOM_* today as possible? | |
| 16:54:16 | sean-k-mooney | and if so the that simple | |
| 16:54:27 | bauzas | stick to the bare minimum requirements :) | |
| 16:54:45 | bauzas | people could come up with api-driven needs later if they want to :) | |
| 16:54:54 | sean-k-mooney | ok just that was going to be one of the question si would ask in the spec review | |
| 16:55:01 | sean-k-mooney | so i didnt want it to come out of the blue | |
| 16:55:16 | bauzas | sean-k-mooney good point, stating that api-driven is out of the spec seems reasonable | |
| 16:55:39 | sean-k-mooney | yep we can state is as not a usecase we want to enabel now in the alternitives | |
| 16:55:46 | bauzas | anyway, we're approaching end of time and we have a way forward | |
| 16:55:50 | sean-k-mooney | obre: anyway as bauzas said keep it simple for now | |
| 16:55:57 | obre | sean-k-mooney: Ack. | |
| 16:56:11 | bauzas | anything to else to bring before we call it out ? | |
| 16:57:02 | bauzas | looks not | |
| 16:57:11 | bauzas | so, I hereby officially declare the meeting as over. | |
| 16:57:14 | bauzas | thanks all | |
| 16:57:18 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-20-16.00.log.html | |
| 16:57:18 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-20-16.00.txt | |
| 16:57:18 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-09-20-16.00.html | |
| 16:57:18 | opendevmeet | Meeting ended Tue Sep 20 16:57:18 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:57:18 | bauzas | #endmeeting | |
| 16:57:23 | elodilles | thanks bauzas o/ | |
| 16:57:24 | gibi | thank you folks | |
| 16:57:33 | gibi | I sign off for today now o/ | |
| 16:57:46 | bauzas | me too | |
| 16:57:49 | bauzas | Java time ! | |
| 16:57:53 | sean-k-mooney | bauzas: gibi im going to push the default change | |
| 16:57:58 | sean-k-mooney | shortly just an fyi | |
| 16:58:10 | sean-k-mooney | runnign test now but ye can get to it tommorw or whenever | |
| 16:58:14 | bauzas | sean-k-mooney: then, ping me once it's done | |
| 16:58:26 | sean-k-mooney | sure | |
| 16:58:34 | bauzas | sean-k-mooney: fwiw, I'll also try to reconnect with the tick-tock cadence | |
| 16:59:27 | sean-k-mooney | this is not really impacted by tick-tock cadance | |
| 16:59:55 | bauzas | sean-k-mooney: correct, that's what I was recollecting | |
| 17:00:04 | bauzas | that's only B relnotes | |
| 17:00:11 | bauzas | that need to be forward-ported to C | |
| 17:00:13 | bauzas | IIRC | |
| 17:00:38 | sean-k-mooney | am no it would be if it was a deprecation | |
| 17:00:52 | sean-k-mooney | to remove a config option we would have to deprecate in A and then could remove in B | |
| 17:01:02 | sean-k-mooney | but we cant depcreate in B and remove in C | |
| 17:01:03 | bauzas | anyway, I'll be late for listening about microservices and serverless knative :) | |
| 17:01:19 | sean-k-mooney | ack chat to you tomorrow | |
| 17:04:21 | sean-k-mooney | artom: you should read over https://bugs.launchpad.net/nova/+bug/1989357 | |
| 17:04:34 | sean-k-mooney | as a potential usecase for the fqdn work | |