| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-02 | |||
| 12:47:52 | sean-k-mooney | i ment to do it last week and forgot this week | |
| 12:47:53 | stephenfin | I'd just add core to stable-core, personally. Probably something for the next meeting | |
| 12:48:40 | gibi | I'm not against it, we need agreemet from stable cores though :) | |
| 12:48:42 | sean-k-mooney | i could i wanted to add a new group to not need to add people to nova-stable-maint for os-vif stable | |
| 12:48:50 | lyarwood | yup I'm not against that | |
| 12:50:08 | sean-k-mooney | gibi: im +2 on the reparenting spec too but i did not give +w to allow melwitt and other to review | |
| 12:50:45 | gibi | sean-k-mooney: ack, thanks | |
| 12:56:57 | sean-k-mooney | stephenfin: should you have not cherry picked the stable train patch form stable ussuri | |
| 12:57:48 | stephenfin | no point. It was just merge conflict hell and they're stable only | |
| 12:58:40 | sean-k-mooney | well normally stable only patches would be cherry picked | |
| 12:58:47 | sean-k-mooney | but ok | |
| 12:59:08 | sean-k-mooney | if its generally effectivly a rewrite then ill change the -1 to +1 | |
| 13:29:23 | opendevreview | Lee Yarwood proposed openstack/nova master: libvirt: Do not destroy volume secrets during _hard_reboot https://review.opendev.org/c/openstack/nova/+/793463 | |
| 13:45:15 | sean-k-mooney | oh ok | |
| 13:46:20 | sean-k-mooney | i guess its ok to not destroy the secreat for had reboot | |
| 13:46:24 | sean-k-mooney | *hard | |
| 13:46:41 | sean-k-mooney | soft reboot calls hard reboot also by the way if it does not soft reboot after a time out | |
| 14:47:27 | mdbooth | sean-k-mooney: Incidentally, I've always felt that was a misfeature. Soft and hard reboots are quite different things. If the user asks for a soft reboot and it doesn't work, they should get an error (asynchronously, obvs). | |
| 14:49:24 | sean-k-mooney | mdbooth: i think its configurable in the nova config | |
| 14:49:47 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.reboot_timeout | |
| 14:50:00 | sean-k-mooney | so by default we dont | |
| 14:50:38 | sean-k-mooney | but it can be enabled | |
| 14:51:09 | sean-k-mooney | which is config driveen api behavior which is awesome... | |
| 14:51:41 | sean-k-mooney | mdbooth: i would much prefer a reboot --gradual or somehting like that to contol that | |
| 15:19:45 | opendevreview | Lee Yarwood proposed openstack/nova master: libvirt: Do not destroy volume secrets during _hard_reboot https://review.opendev.org/c/openstack/nova/+/793463 | |
| 15:19:45 | opendevreview | Lee Yarwood proposed openstack/nova master: virt: Add destroy_secrets kwarg to destroy and cleanup https://review.opendev.org/c/openstack/nova/+/794252 | |
| 15:21:04 | melwitt | lyarwood: added a comment on the launchpad bug wrt wsgi config | |
| 15:21:14 | lyarwood | melwitt: thanks | |
| 15:32:11 | melwitt | sean-k-mooney: the current proposal is to reflect the allocations indirectly via /usages https://review.opendev.org/c/openstack/placement/+/679441/18/api-ref/source/usages.inc and you can filter by project and user | |
| 15:33:00 | melwitt | gibi: ack, will look | |
| 15:33:12 | gibi | melwitt: thanks | |
| 15:33:19 | sean-k-mooney | melwitt: i see ok | |
| 15:33:22 | opendevreview | Merged openstack/nova master: Honor [neutron]http_retries in the manual client https://review.opendev.org/c/openstack/nova/+/793512 | |
| 15:36:02 | bauzas | sean-k-mooney: gibi: oh, just saw your discussion about reservations | |
| 15:36:13 | bauzas | fwiw, blazar already supports timed reservations | |
| 15:36:42 | bauzas | so, the concern here is that we duplicate allocations into blazar-like reservations | |
| 15:36:56 | bauzas | while an idea could be to add timed allocations in placement | |
| 15:37:07 | bauzas | but that's a massive change | |
| 15:37:14 | sean-k-mooney | yes im aware | |
| 15:37:37 | bauzas | the other issue is with quotas | |
| 15:37:45 | sean-k-mooney | yep | |
| 15:38:14 | sean-k-mooney | unified limits would have to understand consumer types and allow qutos per consumer type not just projects | |
| 15:38:37 | bauzas | that's the problem | |
| 15:39:05 | bauzas | blazar would need to support quotas for resources that are different from current quotas | |
| 15:39:16 | melwitt | I'm working on consumer types this cycle fwiw | |
| 15:39:31 | melwitt | just behind on updating the PS from last feedback | |
| 15:39:54 | bauzas | just explaining one of the usecases | |
| 15:40:03 | bauzas | if I have quota for 10 vCPUs | |
| 15:40:29 | bauzas | could I reserve 20 vCPUs over time provided I only start 10 concurrently? | |
| 15:40:43 | bauzas | I could honesly overload resource usage by this | |
| 15:41:15 | bauzas | I could ask for 1000000 vCPUs provided I only have reservations for 10 by once | |
| 15:42:56 | sean-k-mooney | yep i know there are many issue | |
| 15:43:32 | sean-k-mooney | that is why i was suggesting to belmoreira that we proably dont have the design bandwith this cycle for premtibel instances | |
| 15:43:53 | sean-k-mooney | but i think we should consider it for a future cycle and maybe have a sub team to figure this out | |
| 15:44:11 | bauzas | preemptible instances are way simplier to design | |
| 15:44:19 | bauzas | since we don't have reservations | |
| 15:44:45 | bauzas | there are just prioritized instances and non-priortized ones | |
| 15:54:28 | opendevreview | Merged openstack/os-vif stable/ussuri: [Stable Only] Drop lower constraints testing https://review.opendev.org/c/openstack/os-vif/+/794210 | |
| 16:05:30 | rm_work | having an issue with the osc-placement==3.0.0 breaking `openstack completion`, is this the place, or does placement have their own channel, or would an sdk/client channel be better? :D | |
| 16:07:10 | rm_work | http://paste.openstack.org/show/806280/ | |
| 16:10:10 | sean-k-mooney | rm_work: ish | |
| 16:10:31 | sean-k-mooney | ah you are using py 3.9.5 | |
| 16:10:50 | sean-k-mooney | techinially that not supported yet | |
| 16:11:26 | rm_work | ah ok, think it's related? | |
| 16:11:30 | rm_work | I can test with 3.8 | |
| 16:11:34 | sean-k-mooney | return self.session.request(url, method, | |
| 16:11:36 | sean-k-mooney | AttributeError: 'NoneType' object has no attribute 'request | |
| 16:11:51 | sean-k-mooney | i wonder if requests has moved somehing in 3.9 | |
| 16:11:52 | rm_work | will try with 3.8.9 | |
| 16:12:10 | rm_work | well, that implies self.session == None | |
| 16:12:13 | rm_work | right? | |
| 16:12:36 | rm_work | which almost makes sense, why would there be a session (or even need to be one) just to get a command list? | |
| 16:12:37 | sean-k-mooney | yes i gues it does | |
| 16:14:35 | sean-k-mooney | the erro is startin gin the client cache | |
| 16:14:38 | sean-k-mooney | https://github.com/openstack/osc-lib/blob/master/osc_lib/clientmanager.py#L45 | |
| 16:14:47 | sean-k-mooney | whcih is a mixin | |
| 16:14:59 | rm_work | hmm yeah most of this code hasn't changed in years | |
| 16:17:06 | sean-k-mooney | the sessin comes form the instance passed ot make_client https://github.com/openstack/osc-placement/blob/master/osc_placement/plugin.py#L29-L43 | |
| 16:17:41 | sean-k-mooney | i wonder if this is a gregression in the api microversion auto negociation code | |
| 16:18:21 | sean-k-mooney | since the failure is comming form inside self.negotiate_api_version(api_version) | |
| 16:19:00 | sean-k-mooney | the auto complete code likely doe snot actully connect to the cloud | |
| 16:19:12 | sean-k-mooney | well it should not connect ot the cloud | |
| 16:19:27 | sean-k-mooney | so the auto complete code will need to handel that | |
| 16:19:31 | sean-k-mooney | stephenfin: gibi ^ | |
| 16:21:23 | sean-k-mooney | i would gues that OSC itself is passing None for the session to osc_placment | |
| 16:24:15 | rm_work | that'd make sense I guess -- not sure what else it could reasonably pass | |
| 16:24:32 | rm_work | and it'd expect the client to deal with that in this case but placement made a different assumption | |
| 16:24:41 | rm_work | though again, not a change on the placement side I think? | |
| 16:24:56 | rm_work | since I can't find any code in osc-placement that has changed since like 2019 lol | |
| 16:25:43 | rm_work | maybe should bring this up in thee client channel | |
| 16:25:43 | sean-k-mooney | we merged that auto negocaation code about last week or the week before | |
| 16:25:47 | rm_work | oh, k | |
| 16:26:28 | rm_work | wait where is that | |
| 16:27:24 | sean-k-mooney | so this is causing the get to rfail https://github.com/openstack/osc-placement/blob/37e47afc88b188a338e3cb70adcf87bac513d4ef/osc_placement/version.py#L142 | |
| 16:28:19 | sean-k-mooney | the allocation endpoing and like all the rest is chanck the api version and seeing if it supprot things | |
| 16:28:27 | sean-k-mooney | File "/Users/rm_work/.pyenv/versions/3.9.5/envs/osc2/lib/python3.9/site-packages/osc_placement/resources/allocation.py", line 90, in get_parser | |
| 16:28:29 | sean-k-mooney | required=self.compare_version(version.ge('1.8')) | |
| 16:28:49 | sean-k-mooney | so the allocation class is using the compare_version mixin | |
| 16:28:51 | gibi | rm_work, sean-k-mooney: I've just confirmed locally that 3.0.0 break the completion, while 2.2.0 still works | |
| 16:29:18 | gibi | so it is pretty likely that the microversion negotiation break it as that is the only thing we merged in 3.0.0 | |