Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-04-20
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 ?
17:21:29 edleafe rukh: since this is Python, yes
17:21:59 edleafe rukh: Also, when posting more than a line or two of code, using a paste service helps make the code more readable
17:22:08 edleafe and doesn't clutter the channel
17:22:16 rukh edleafe, apologies..
17:22:18 openstackgerrit Dean Troyer proposed openstack/osc-lib master: Add token auth test https://review.openstack.org/458597
17:22:24 edleafe rukh: no worries
17:22:46 dtroyer_zz stevemar: can you look at ^^^ and the associated revert if you have a minute?
18:15:59 openstackgerrit Carlos Goncalves proposed openstack/python-openstacksdk master: Add data plane status support to Network Port obj https://review.openstack.org/458608
18:47:22 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Correct auth issue in master os-client-config" https://review.openstack.org/458615
18:57:37 openstackgerrit Merged openstack/python-openstacksdk master: Add data plane status support to Network Port obj https://review.openstack.org/458608
19:20:38 openstackgerrit Carlos Goncalves proposed openstack/python-openstackclient master: Add 'data_plane_status' option to Port classes https://review.openstack.org/458626
20:11:37 openstackgerrit Merged openstack/keystoneauth master: Updated from global requirements https://review.openstack.org/455926
20:18:09 openstackgerrit Merged openstack/osc-lib master: Revert "Avoid to authenticate twice" https://review.openstack.org/458586

Earlier   Later