| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-04-20 | |||
| 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 | |
| 20:18:16 | openstackgerrit | Merged openstack/osc-lib master: Add token auth test https://review.openstack.org/458597 | |