| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-11-15 | |||
| 16:12:20 | mriedem | there is no 'update' in osc | |
| 16:12:23 | mriedem | there is set | |
| 16:12:27 | melwitt | efried: I tried to add 'update' awhile back and got nacked and ended up instead adding --amend to 'set' | |
| 16:13:20 | efried | Okay, `set --amend` then. Point being, `set` (without something really stark) should be full overwrite. | |
| 16:13:41 | efried | alternative to --no-allocation could be --allocation rp=$uuid,$rc=0 to remove one | |
| 16:13:45 | melwitt | it's not a huge deal if it's not possible to remove for multiple providers, I was just saying it would be one call vs several | |
| 16:13:59 | mriedem | tetsuro also asked for multiple provider support | |
| 16:14:14 | melwitt | heh | |
| 16:14:45 | efried | melwitt: your --amend was for inventories, right? | |
| 16:15:06 | efried | We still don't have any form of amending for allocs yet? | |
| 16:15:09 | melwitt | efried: that was my original reason (allocation ratios) but it works for anything | |
| 16:15:30 | melwitt | oh, sorry yeah | |
| 16:15:33 | efried | "works for anything" theoretically, but is only implemented for inventories currently, right? | |
| 16:15:40 | melwitt | inventory set is its own thing yeah? | |
| 16:15:47 | efried | yeah, separate subcommand. | |
| 16:15:52 | efried | afaiu | |
| 16:15:54 | melwitt | if so then yes it's only for inventories | |
| 16:16:06 | melwitt | I can't remember rn | |
| 16:16:09 | dtroyer | mriedem, efried: I just skimmed the scrollback, it seems like you guys are on the right track. The things to keep in mind are that —no-whatever options are used to remove all of whatever in set commands, to remove a specific one needs an unset command. —all-whatever in unset also has a precedence in network commands. | |
| 16:16:11 | efried | okay, then s/update/set --amend/ for my suggestions above. | |
| 16:16:55 | dtroyer | I'll leave the particulars of the semantics of multiple providers, etc to you guys, I don't think we have a precedent for that sort of thing. If so iit'll be in netowrk commands | |
| 16:17:38 | efried | dtroyer: Roger that. In this case I feel like --no-provider is really jarring semantically so I'm grasping for *any* better option. | |
| 16:18:01 | melwitt | ok yeah inventory set is the only one that has --amend | |
| 16:18:08 | dtroyer | I would expect that to remove all providers, which may or may not make sense at all there | |
| 16:18:24 | efried | dtroyer: does --no-foo ever take an arg? | |
| 16:18:36 | efried | cause that's what's being proposed here. | |
| 16:18:44 | efried | to narrow down what we remove | |
| 16:18:52 | mriedem | based on what dean just said i'd drop the set --no-provider thing, | |
| 16:18:58 | mriedem | and just do: unset --provider | |
| 16:19:17 | mriedem | nargs='+' | |
| 16:19:20 | dtroyer | efried: no, it is used to clear the list (like properites) to allow setting new ones in the same command | |
| 16:19:33 | efried | okay | |
| 16:19:58 | efried | mriedem: having learned about the existing --allocation syntax, I'm not in favor of unset --provider | |
| 16:21:10 | efried | Hindsight: if we had called it `consumer allocation` instead of `resource provider allocation` then we could have made "futz with a resource provider's allocations" the latter. | |
| 16:21:26 | mriedem | so what are you asking for now? allocation set --amend --allocation rp=uuid to remove all allocatoins for a given provider? | |
| 16:21:35 | efried | yes | |
| 16:21:38 | efried | for symmetry | |
| 16:22:23 | mriedem | and --amend with rp=uuid,rc=n means add/update new/existing allocation? | |
| 16:22:37 | efried | yes | |
| 16:23:58 | efried | Hold on, you said --amend --allocation rp=$uuid to remove? As opposed to --amend --allocation rp=$uuid,$rc=0 [... repeat for all $rc] ? | |
| 16:24:11 | efried | I guess that could work. | |
| 16:24:46 | mriedem | i would prefer just a simple unset --provider | |
| 16:25:11 | mriedem | than dork with the existing set --allocation <gdi this is a mess like bdms> format thing | |
| 16:25:16 | mriedem | but that's just me | |
| 16:25:57 | efried | I won't die on a hill for it, but the reasons I don't like that are: | |
| 16:25:57 | efried | 1) it's asymmetrical | |
| 16:25:57 | efried | 2) it makes it impossible to narrow down to RC granularity in the future | |
| 16:26:29 | mriedem | i don't think it's impossible, you add a --resource-class option | |
| 16:26:39 | mriedem | if specified, unset the resource class for the given provider, | |
| 16:26:51 | efried | not if you can specify multiple providers | |
| 16:26:51 | mriedem | if no providers are specified, remove the resource class from all providers on which the consumer has allocations | |
| 16:27:25 | mriedem | 1. openstack resource provider allocation unset --provider A --provider B --resource-class VGPU consumer1 == remove VGPU allocatoins from providers A and B for consumer1 | |
| 16:27:53 | mriedem | 2. openstack resource provider allocation unset --resource-class VGPU consumer1 == remove VGPU allocations from all providers on which consumer1 has allocations | |
| 16:28:13 | mriedem | 3. openstack resource provider allocation unset --provider A consumer1 == remove all allocations consumer1 has on provider A | |
| 16:28:23 | mriedem | doesn't seem impossible to me | |
| 16:28:52 | efried | and --resource-class is repeatable too? | |
| 16:28:56 | mriedem | sure | |
| 16:29:04 | efried | Okay. Then I just hate the asymmetry. | |
| 16:29:35 | efried | 4. openstack resource provider allocation unset consumer1 ? Same as `delete`? | |
| 16:31:26 | mriedem | yeah i guess | |
| 16:31:34 | mriedem | well, | |
| 16:31:52 | mriedem | if you make --provider use nargs=+ to start, then that's not possible as at least one provider is required, | |
| 16:32:03 | mriedem | which you could do until you add support for --resource-class | |
| 16:32:14 | mriedem | but that's a behavior change and would require a major version release probably | |
| 16:32:19 | efried | Yeah, but the code is nearly identical because you still have to deal with having specified all --provider Z | |
| 16:32:23 | mriedem | anyway, sure | |
| 16:32:25 | efried | which is effectively the same. | |
| 16:32:44 | mriedem | so yes to 1-4 | |
| 16:33:09 | efried | are you going to skip implementing --resource-class for now? | |
| 16:34:14 | mriedem | i would yes | |
| 16:34:38 | mriedem | unlike this irc conversation, i don't really want to boil the ocean on providing something simple to just remove a single provider from a set of allocations :) | |
| 16:35:18 | mriedem | this started as like a "this should be relatively simple" kind of thing for something useful | |
| 16:35:33 | mriedem | i appreciate forward-thinking, but i'm also close to just abandoning | |
| 16:37:10 | efried | "remove *multiple* providers from a set of allocations" yeah? | |
| 16:39:11 | mriedem | it started as one, | |
| 16:39:20 | mriedem | tetsuro and mel asked for multiple which was simple to accomodate | |
| 16:44:32 | efried | or so you thought | |
| 16:45:15 | mriedem | yeah this eric guy got involved | |
| 16:45:18 | mriedem | blew it all up! | |
| 16:46:42 | efried | You'll thank me later. | |
| 16:46:44 | efried | In therapy. | |
| 16:53:53 | mnaser | mordred: i hope you're resting well after your entertainment-less flight --- can you leave some comments on https://review.opendev.org/#/c/684740/ please? | |
| 16:54:05 | mnaser | we kinda discussed that briefly at ansiblefest and i think ansible-sig might be a better home | |
| 19:33:55 | johnsom | efried It seems Dean is ok with that osc-lib hack for the neutron docs. Any chance we can move that from WIP? | |
| 19:35:02 | efried | johnsom: which one? | |
| 19:35:46 | johnsom | efried lol, https://review.opendev.org/#/c/693267 | |
| 19:36:28 | efried | johnsom: oh, yeah, needs tests, thought you might be willing to, ahem, co-author :P | |
| 19:36:39 | johnsom | Um, no | |
| 19:37:18 | efried | okay then, I'll see what I can work up. | |
| 19:37:44 | johnsom | Ok, thank you | |
| 20:15:47 | openstackgerrit | Eric Fried proposed openstack/osc-lib master: Add enhance_help kwarg to tags option generators https://review.opendev.org/693267 | |
| 20:15:49 | efried | johnsom: ^ | |
| 20:15:51 | efried | dtroyer: ^ | |
| 20:58:18 | openstackgerrit | Nate Johnston proposed openstack/python-openstackclient master: Handle NotFoundException when listing floating IPs https://review.opendev.org/694571 | |
| 21:10:48 | johnsom | Thanks | |
| 22:07:48 | openstackgerrit | Ruby Loo proposed openstack/openstacksdk master: baremetal node: 'error' is a failed state https://review.opendev.org/694634 | |
| #openstack-sdks - 2019-11-17 | |||
| 10:47:51 | mordred | mnaser: replied. happy to make sig deliverable - is there a pointer somewhere to what I need to do to do that? | |
| #openstack-sdks - 2019-11-18 | |||
| 09:16:08 | Horrorcat | moin. we’re currently troubleshooting keystone-to-keystone federation not working with recent openstackclient versions. the problem manifests itself in that `openstack catalog list` shows the correct endpoints, but for example `openstack server list` claims that no compute endpoint exists in the default region | |
| 09:16:35 | Horrorcat | We reported this issue a while back https://storyboard.openstack.org/#!/story/2004016 and haven’t gotten any feedback. | |
| 09:17:17 | Horrorcat | I now found a super-hacky solution, which is adding `self._cli_options._auth = self.auth` after the `if self._cli_options.service_provider` block in `ClientManager.setup_auth` in osc_lib/clientmanager.py | |