Earlier  
Later
New Search
Posted Nick Remark
#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?
16:29:36 elmiko i should probably send an email as well, just to help promote transparency and collaboration for the decision
16:30:06 dtantsur yup
16:30:42 dtantsur mordred: we want to grant you an unlimited access to elmiko, are you happy?
16:30:49 mordred YES GOD YES

Earlier   Later