19:00:41 #startmeeting python-openstacksdk 19:00:42 Meeting started Tue Jun 2 19:00:41 2015 UTC and is due to finish in 60 minutes. The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:46 The meeting name has been set to 'python_openstacksdk' 19:00:48 o/ 19:01:02 if you're here for the SDK meeting, say hi 19:01:13 hi 19:01:14 etoews: did you end up putting together an agenda? i just came out of that interview 19:01:16 o/ 19:01:22 yep 19:03:11 on my side of things, i'm just trying to clear out the review queue before digging into any new work (plugins next) 19:06:29 etoews: what all is necessary to get messaging moving along? do you need help beyond reviews or do you pretty much have it? 19:06:49 #link https://review.openstack.org/#/c/187020/ 19:07:04 o/ 19:07:17 i replied to a few comments from terrylhowe. did you want to discuss those further terry? 19:07:41 I just saw your reply. might take a while to digest 19:08:59 understood. 19:09:20 can i offer a digestif? :) 19:10:43 etoews: I think I am starting to see how you ended up with that model, just trying to eliminate other solutions to get there. 19:11:23 I see your points. Makes me wonder if we should have a Message resource at all. 19:11:46 or if create_messages should just be a method of queue 19:12:06 Is there something resourcey to do with the thing? 19:13:23 terrylhowe: all sorts of stuff https://wiki.openstack.org/wiki/Zaqar/specs/api/v1#Messages 19:14:14 okay, fair enough 19:14:54 do we need to cut a release soon with this stuff so it is ready for the demo? 19:15:33 i'm not expecting that. i can have the student install from git. 19:15:45 s/student/students/ 19:15:52 pip install from git that is 19:16:06 excellent, not sure what state things are overall 19:17:26 anything else on that? 19:17:58 nope. i expect the development on the stuff i need will come down to the wire. i think a pip install from git is the only reasonable way. 19:18:27 one more question on the messages resource. 19:18:42 'age' property decays as soon as the message leaves the server, is there any reason to also track an optional timestamp property for when the message was retrieved from the server to allow true age to be tracked by clients? maybe a calculated expiry based on ttl, and and the timestamp? 19:20:41 i'm not 100% sure what you're asking. are you talking about adding another property to Message? 19:21:35 I guess it would be a transient property 19:22:17 I suspect it just wouldn't be needed 19:22:34 without a well defined use case and some feedback from a user, i'm reluctant to add any transient props. 19:22:43 ys 19:22:45 ya 19:23:56 should we move on? 19:24:09 please 19:24:15 go ahead 19:26:06 i'd also like to talk about Add Heat resource support #link https://review.openstack.org/#/c/181063/ 19:26:57 is qiming around? 19:27:19 i don't know that i've ever seen him on irc... 19:27:33 I haven’t 19:27:54 he was in yesterday asking about functional testing, but it was pretty late US time i believe 19:28:17 etoews: i need to think about that exception versus empty list since that call is a combination of things now 19:28:27 well anyway...i ran the functional tests on his latest patch set 5 and they failed with the same error as on patch set 4. 19:28:29 it was originally returning None which it cant do 19:29:18 it would be good if someone else could run the functional test TestStack against his work, to double check. 19:29:36 i'll check it out, i hadn't gotten around to running functional tests myself in teh mad rush up to the summit 19:29:40 briancurtin: ya. that needs to be resolved too. 19:29:51 understandable. 19:30:54 i'm just not going to have anymore time until after the qcon workshop to put towards that review and functional testing. 19:31:15 etoews: i'll take a look, you go back to doing the messaging stuff 19:31:22 thx 19:32:27 should be able to run ‘check experimental’ still 19:33:06 there, give it 25 minutes or so 19:33:23 terrylhowe: cool! 19:33:50 I have a change out in project-config for a non-voting check 19:34:11 that's awesome. thx for doing that. 19:34:15 hope everyone is okay with the 25 minute delay on patches 19:34:19 where do i go to vote? 19:34:24 :) 19:34:48 https://review.openstack.org/#/c/184621/ 19:35:06 I don’t want to hijack the heat discussion though 19:35:11 i'm also +1 on the non-voting. too many transient failures when it comes to devstack. 19:36:41 not hijacking. i'd say this is very relevant to the heat discussion. 19:37:27 anythoughts on the stack_name and stack_id in the resource? 19:39:23 so if you were to add those to Resource, wouldn't they get serialized to json if you did a resource.create()? 19:40:20 hmm, probably. They shouldn’t 19:40:49 in this particular case, it's a moot point. http://developer.openstack.org/api-ref-orchestration-v1.html#stack-resources 19:41:48 in general that's still an issue any time we put extra props on a resource. 19:42:06 then you wind up have to do a custom json encoder 19:42:07 I think there is special code briancurtin added to covert props of type=resource to resource_id in the body 19:42:37 yeah there's just a quick loop through the _attrs converting them back and forth to IDs, or something like that iirc 19:42:57 i expect that's fine in most cases 19:43:08 i don't trust the APIs though 19:43:54 yeah, no resource instance should hit that (would blow up anyway in setting up the URL) 19:48:00 i might be missing something, but is there an issue that has happened or would appear to happen around those? 19:51:35 briancurtin: there was some back and forth on those when it came to modeling Stack. 19:51:44 we wound up with 19:51:45 name_attribute = 'stack_name' 19:51:52 name = resource.prop('stack_name') 19:52:00 oh, that 19:52:23 i was thinking when you do resource.prop("blah", type=mytype.MyType) 19:52:52 heat is different in that the stack name is unique and you can use it to get redirect to the id. 19:53:26 /v1/​{tenant_id}​/stacks/​{stack_name}​/​{stack_id}​ 19:53:30 i guess i'll have to refresh on that 19:53:39 * flaper87 just saw Zaqar being mentioned here. Are you guys adding support for it in openstacksdk? (there's some support in the zaqarclient repo) 19:53:54 (sorry for the hijack) 19:53:56 * flaper87 stfu 19:54:16 flaper87: i'm adding support for it to the openstacksdk 19:54:19 flaper87: yep, there's some in there now and building up 19:54:59 flaper87: i saw the message on the list. your intern should work on the openstacksdk and openstackclient instead :) 19:55:00 etoews: briancurtin awesome, not sure if you're aware of https://github.com/openstack/python-zaqarclient/blob/master/setup.cfg#L47-L54 19:55:31 FWIW, zaqarclient is a pure python library with no CLI support 19:55:39 we've been relying on the openstacksdk since the get-go 19:55:54 flaper87: cool. 19:56:44 etoews, ++ 19:56:44 flaper87: what does code from your github link do exactly? 19:57:20 etoews: those are the entry points that openstacksdk uses to load the zaqar code that has support for CLI actions 19:57:32 openstackclient entry points rather 19:57:43 terrylhowe: ah, mmh, yeah. That. 19:58:08 flaper87: cool. when does that land in osc (openstackclient)? 19:58:42 people would just install zaquarclient and it will show up 19:58:44 etoews: we could move that code there, I guess. That code landed when incubation was still a thing 19:59:03 but yeah, if openstackclient is install and ppl install zaqarclient, that will just show up 19:59:14 i had no idea. 19:59:18 etoews, magic of entry points 19:59:21 i'll try that 20:00:02 time's up for the meeting, can head back to -sdks to continue. thanks all! 20:00:05 #endmeeting