19:01:19 #startmeeting OpenStackClient 19:01:20 Meeting started Thu Jul 16 19:01:19 2015 UTC and is due to finish in 60 minutes. The chair is dtroyer_zz. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:23 The meeting name has been set to 'openstackclient' 19:01:26 Who is here today? 19:01:32 dtroyer_zz: half here 19:01:35 o/ 19:01:37 * shaleh raises hand 19:01:53 stevemar: I hope it is the pretty half 19:01:59 dtroyer_zz: bknudson is around too, and pushing patches 19:02:16 o/ 19:02:17 hi 19:02:28 ping: lhcheng, sigmavirus24 19:02:33 keystone meetup! 19:02:44 Oh! Say hi to the gang! 19:02:44 conversation here is uninteresting 19:03:01 bknudson: nice 19:03:09 bknudson: yeah, little bit 19:03:09 #topic reviews 19:03:43 I suppose the starting point might be WTF is going on? I haven't had a chance yet to dig into the test failures, has anyone else? 19:04:00 no 19:04:07 I tried to use devstack to install and it didn't work. 19:04:10 * sigmavirus24 didn't know there was a failure =P 19:04:20 I think due to https://bugs.launchpad.net/python-openstackclient/+bug/1475127 19:04:20 Launchpad bug 1475127 in python-openstackclient "Cannot manipulate group member by ID" [High,In progress] - Assigned to Steve Martinelli (stevemar) 19:05:33 yeah, the recent devstack patches to use keystone v3 only kinda murked things up 19:06:01 dtroyer_zz: i brought this up yesterday and you thought i was crazy! 19:06:06 that's what I was wondering. did it to this across the board? 19:06:21 is this what you were asking? I couldn't duplicate it here 19:06:42 you'll only hit it if its osc master + devstack master 19:06:47 it's passing domain_id=None to groups.get(), but that function only takes a group parameter 19:06:49 so CI is fine 19:07:00 (well, not _our_ CI) 19:07:02 oh, right 19:07:23 http://git.openstack.org/cgit/openstack/python-keystoneclient/tree/keystoneclient/v3/groups.py#n81 19:07:23 then I suppose that's the priority for this afternoon… 19:07:28 that's the groups.get() call 19:08:04 http://git.openstack.org/cgit/openstack/python-openstackclient/tree/openstackclient/common/utils.py#n29 19:08:14 so the dueling reviews, face-off in 10 minutes? ;) 19:08:20 there's find_resource, which would call manager.get(name_or_id, **kwargs) 19:08:57 dtroyer_zz: basically, the find_resource call (or the refactoring we did a while ago, find_group_resource) changed the way .get() and .find() are called with UUIDs 19:09:02 so if kwargs has domain_id=None, it calls get('uuid-jdsfkdsa', domain_id=None) 19:09:05 it ended up doing this: GET /v3/users?name=f84f7276f2ae4e068869d9e5afd433ed 19:09:09 which is silly pants 19:09:32 dtroyer_zz: both fix it, just at different layers 19:09:42 dtroyer_zz: you can decide which fix you like better :P 19:10:03 find_resource is considering any exception from manager.get(name_or_id, **kwargs) to mean "resource not found" 19:10:04 ok, at a glance I don't know yet…will dig in after the meeting 19:10:07 which hides the actual error 19:10:32 that sounds bad, bknudson is in the lead now ;) 19:10:32 the actual error was that .get() was called with an invalid parameter 19:10:39 yep 19:10:47 I didn't try to fix that 19:10:55 bknudson: slacker 19:11:07 so then I still have to actually read both reviews? 19:11:35 what other reviews need attention here? 19:11:44 dtroyer_zz: it'll be cool, i already approved mine, to get the gate unstuck (and i did this early in the morning) 19:11:49 it's interesting that the manager.get(int(name_or_id), **kwargs) case has special exception handler but manager.get(name_or_id, **kwargs) just skips 19:12:05 bknudson: you're more than welcome to fix it :D 19:12:12 maybe the exception handlers should be the same. I'll propose a patch! 19:12:56 dtroyer_zz: so, a cool review that was recently merged 19:13:01 bknudson, sounds like an easy one to review! add me as a reviewer!!! 19:13:05 thanks to shaleh: https://review.openstack.org/#/c/201258/ 19:13:24 now --help | -h works 19:13:35 I like good UX :-) 19:13:52 I have some more ideas to propose once I get 'image create' working properly 19:13:54 yes! thanks shaleh. and it was a cliff fix 19:14:32 dtroyer_zz: logistically, i kept the bug attached to OSC too, so we remember to release a new cliff before we release OSC 19:14:44 dtroyer_zz: another recent cliff change: https://review.openstack.org/#/c/202053/ 19:14:50 moar UX! 19:15:11 I was actually thinking of writing that patch when I saw the review land 19:15:24 if you type $ openstack user foo 19:15:35 stevemar Need moar UX!!! keep going!!! 19:15:41 it'll spit out other `openstack user` commands instead of non-sense 19:15:41 ah, that's where that came from! I saw it when testing the help bit 19:16:07 dtroyer_zz: terrylhowe and i were waiting for you and/or dhellmann to be cool with it 19:16:45 I didn't realize it was sitting there… conceptually I am, will look after the other thing 19:16:56 dtroyer_zz: it landed yesterday? 19:17:00 both nice fixes 19:17:03 err.. arrived 19:17:04 my queue polling has been dropping packets lately 19:17:18 dtroyer_zz: nah, it showed yo 24 hrs ago :P 19:17:48 stevemar: I'll be looking at it later today 19:18:04 dhellmann: ty sir! you're a gentleman and a scholar 19:18:40 so in https://review.openstack.org/#/c/198506/ Roxana makes a point about starting with interface and changing to endpoint-type (I may have prompted that). evidently only Identity uses 'interface'. Do we still want to make that change? I'm waffling now… 19:19:05 i thought i approved that 19:19:19 no +A yet 19:19:29 i like interface since it makes jamie happy :P 19:19:43 and staying consistent with KSC is good 19:19:53 Roxana just wants her patch to land and be done :-) 19:19:54 we have been giving Jamie plenty of grief ;) 19:20:09 terrylhowe: does the SDK have a single usage internally for this? 19:20:16 I have a change in occ for that 19:20:22 shaleh: i already apologized to roxana in person at keystone mid cycle! 19:20:29 stevemar: :-) 19:20:41 the sdk should probably go to interface. It is using endpoint_type now. i think I made a bug for it already. 19:21:05 it's me too, I've basically had a mental cache flush (and will again in a few weeks) 19:21:34 terrylhowe: ok, if you are confident that is going to happen, we need to be consistent there for sure 19:21:35 empty caches are good sometimes 19:21:55 yeh endpoint_type->interface will happen in sdk 19:22:11 ok, then I'm back on-board with it here too 19:22:14 in occ Monty just asked for a minor change in the backward compat 19:22:45 dtroyer_zz: aside from those, theres a whole whack of functional tests being added by some dude 19:22:55 i tried to keep up, but he's cranking them out 19:23:05 same here stevemar 19:23:17 how do they look? consistent with the way we've been doing them? 19:23:25 I havne't looked at them at all yet 19:23:43 dtroyer_zz: yep, i weighed in heavily on the early ones 19:23:50 ok, good 19:23:51 but all subsequent ones are looking good 19:24:40 he's also going around adding --project-domain | --user-domain | --group-domain to the few spots we missed 19:25:03 cool 19:25:11 any other reviews for attention? 19:25:40 a few image related ones are up, haven't reviewed them yet 19:26:51 not counting network, and after volume v2, image v2 needed the most love… 19:27:24 #topic bugs 19:27:55 dtroyer_zz: volume v2 is pretty awesome now btw 19:28:01 abhide did great work there 19:28:12 https://bugs.launchpad.net/python-openstackclient/+bug/1472909 looks interesting… is this a case of OSC not doing the name -> ID translation properly? 19:28:12 Launchpad bug 1472909 in python-openstackclient ""role assignment list" fails if two users in different domains have the same name" [Undecided,New] 19:28:14 image v2 has a few patches now 19:28:27 I’ll be back on network once this next sdk release goes out (this week soemtime) 19:28:33 dtroyer_zz: oh maybe 19:28:50 might have been... 19:28:58 err, 'might be' 19:29:02 that's the only reason I can think of why it might not be a server-side problem… 19:29:25 I'm not sure how to corss domains from the API intentionally 19:31:33 it looks like there are a couple of bugs connected to o-c-c 19:31:54 whoever mentioned doing a release there soon is right... 19:32:08 yep! 19:32:18 * dtroyer_zz too lazy to scroll back 19:32:26 we should do one soonish 19:32:30 any other bugs? 19:32:56 once the gate is fixed, and we push a few bug fixes 19:33:37 #topic open discussion 19:33:45 so, speaking of releases… 19:33:57 a) occ gets one soon, then… 19:34:07 b) osc gets one following 19:34:26 cliff should get one when we land that second ux patch 19:34:27 err not quite 19:34:30 cliff gets one too 19:34:48 dhellmann: knows whats good 19:34:59 I think it would be goood to get the image work finished now before doing another release 19:35:05 re cliff: agreed 19:36:15 and we have a new process for doing the releases. dhellmann, would it be helpful if we do depends-on in those reviews to set order? 19:36:24 dtroyer_zz: i think we can say we have volume v2 support now: https://github.com/openstack/python-openstackclient/blob/master/setup.cfg#L378-L405 19:36:49 dtroyer_zz: some of the repos from the team aren't being managed, so we should talk about that, too 19:37:04 does the order matter? 19:37:05 dhellmann: hmm? which repos? 19:37:08 hmmm…. I saw cliff in there, so occ? 19:37:17 yeah, occ is release:independent 19:37:25 order only in that cliff and occ need to come before osc 19:37:40 dtroyer_zz: ok, you could just submit them as a series of patches 19:38:00 ah, right, that would be easier to follow 19:38:10 yeah, depends-on is only needed for cross-repo things 19:38:16 oh more open discussion 19:38:29 and it's possible we'll disallow those for releases, to avoid having people try to ask for a release of something that hasn't merged 19:38:33 abhide asked me if i had a bp he could work on 19:38:53 i told him to do this: https://blueprints.launchpad.net/python-openstackclient/+spec/global-limits 19:39:26 ooo fun 19:40:24 shaleh: looking through the BP's, there is https://blueprints.launchpad.net/python-openstackclient/+spec/image-member that applies to the image stuff you are working on…go ahead and reference that and we can close it when the image create is finished 19:40:34 should that bp have —marker? 19:40:45 dtroyer_zz: shall do 19:40:47 dtroyer_zz: i was going to say, i plan on marking some BPs are obsolete, ceilometer/heat/trove/sahara/magnum/manila plugin bps 19:40:51 err, image member or whatever it is called 19:41:08 stevemar: go for it 19:41:11 ty 19:42:48 any other things to discuss? 19:43:02 dtroyer_zz: there we go, we lost some weight there: https://blueprints.launchpad.net/python-openstackclient 19:43:31 dtroyer_zz: i'm in a `go-through-bps` mood 19:44:09 dtroyer_zz: https://blueprints.launchpad.net/python-openstackclient/+spec/api-list 19:44:16 dtroyer_zz: want help on that? 19:45:20 shaleh: I did that three times already and none of them really worked right due to the wide variances of server response. 19:45:47 OSC has a hack in it for mis-configured keystone but the rest are still sitting in a branch somewhere 19:46:00 oh oh, before i forget... 19:46:14 dtroyer_zz: really need your input on this one 19:46:14 I think the ideal solution is to generalize it into the SDK 19:46:32 and handle the project-specific hacks there 19:46:41 we are nuking the keystone CLI very soon, when we release keystoneclient 2.0 19:46:48 \o/ 19:46:56 bknudson had some remarks about morgans work: https://review.openstack.org/#/c/196297/3 19:47:15 if you could check PS3, and brants comments... that would be great 19:47:15 I left a comment there this morning 19:47:26 i think brant it crazy, but that's not unusual 19:47:45 on the specific one you posted… 19:48:42 in general, OSC has tried to avoid using the oslo-config based arg handling, so I'm of the opinion that removing that should hurt us. it might affect others... 19:48:53 er, shouldn't hurt us 19:48:55 should or shoudln't 19:48:59 ok cool 19:49:45 do you have plans to set any version caps anywhere before 2.0 is released? 19:49:53 or find the breakage then? 19:50:10 not sure, gotta ask morgan 19:51:35 ok sports fans, anything else today? 19:51:55 nada 19:52:09 just a whole bunch of patches to push through 19:52:45 terrylhowe: yeah 19:53:02 once we get our open patch queue to something reasonable we should push for a release 19:53:22 all these gate problems have made things tough 19:53:41 terrylhowe: yeah, at least we have fixes in place now 19:53:43 yes. I may not have time to do that next week, but with the current processes that is basically pulling together release notes in the docs 19:53:48 yep 19:54:16 dtroyer_zz: that's all i got 19:54:20 dtroyer_zz: wrap it up! 19:54:29 ok, we'll call it a day then 19:54:33 #endmeeting