| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-11-15 | |||
| 15:59:56 | efried | always all and only in the same tree? | |
| 16:00:03 | efried | brbwc | |
| 16:00:05 | mriedem | no | |
| 16:00:08 | mriedem | no trees | |
| 16:00:13 | mriedem | simple old separate compute node providers | |
| 16:00:35 | mriedem | e.g. you try migrating a server to hosts A, B, C, all fail, all orphan providers b/c nova has a bug | |
| 16:01:46 | efried | and it doesn't help us to just fix the bug, because osc needs to be usable against old still-broken clouds. | |
| 16:02:32 | mriedem | correct | |
| 16:03:44 | efried | I can't think of reasonable way to allow granular updates on the CLI because you need to specify RP+RC in pairs. | |
| 16:04:12 | mriedem | right, which is what allocation set --allocation does and it's a really gross interface on a command line | |
| 16:04:36 | mriedem | there is a good example of the gross in here https://docs.openstack.org/nova/latest/admin/troubleshooting/orphaned-allocations.html | |
| 16:04:51 | mriedem | https://docs.openstack.org/nova/latest/admin/troubleshooting/orphaned-allocations.html#solution | |
| 16:05:14 | efried | yeah, rp=$u,RC=$n | |
| 16:05:16 | mriedem | that's the reason i'm working on the osc-placement command | |
| 16:06:06 | efried | okay, well, if we have a precedent for this --allocation syntax (I didn't realize that) then IMO it makes the path forward *somewhat* clearer. | |
| 16:08:21 | efried | Does `allocation set` have anything yet that does partial update? | |
| 16:08:54 | efried | If not, I'd like to keep it that way. "set" means full overwrite, end of story. | |
| 16:09:05 | efried | And we should put partials in a different CLI. | |
| 16:09:17 | efried | whether `update` or `unset` | |
| 16:11:40 | efried | `update` could take --allocation {same syntax as `set`} to add a rp/rc to what's there, and --no-allocation rp=$uuid[,$rcname] to remove. Omit $rcname and everything from that provider goes away, which is melwitt's use case. And we can defer implementing [,$rcname] to later. | |
| 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. | |