| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2020-03-11 | |||
| 20:38:37 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Rationalize examples and functional extra config loading https://review.opendev.org/712538 | |
| 21:27:35 | umbSublime | heh, I was about to ask if the sdks config supported adding arbitrary sections to clouds.yaml. TIL \o/ | |
| 21:32:08 | mordred | umbSublime: :) | |
| 22:26:14 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Rationalize examples and functional extra config loading https://review.opendev.org/712538 | |
| #openstack-sdks - 2020-03-12 | |||
| 00:17:57 | openstackgerrit | Felix Yan proposed openstack/cliff master: Fix compatibility with new cmd2 https://review.opendev.org/712591 | |
| 09:54:12 | dtantsur | mordred: morning! when you have a minute, this backport https://review.opendev.org/#/c/712536/ will likely make sshnaidm a bit happier | |
| 09:55:36 | sshnaidm | dtantsur, thanks! | |
| 09:57:58 | sshnaidm | dtantsur, btw take a look https://review.opendev.org/#/c/712303/ | |
| 09:59:16 | dtantsur | sshnaidm: are you aware of this call? https://docs.openstack.org/openstacksdk/latest/user/proxies/baremetal.html#openstack.baremetal.v1._proxy.Proxy.wait_for_nodes_provision_state | |
| 09:59:21 | dtantsur | you seem to be duplicating it | |
| 10:00:26 | dtantsur | if you miss something from it, let's update the SDK rather then duplicating the functionality | |
| 10:01:21 | sshnaidm | dtantsur, yeah I know this call, but it's blocking, in the module I run all nodes provision in parallel | |
| 10:02:05 | dtantsur | sshnaidm: I mean, it's a direct replacement for lines 354-400 | |
| 10:02:15 | dtantsur | where you're looping over nodes waiting for them to be finished | |
| 10:02:23 | dtantsur | wait_for_nodes_provision_state does exactly that | |
| 10:02:30 | dtantsur | I don't suggest you use wait=True on set_node_provision_state | |
| 10:03:12 | sshnaidm | dtantsur, a-ha, seems like I missed it can be done for multiple nodes | |
| 10:03:28 | dtantsur | yep, I implemented it this way specially for cases like yours :) | |
| 10:03:57 | dtantsur | lemme know if anything is missing there, we can update it | |
| 10:04:14 | sshnaidm | dtantsur, and in case of failure, does it still return nodes that were provisioned successfully? | |
| 10:04:48 | dtantsur | sshnaidm: I'm not sure, but we can implement that | |
| 10:06:22 | dtantsur | sshnaidm: it raises an exception by default. do you need this functionality? | |
| 10:06:51 | sshnaidm | dtantsur, yeah, maybe an option to not raise, but return passed/failed | |
| 10:07:10 | sshnaidm | dtantsur, not too critical though | |
| 10:07:31 | dtantsur | sshnaidm: I'll look into that. I'd suggest you start without it to avoid these 50 lines of code. | |
| 10:08:15 | sshnaidm | dtantsur, yeah, will replace it, thanks | |
| 10:09:08 | sshnaidm | dtantsur, also need to figure out if we need one module for "set state" for nodes, right now it's one for provide, and one for cleaning | |
| 10:09:24 | sshnaidm | and they have dups of course | |
| 10:10:14 | dtantsur | a good question. at the very least, they have different parameters | |
| 10:18:42 | openstackgerrit | Dmitry Tantsur proposed openstack/openstacksdk master: [WIP] baremetal: fail-less mode for wait_for_nodes_provision_state https://review.opendev.org/712637 | |
| 10:18:43 | dtantsur | sshnaidm: wdyt about this design ^^^? | |
| 10:23:36 | openstackgerrit | Igor Malinovskiy proposed openstack/python-openstackclient master: Add 'address_scope' type support to network rbac commands https://review.opendev.org/709124 | |
| 10:24:23 | sshnaidm | dtantsur, perfect | |
| 10:24:35 | dtantsur | okie, will add tests now | |
| 10:25:20 | sshnaidm | dtantsur, cool, thanks | |
| 10:25:44 | sshnaidm | dtantsur, after I'm done, we'll need to talk about how to optimize the modules | |
| 10:25:53 | dtantsur | totally | |
| 10:26:06 | dtantsur | sshnaidm: do we need to schedule a virtual meetup for that? given how less and less likely the PTG is... | |
| 10:26:41 | sshnaidm | dtantsur, yeah, I think it's good to do | |
| 10:26:54 | sshnaidm | dtantsur, tbh I don't believe ptg will happen in June | |
| 10:27:00 | sshnaidm | maybe only virtual one | |
| 11:04:37 | openstackgerrit | Dmitry Tantsur proposed openstack/openstacksdk master: baremetal: fail-less mode for wait_for_nodes_provision_state https://review.opendev.org/712637 | |
| 11:04:39 | dtantsur | sshnaidm: the final one (testing welcome) ^^^ | |
| 11:06:38 | sshnaidm | dtantsur, ack, will try to test it today | |
| 11:44:24 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/python-openstackclient master: Add "fields" parameter to ListSecurityGroup query https://review.opendev.org/710825 | |
| 13:18:53 | BakaKuna | ||
| 13:18:53 | BakaKuna | I'm probably missing something in the documentation, but maybe someone can help. When I try to commit a change on dhcp_agent I get the error that 'AttributeError: 'Session' object has no attribute 'default_microversion'. I have set the microversion in my env variables as OS_NEUTRON_DEFAULT_MICROVERSION=2, but that is not used apparently. | |
| 13:46:19 | openstackgerrit | Jose Castro Leon proposed openstack/python-openstackclient master: Allow os quota list query to filter by project https://review.opendev.org/712678 | |
| 14:07:41 | bverschueren | gate tests failed for https://review.opendev.org/#/c/688353/ due to the aggregate functional test, but it is rebased now after the fix and should be fine | |
| 14:07:58 | bverschueren | if anyone could have a look ? | |
| 14:40:29 | mordred | if anyone sees BabaKuna, the env var woudl bs OS_NETWORK_DEFAULT_MICROVERSION | |
| 14:42:47 | BakaKuna | mordred: thanks! I'll try that. Have to go work at home now. | |
| 14:43:10 | mordred | BakaKuna: cool - let me know if it still doens;'t work | |
| 14:43:28 | mordred | oh - also - "2" isn't a microversion | |
| 14:45:05 | mordred | slaweq: does neutron have microversions now? | |
| 14:48:23 | bverschueren | thanks mordred smcginnis ! | |
| 14:54:23 | mordred | dtantsur|brb: if we were to do an SDK v2 (hahaha assuming we ever tag a v1) - I'd totally have methods return a Future if wait wasn't true | |
| 14:55:02 | mordred | dtantsur|brb: or even just have two methods - one that is wait=False that returns a future and one that is wait=True which calls the first and does the wait and returns the object | |
| 15:07:16 | openstackgerrit | Igor Malinovskiy proposed openstack/python-openstackclient master: Add 'subnetpool' type support to rbac commands https://review.opendev.org/712705 | |
| 15:39:13 | slaweq | mordred: hi, nope | |
| 15:39:22 | slaweq | mordred: we still have only those API extensions | |
| 15:39:56 | slaweq | amotoki was going to propose some spec about microversions for extensions but I don't think he worked on it recently | |
| 15:42:28 | mordred | slaweq: ok. so does BakaKuna's question above make any sense? | |
| 15:46:28 | slaweq | mordred: TBH it looks more like some bug in SDK code | |
| 15:47:18 | mordred | yay | |
| 15:50:58 | noonedeadpunk | hi everyone. Need some help to understand how CLI commands are "routed". Like `openstack image add project` | |
| 15:51:41 | noonedeadpunk | I kinda feel that there's some "bug" there but can't really find "entry point" | |
| 15:52:32 | noonedeadpunk | It looks like https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/image_members.py#L55-L60 but can't find how it's called | |
| 15:53:12 | noonedeadpunk | The thing is that I suggest, that while searching for member_id there's exception handling missing | |
| 15:55:46 | noonedeadpunk | so while doing `openstack project list` error handling is preset like http://paste.openstack.org/show/790616/ | |
| 15:57:10 | noonedeadpunk | but `openstack image add project` ends up that way: http://paste.openstack.org/show/790617/ | |
| 15:57:46 | dtantsur | mordred: good idea. let's live to see v1 first :) | |
| 16:00:20 | elmiko | API SIG office hour now open \o/ | |
| 16:00:23 | mordred | noonedeadpunk: look in setup.cfg at the entrypoints | |
| 16:00:35 | mordred | noonedeadpunk: you'll see one called "image" - which will point you in the right direction to start tracing | |
| 16:01:10 | mordred | noonedeadpunk: I'm sorry - you'll find one called "image_add_project" | |
| 16:02:03 | noonedeadpunk | mordred: oh, nice! thanks | |
| 16:02:44 | mordred | noonedeadpunk: we just recently landed the patch to replace the calls to glanceclient with calls to sdk - but I don't think I've cut a release with that code yet | |
| 16:03:09 | mordred | noonedeadpunk: so you might want to start with trying to see how it goes with the code in master since it's RADICALLY different for image | |
| 16:03:29 | noonedeadpunk | mordred: so do you suggest trying out master version before futher investigation? | |
| 16:03:33 | mordred | yup | |
| 16:03:36 | noonedeadpunk | yeah, ok | |
| 16:04:27 | dtantsur | o/ | |
| 16:05:12 | mordred | oh - actually | |
| 16:05:35 | noonedeadpunk | tbh, image_add_project & image_member_list & image_remove_project pretty confising, because they point to the same api path, but are so different for CLI.... is there alias support? Like, can be `image_member_add` safely added for deprecating older one later? | |
| 16:05:46 | mordred | noonedeadpunk: those aren't landed yet - https://review.opendev.org/#/c/699416/ ... you might want to grab that change and try with that | |
| 16:06:06 | noonedeadpunk | mordred: oh, thanks ffor providing patch:) | |
| 16:11:00 | noonedeadpunk | patch do not resolve issue, infortunatelly | |
| 16:11:17 | mordred | ok. well - good to know at least | |
| 16:11:43 | mordred | noonedeadpunk: if you find a fix - do it on top of that stack - just so we don't hit weird merge conflicts | |
| 16:12:33 | noonedeadpunk | yes, sure:) | |
| 16:21:15 | openstackgerrit | Merged openstack/openstacksdk master: Add support for additional volume backup options https://review.opendev.org/688353 | |
| 16:22:41 | elmiko | dtantsur: given the consolidation efforts that have been discussed recently, and the low traffic of sig-api acitivity. i wonder if it's time that we re-evaluate ourselves a little? or perhaps consider a next phase for the sig, what do you think? | |
| 16:22:59 | dtantsur | elmiko: I was actually about to propose us to merge with someone.. SDK? | |
| 16:23:17 | dtantsur | because realistically, we're not doing anything except for trolling each other for quite a while :) | |
| 16:25:26 | elmiko | right | |
| 16:25:40 | elmiko | i think merging into sdk would be great | |
| 16:26:13 | elmiko | is there a chair or something we should talk to in the sdk group? | |
| 16:26:31 | elmiko | or maybe i should just make an email to discuss ml about this? | |
| 16:28:32 | dtantsur | elmiko: well, mordred? | |