| *** diablo_rojo_phone_ is now known as diablo_rojo_phone | 02:30 | |
| *** diablo_rojo_phone is now known as Guest3739 | 02:31 | |
| -opendevstatus- NOTICE: zuul needed to be restarted, queues were lost, you may need to recheck your changes | 08:47 | |
| opendevreview | Merged openstack/python-openstackclient master: tox: Ignore virtualenvs for pep8 environment https://review.opendev.org/c/openstack/python-openstackclient/+/815031 | 11:04 |
|---|---|---|
| opendevreview | Merged openstack/python-openstackclient master: Remove 'get_osc_show_columns_for_sdk_resource' duplicates https://review.opendev.org/c/openstack/python-openstackclient/+/815032 | 11:04 |
| opendevreview | Merged openstack/python-openstackclient master: Remove remnants of 'six' https://review.opendev.org/c/openstack/python-openstackclient/+/815033 | 11:04 |
| *** tosky_ is now known as tosky | 12:07 | |
| stephenfin | gtema: Bike shedding time! cinder allows you to configure the fields that you can filter various resources on (volumes, attachments, backups, snapshots, etc.). cinderclient lets you list these using a list-filter command. I need to add this to OSC. What do I call it? | 13:48 |
| stephenfin | gtema: I was going to add a separate 'filter list' command for each resource (i.e. 'volume snapshot filter list', 'volume backup filter list') but the underlying API returns filters for all resources, so this seems wasteful: we'd be dumping info for all resources except the one we care about | 13:50 |
| stephenfin | example cinderclient output https://paste.opendev.org/show/810167/ | 13:50 |
| stephenfin | I'm thinking 'volume service filter list' or 'volume filter list' but both have issues. The latter is simpler, but I'm concerned people might think the filters are only for volumes. The former avoids this but people could read it as a filter for the volume service (i.e. the entity shown by 'volume service list'). 'filter list' is too generic | 13:52 |
| stephenfin | Any opinions? I'll just choose one if you don't :-D | 13:53 |
| gtema | Uhm, no opinion in this now | 14:04 |
| frickler | stephenfin: what about "volume resource filter list", just like you kind of said in the first sentence? | 14:05 |
| stephenfin | frickler: oh, that's a good idea. I didn't think of that | 14:05 |
| stephenfin | that'll do nicely. Thanks, frickler | 14:06 |
| frickler | :) | 14:06 |
| gtema | maybe also `block storage filter list` | 14:07 |
| gtema | not to mix with volume as a resource | 14:08 |
| stephenfin | OSC seems to use volume rather than block storage everywhere (though object store instead of simply object), so I'm not so sure about that one. I think 'volume resource' is as clear as e.g. 'volume service' is | 14:10 |
| gtema | that is exactly what I mean. atm we have volume rather for the resource, than the service. If we want to have command related to the service (if I understood correctly what you mean) I would rather try using different name | 14:16 |
| stephenfin | I agree that we shouldn't overload the term. I'm saying that we're already overloading it though and don't use "block storage" as a term anywhere except some docs. It doesn't seem wise to change direction unless we want to rename the existing commands? | 14:18 |
| gtema | I wouldn't change existing commands, cause they refer to the volume as a resource. Where we refer to volume as a service - we can think | 14:19 |
| gtema | object store is not having a prefix at all and that is already creating confusion (not only in OSC, but also in ansible) | 14:20 |
| stephenfin | hmm, fair. Let me see what it looks like and how it fits with existing commands | 14:21 |
| stephenfin | gtema: How about 'volume service resource filter list'? It's a heck of a mouthful but it works? | 14:22 |
| stephenfin | If not, I'd be tempted to rename 'volume service list' to 'block storage service list' | 14:23 |
| stephenfin | with a deprecated alias, of course | 14:23 |
| gtema | maybe it would be really better in the major release introduce block_storage and object_storage | 14:23 |
| gtema | `block storage service list` sounds much better to me | 14:23 |
| stephenfin | so also 'block storage service cluster' for clusters of block storage services? | 14:24 |
| gtema | service cluster? not `block storage cluster`? | 14:25 |
| gtema | which cluster you mean? | 14:25 |
| stephenfin | They're clusters of services https://docs.openstack.org/cinder/latest/contributor/api_microversion_history.html#id7 | 14:27 |
| gtema | oh great, this is not on https://docs.openstack.org/api-ref/block-storage/v3 | 14:27 |
| stephenfin | I think it's a HA thing, but I'm not really sure /o\ I'll have to ask Gorka | 14:27 |
| stephenfin | Yeah, they're missing a few things from the docs :( | 14:27 |
| gtema | very sad - really lot | 14:28 |
| gtema | anyway, in this case I would rather go for `block storage cluster` | 14:29 |
| gtema | I do not think using `service` inside in the command is useful | 14:29 |
| gtema | missing stuff in docs mean we might miss lot in SDK | 14:30 |
| gtema | stephenfin, if you are still around - is nova /limits still accept tenant_id as query_param? https://docs.openstack.org/api-ref/compute/?expanded=show-rate-and-absolute-limits-detail#show-rate-and-absolute-limits | 14:55 |
| stephenfin | gtema: yes, it's still tenant_id | 15:27 |
| gtema | ok, thks | 15:28 |
| stephenfin | there's a blueprint to change it to project_id (ditto for all other remaining references to tenant) but that hasn't landed yet | 15:28 |
| gtema | good, adding it this way | 15:28 |
| gtema | uhm, and quota-set is also non-standard (whatever standard actually is) - no support for ?usage=, but with /quota-sets/XXX/details | 15:31 |
| stephenfin | yeah, there's a lot of those in the nova API, sadly | 15:33 |
| stephenfin | i.e. 'GET /servers/{id}/detail' instead of e.g. 'GET /servers/{id}?detail=1' | 15:33 |
| gtema | https://review.opendev.org/c/openstack/python-openstackclient/+/763414 is making me doubt in myself | 15:34 |
| gtema | check passes, gate fails (single test I mean) | 15:35 |
| * stephenfin looks | 15:35 | |
| stephenfin | not entirely related but why is HypervisorTests.test_hypervisor_list calling 'hypervisor show'? :) | 15:36 |
| stephenfin | that's a strange failure | 15:37 |
| gtema | nice question | 15:37 |
| stephenfin | so the test fails at 2021-10-22 15:04:02.759154 after 5.132781s | 15:39 |
| gtema | ah, cause I first try to get list of existing ids | 15:39 |
| * stephenfin looks at logs for around that time period | 15:39 | |
| stephenfin | there's the request hitting the API at 15:04:02.564172 https://zuul.opendev.org/t/openstack/build/1f6c15565b2840bfb6e4f09ec7714ea0/log/controller/logs/screen-n-api.txt#1979 | 15:42 |
| gtema | apparently OSC receives empty response back | 15:43 |
| stephenfin | the compute service is still up | 15:46 |
| stephenfin | https://zuul.opendev.org/t/openstack/build/1f6c15565b2840bfb6e4f09ec7714ea0/log/controller/logs/screen-n-cpu.txt#7018 | 15:46 |
| gtema | I'm not able to understand why check and gate behaves differently - and this 2 times | 15:47 |
| gtema | maybe I should rebase | 15:48 |
| stephenfin | I'd suggest trying it. That's weird | 15:48 |
| opendevreview | Artem Goncharov proposed openstack/python-openstackclient master: Switch hypervisor operations to SDK https://review.opendev.org/c/openstack/python-openstackclient/+/763414 | 15:48 |
| gtema | well, and if check will fail now I would be even more confused ;-) | 15:49 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!