| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-11-12 | |||
| 13:58:19 | Blinkiz | oh, I see. Yeah, of course. | |
| 13:59:19 | frickler | iiuc this is the code that handles the different scoping options https://opendev.org/openstack/keystoneauth/src/branch/master/keystoneauth1/identity/v3/base.py#L148-L166 | |
| #openstack-sdks - 2019-11-13 | |||
| 02:57:22 | openstackgerrit | Bin Lu proposed openstack/python-openstackclient master: add optional argument metric to set metric for routes https://review.opendev.org/637658 | |
| 10:58:47 | openstackgerrit | Riccardo Pittau proposed openstack/openstacksdk master: Add reset_interfaces argument to patch_node https://review.opendev.org/689414 | |
| #openstack-sdks - 2019-11-14 | |||
| 16:01:19 | elmiko | API SIG office hour now starting | |
| 17:15:11 | elmiko | wheeelp, i'm closing up shop. have a nice weekend all o/ | |
| 18:09:32 | openstackgerrit | Eric Fried proposed openstack/cliff master: Add autoprogram_cliff_app_dist_name config opt https://review.opendev.org/692464 | |
| 20:12:14 | openstackgerrit | Merged openstack/openstacksdk master: Add clustering update_action https://review.opendev.org/682787 | |
| #openstack-sdks - 2019-11-15 | |||
| 08:06:54 | openstackgerrit | Yongli He proposed openstack/python-openstackclient master: Microversion 2.78 - server show topology https://review.opendev.org/680928 | |
| 09:07:36 | openstackgerrit | Daniel Bengtsson proposed openstack/python-openstackclient master: Stop configuring install_command in tox. https://review.opendev.org/694484 | |
| 09:33:55 | openstackgerrit | Daniel Bengtsson proposed openstack/python-openstackclient master: Stop configuring install_command in tox and stop use pip. https://review.opendev.org/694484 | |
| 10:43:47 | openstackgerrit | Daniel Bengtsson proposed openstack/osc-lib master: Stop configuring install_command in tox and stop use pip. https://review.opendev.org/694510 | |
| 11:48:39 | jawad_axd | Hi folks, How to get vm console url (as openstack console url show server) from openstackSDK ? | |
| 12:45:06 | frickler | jawad_axd: this seems to be a missing feature. some tried to implement this three years ago, but failed, I haven't found anything happening after that https://review.openstack.org/319828 | |
| 12:48:28 | frickler | osc is using novaclient for that action iiuc | |
| 12:50:34 | jawad_axd | frickler: okay..I am looking into link you provided. Thanks for reply. | |
| 14:13:27 | mriedem | dtroyer: when you get a chance, can you weigh in on an option name on this osc-placement patch? https://review.opendev.org/#/c/691422/ - it's updating a set command to add a --no-provider option which means, remove allocations for the given provider (but not all providers), | |
| 14:13:40 | mriedem | the --no-provider name is trying to mirror CLIs like port set --no-tag, | |
| 14:13:49 | mriedem | but at least 2 people (efried and melwitt) were confused by it | |
| 14:14:11 | mriedem | my alternative suggestions are (1) change the option name to be --clear-provider or --remove-provider and keep using the set command, | |
| 14:14:21 | mriedem | or (2) add an unset command with a --provider option | |
| 14:15:52 | mriedem | e.g. openstack resource provider allocation unset --provider prov1 --provider prov2 consumer1 // removes consumer1's allocations from prov1 and prov2 | |
| 15:20:46 | openstackgerrit | Nate Johnston proposed openstack/python-openstackclient master: Handle NotFoundException when listing floating IPs https://review.opendev.org/694571 | |
| 15:28:06 | efried | mriedem: (2) jumped out as being pretty clean/intuitive. I haven't stared at it yet. | |
| 15:31:28 | mriedem | i left a comment on the review but one fear i have with adding unset is someone expecting it to also have a --no-allocation or some option to also remove specific resource classes from an existing provider allocation combo, which would be really annoying | |
| 15:41:10 | efried | mriedem: I was about to respond to that. IMO | |
| 15:41:10 | efried | openstack resource provider allocation unset --consumer C [--provider P] [--resource-class R1 [--resource-class R2 ...]] | |
| 15:41:10 | efried | makes enough sense. | |
| 15:41:10 | efried | If you don't specify a --provider, all providers are affected. | |
| 15:41:10 | efried | You can specify at most one --provider, in which case only that provider is affected. | |
| 15:41:10 | efried | You can specify zero or more | |
| 15:41:21 | efried | ... --resource-class, in which case only those resource classes are affected. | |
| 15:41:55 | efried | For a first iteration you could leave off the --resource-class arg, but if/when it needs to be added later, does that seem like a reasonable design? | |
| 15:42:35 | efried | If you need to affect a >1 subset of providers, repeat the command. Are we allowed to say that? | |
| 15:45:17 | mriedem | i think consumer and at least one provider should be required, consumer obviously (it's an arg, not an option) | |
| 15:45:47 | mriedem | specifying zero providers means what? clear all allocations? | |
| 15:46:25 | mriedem | and if so, <1.28 means DELETE, >= 1.28 means PUT with empty allocs dict and consumer_generation | |
| 15:46:36 | mriedem | i'm not dealing with that --resource-class garbage | |
| 15:47:26 | efried | Yes, zero providers means remove all allocations, the base use case for 'allocation unset $consumer'. | |
| 15:47:54 | mriedem | and that's only useful over allocation delete b/c of 1.28 and consumer generations? | |
| 15:48:45 | efried | Do you think it's necessary to have a generation'd code path in `allocation delete`? | |
| 15:49:06 | mriedem | not really | |
| 15:49:24 | mriedem | if someone wanted that, you could provide 1.28 and a --safe or --validate option or something like that | |
| 15:49:36 | efried | IMO this kind of reflects the semantics of DELETE vs PUT{}: one you're saying "Blow it away. I don't care what's there." The other you're saying "Remove what I think is there right now. If something changes, hold up, I need to reevaluate" | |
| 15:49:38 | mriedem | openstack --os-placement-api-version 1.28 resource provider allocation delete --safe <consumer_id> | |
| 15:49:50 | efried | But in a CLI like this, the window between the GET and PUT is so small, I'm not sure it adds any value. | |
| 15:50:49 | efried | so no, unset with no provider (and no RC) doesn't really add value. It's just a reducto case of two CLIs providing the same function. | |
| 15:51:39 | efried | If you include (or at least plan for) the RC option, though, it does make sense for --provider to be optional. | |
| 15:51:48 | efried | "Remove all bandwidth allocations" | |
| 15:51:55 | efried | "Remove all GPUs" | |
| 15:52:14 | efried | things that can be on (multiple) nested providers | |
| 15:52:52 | mriedem | congratulations, you've talked me out of wanting to work on this anymore :) | |
| 15:55:03 | mriedem | what i'd probably do is unset with --provider using nargs='+' to start meaning at least one --provider is required, | |
| 15:55:11 | mriedem | if at some point you want to make --provider really optional, you drop the nargs | |
| 15:58:13 | efried | I don't think we should allow more than one provider. | |
| 15:58:35 | efried | mm, hold that thought. | |
| 15:59:05 | efried | I guess you're more likely to want to remove all (nested) allocs from one host, huh. | |
| 15:59:25 | efried | ... unset --root-provider $P ? | |
| 15:59:36 | efried | --tree $P ? | |
| 15:59:37 | mriedem | melwitt specifically wants to be able to remove allocations from more than one provider in a single call | |
| 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. | |