Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-04-20
10:48:23 openstack Launchpad bug 1676298 in python-openstackclient "Need to remove usage of novaclient.v2.security_group_rules" [High,Confirmed] - Assigned to Dean Troyer (dtroyer)
10:48:23 Andrew_jedi hello folks, openstack client 3.9 is throwing exception while trying to add a "security group rule". This is the bug report https://bugs.launchpad.net/python-openstackclient/+bug/1676298. And this is the fix https://github.com/openstack/python-openstackclient/commit/4289ddd47a9c92eb3033eccf39966915caae05db#diff-b811fca43423b66e081e0d0843104450. Could you please let me know when the next...
10:48:39 Andrew_jedi ...version of openstackclient will be uploaded to pip?
11:05:09 openstackgerrit Stephen Finucane proposed openstack/python-openstackclient master: Start using 'cliff.sphinxext' https://review.openstack.org/452861
11:05:10 openstackgerrit Stephen Finucane proposed openstack/python-openstackclient master: Convert 'server' commands to use autoprogram https://review.openstack.org/458452
11:44:13 openstackgerrit Rui Chen proposed openstack/python-openstackclient master: Make block-device-mapping more stable and clear https://review.openstack.org/438141
12:14:31 dtroyer_zz Andrew_jedi: this is due to the release of python-novaclient 8.0 which removed all nova-net support. The next release of OSC will contain replacements for that functionality, it is still in the pipeline with one remaining thing to address. If yo can use the master branch it shold work for you now
12:14:59 dtroyer_zz or you can downgrade python-novaclient to 7.1.0
12:15:23 Andrew_jedi dtroyer_zz: splendid, thanks for letting me know !
12:22:18 rabel dtroyer_zz: I'm not sure if I can attend the meeting today. Could you have another look at https://review.openstack.org/#/c/444924/ (ready for merging I think) and https://review.openstack.org/#/c/449707/ (your opinion as mentioned by Julien Danjou's comment)?
12:49:49 rabel dtroyer_zz: meeting in 11 minutes?
13:03:03 rabel :(
13:19:47 briancurtin rukh: can you share some code that shows what you’re doing? i can’t really tell you whats wrong if i don’t know what you’re doing
13:20:17 rukh briancurtin, thanks so much for pinging me to help.. I figured it out though .. thanks so much
13:44:50 rukh briancurtin, if u have a sec .. looking for what I am doing wrong in this seemingly simple 2 line code
13:44:51 rukh https://pastebin.com/c6FKtamz
13:56:36 briancurtin rukh: that resource_name argument on the end is extra. if you take that off it should work
14:21:23 rukh print(resources)
14:21:23 rukh resources= self.conn.orchestration.resources(stack)
14:21:23 rukh briancurtin, I didn't understand why .. but I took it off and tried this: stack = self.conn.orchestration.find_stack(self.configs.plan)
14:21:38 rukh <generator object list at 0x2a37d70>
14:22:03 briancurtin rukh: yeah, the list related calls return generators. you need to consume the generator to see its contents
14:22:08 rukh I guess I don't understand how to consume a generator (again I started on python + sdk 2 days ago so my questions might be super dumb)
14:22:19 briancurtin something like “for resource in resources: print(resource)"
14:23:44 rukh briancurtin, that gave me some output .. is a generator = list ?
14:24:03 briancurtin they look like lists in some forms, but a generator is very different
14:24:34 briancurtin rukh: this might help: https://jeffknupp.com/blog/2013/04/07/improve-your-python-yield-and-generators-explained/
14:24:38 rukh I am thinking it is python specific.. if you don't mind can I pm u ? Its just a gen question about python and ur path ?
14:24:58 briancurtin sure
14:29:24 rabel dtroyer_zz: Could you have a look at https://review.openstack.org/#/c/444924/ ? I think it's ready for merging.
14:34:24 rukh briancurtin++
15:56:07 stevemar dtroyer_zz: https://review.openstack.org/#/c/454613/4 didn't make the 2.6.0 cut btw
15:56:21 stevemar dtroyer_zz: regarding https://review.openstack.org/#/c/438141/12
15:59:59 dtroyer_zz well then…
16:18:29 openstackgerrit OpenStack Proposal Bot proposed openstack/keystoneauth master: Updated from global requirements https://review.openstack.org/455926
16:18:46 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: DNM: Enable debug in functional tests https://review.openstack.org/458579
16:24:55 edleafe cdent: elmiko: Ready for review: https://etherpad.openstack.org/p/api-wg-newsletter
16:25:58 elmiko edleafe: i like the tongue-in-cheek style +1
16:25:59 cdent "as to their status"
16:26:13 cdent is them there good english, what?
16:26:22 cdent :ship it:
16:26:46 edleafe you want gooder english?
16:26:52 cdent naw mate
16:29:28 mordred edleafe, cdent: I made a document you might find interesting: https://review.openstack.org/#/c/458565/
16:30:07 cdent mordred: oh dear. shouldn't you be on a bull or something?
16:30:12 mordred edleafe, cdent: I don't _think_ it's appropriate for inclusion in an API-WG repo in a more general form - but it does describe a general algorithm for dealing with discovery
16:30:24 mordred cdent: why would you get the idea that I'm not on a bull
16:30:26 mordred ?
16:31:14 cdent because, though you are a talented person, version discovery is so complex that anyone who is attempting to comprehend it, while on a bull, is no longer on the bull
16:32:06 edleafe mordred: ok, will review and add some acerbic comments
16:32:13 mordred cdent: maybe it would be proof of my acumen if I could perform version discovery correctly whilst upon a bull?
16:32:19 mordred edleafe: sweet!
16:32:24 mordred or, sour perhaps
16:32:50 cdent (and yes, I reckon not for api-wg repo because we want to describe how things should be (although some state of the are description used to be the norm))
16:32:58 edleafe mordred: definitely bitter
16:32:58 mordred cdent, edleafe: also have a followup patch which has thoughts on how we're going to consume microversions in shade
16:33:00 cdent mordred: I think you've figured out your next keynote presentation
16:33:08 mordred cdent: zomgyes
16:33:22 cdent [...] on a bull!
16:33:34 mordred they did not accept my talk for this summit about making BBQ
16:33:51 mordred I'm starting to think I can't get talks on absurd topics accepted purely on name recognition!
16:33:52 cdent making BBQ while on a bull smacks of ethics violation
16:35:07 edleafe yes, too recursive
16:35:19 edleafe unless you are barbecuing a pig, of course
16:35:30 openstackgerrit Dean Troyer proposed openstack/osc-lib master: Revert "Avoid to authenticate twice" https://review.openstack.org/458586
16:37:18 mordred edleafe: I should figure out how to make fake beef out of pork, and fake pork out of beef - and maybe fake coleslaw out of chicken
16:40:05 dtroyer_zz mordred: I'm tackling version/microversion stuffs in OSC too, if I can ever unwind the release madness+client code removal we're in, will try to get that all back into my head this afternoon to compare notes
16:40:23 dtroyer_zz I don't mind duplicating the REST bits, we're doing different things there, but let's make only one of these
16:40:29 edleafe cdent: elmiko: so do you think that adding an email address field to the liaisons.json file is worthwhile?
16:40:51 mordred dtroyer_zz: yah - so I started working on some patches for keystoneauth yesterday
16:40:59 mordred dtroyer_zz: because ksa actually does some of this already
16:41:00 cdent edleafe: it can be useful, but i think it is also possible to extract it from gerrit using the name?
16:41:07 cdent so I dunno
16:41:32 dtroyer_zz mordred: right, I have some bits too that are not yet proposed… distilled from the <sorry> nova & cinder clients
16:41:33 mordred dtroyer_zz: however, I'm not 100% sure I can sell the whole thing at the ksa layer, becaues it starts to get a smidge invasive
16:41:55 mordred dtroyer_zz: maybe if we can at least come to a general agreement on what the overall algorithm should be
16:41:57 dtroyer_zz it does. I think jamielennox is on-board for some of the lower-layer stuff, but not all of it
16:42:13 mordred we can then figure out how much can live in ksa and now much is impl specifics for shade/osc
16:42:15 edleafe cdent: maybe - haven't played much with the gerrit API
16:42:36 mordred dtroyer_zz: please tell me whence you find one!
16:53:20 mordred dtroyer_zz: but any way - if you could find time to look at that shade doc patch and see if you disagree on any fundamental points, that would be cool
16:53:51 mordred dtroyer_zz: I could potentially do a pass through it to talk about it in terms of general discovery and then how shade specifically wants to interact with such a thing
16:53:59 mordred if it winds up being too shade-centric
16:54:56 dtroyer_zz I'm curious to see how similar we want to handle versions, the discovery should be close, it's the philosophy on using microversions that may be different
16:55:22 dtroyer_zz I want to let each command make that decision as much as possible
17:04:47 mordred dtroyer_zz: yes. that's exactly how I want to handle microversions
17:05:20 mordred but I left microversions as a followup document, since the thing I actually need to solve in shade soon is a more generic major version discovery
17:06:12 mordred dtroyer_zz: oh - also, one of the goals of the process/approach in that document is to allow us to get rid of the default values for api versions in occ
17:06:36 dtroyer_zz \o/
17:06:52 mordred doing that curently would screw some things, but if I can get generic discovery working consistently and overridably when needed, then we can get rid of them
17:07:31 mordred (which is one of the things that I think will wind up being invasive ksa-side - currently it'll handle doing discovery, but you have no idea what version it actually discovered)
17:09:04 openstackgerrit Merged openstack/cliff master: Add smart help formatter for command parser https://review.openstack.org/454613
17:17:51 stevemar dtroyer_zz: shouldn't be a big deal about missing that one, Rui's patch only refactored things right?
17:18:24 rukh ping openstack-sdks: Looking at this https://developer.openstack.org/sdks/python/openstacksdk/users/resources/orchestration/v1/resource.html#openstack.orchestration.v1.resource.Resource I was able to get the physical_resource_id for the "Controller" resource and I think must be additional resources associated with this physical id .. I see the class this inherits from has a list() function. but I don't think I can access it like this:
17:18:26 rukh resources = self.conn.orchestration.resources(stack)\
17:18:30 rukh resources = self.conn.orchestration.resources(stack)
17:19:30 rukh resource_id = resource.physical_resource_id
17:20:02 rukh Controller)
17:20:02 rukh node = resources.get(resource_id,
17:20:53 rukh is it possible to access the base class resource members ?

Earlier   Later