Earlier  
Posted Nick Remark
#openstack-nova - 2021-06-02
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
16:29:37 sean-k-mooney doing obj.app.client_manager.placement.api_version tries to actully connect to placement to do the version negocation
16:29:53 sean-k-mooney which cant work since bash completion will not have your auth details
16:30:09 sean-k-mooney well not the auth deatials but it wont have the cloud endpoint
16:30:18 sean-k-mooney form cloud.yaml
16:30:31 rm_work yeah ideally it should work completely offline (same as "help")
16:30:44 sean-k-mooney this would proably work if you exproted the env vars for the keystone endpoint
16:30:53 sean-k-mooney like the openrc did
16:31:04 sean-k-mooney rm_work: yes it should
16:31:44 sean-k-mooney so here we catrch AttributeError
16:31:46 sean-k-mooney https://github.com/openstack/osc-placement/blob/37e47afc88b188a338e3cb70adcf87bac513d4ef/osc_placement/version.py#L143
16:32:08 sean-k-mooney but we are rasing exceptions.PluginAttributeError
16:32:51 sean-k-mooney https://github.com/openstack/osc-lib/blob/master/osc_lib/clientmanager.py#L49
16:33:59 sean-k-mooney really we should just check if we have a session and if not returnt true
16:34:16 sean-k-mooney well

Earlier   Later