| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-02 | |||
| 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 | sean-k-mooney | we merged that auto negocaation code about last week or the week before | |
| 16:25:43 | rm_work | maybe should bring this up in thee client channel | |
| 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 | |
| 16:35:04 | sean-k-mooney | if not obj.app.client_manager.session: return SUPPORTED_VERSIONS[0] | |
| 16:35:17 | sean-k-mooney | here https://github.com/openstack/osc-placement/blob/master/osc_placement/version.py#L141 | |
| 16:36:01 | sean-k-mooney | actully maybe SUPPORTED_VERSIONS[-1] would be better | |
| 16:36:22 | sean-k-mooney | we have a choice of assume oldest or newest microversion for completion | |
| 16:36:33 | sean-k-mooney | newset might be best | |
| 16:36:59 | sean-k-mooney | gibi: do you think ^ is a vaild approch | |
| 16:37:44 | gibi | sean-k-mooney: agree, for completion just assume the newest supported | |
| 16:38:20 | sean-k-mooney | rm_work: you could proably work around this by changing the complation command used in bash | |
| 16:38:42 | sean-k-mooney | to pass --os-placment-api-version or whatever that flag is to the openstack client | |
| 16:38:49 | sean-k-mooney | as a tempory hack | |
| 16:40:40 | sean-k-mooney | gibi: actully if you just run "openstack complete" you get "ould not clean up: 'ClientManager' object has no attribute 'sdk_connection'" | |
| 16:40:42 | sean-k-mooney | at the end | |
| 16:41:03 | gibi | that last error comes from 2.2.0 as well | |
| 16:41:08 | gibi | but it does not break completion I think | |
| 16:41:13 | gibi | or is it? | |
| 16:44:11 | rm_work | yeah i've noticed that for a long time, not sure if that's placement related | |
| 16:44:21 | rm_work | and no, it didn't break completion | |
| 16:45:06 | sean-k-mooney | correct it does not but it does point to the fact that this is a general problem with the complete command | |
| 16:45:54 | sean-k-mooney | in at least the cleanup path its trying to unconditonally clean up the sdk connection that is never established | |
| 16:46:54 | rm_work | yeah | |
| 16:49:12 | sean-k-mooney | rm_work: can you try invoking complete but passing --os-cloud | |
| 16:49:25 | rm_work | uhh sure | |
| 16:49:34 | rm_work | I do have OS_CLOUD exported, FWIW | |
| 16:49:47 | sean-k-mooney | oh in that case never mind | |
| 16:50:01 | rm_work | and yeah no difference | |
| 16:50:02 | sean-k-mooney | i was wondering if we told it what cloud to sue woudl the normal auth kick in | |
| 16:50:24 | rm_work | what is an example `--os-placment-api-version` i could try btw | |
| 16:50:49 | rm_work | well, typed a random number and it works | |
| 16:51:01 | rm_work | `openstack complete --os-placement-api-version 1.2` | |