19:01:52 #startmeeting openstackclient 19:01:52 Meeting started Thu Apr 14 19:01:52 2016 UTC and is due to finish in 60 minutes. The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:56 The meeting name has been set to 'openstackclient' 19:02:02 hi 19:02:03 Howdy all! Who is here? 19:02:06 hi 19:02:15 Hi guys :) 19:02:18 Hi 19:02:57 Hi, Richard, Steve, Dean 19:03:11 Hi Tang, nice to see you here! 19:03:18 hi tangchen, glad you could join 19:03:23 First time for me to join the meeting. 19:03:27 o/ 19:03:50 ok, let's get started… 19:04:00 #topic meeting time 19:04:20 I re-kicked the meeting time thread earlier this week 19:04:27 #link http://lists.openstack.org/pipermail/openstack-dev/2016-April/092160.html 19:04:52 and only rtheis replied, so I don't think we have much agreement yet... 19:06:19 tangchen: does the E.1 and O.3 times work for you? 19:06:20 I'm also OK with Wednesday at 1400 UTC 19:07:00 dtroyer: Sorry, I'd prefer 0.2 19:07:13 Wednesday at 1400 UTC 19:07:42 It is 3 am now...... 19:08:13 I don't think I can join the meeting every time at 3 am. 19:08:42 tangchen: I think the idea was to alternate so you could join every other time 19:08:53 that's why we want to alternate the times, having them all at 1300/1400 isn't much of a switch 19:09:15 that puts someone else at a bad time all of the time 19:10:09 Oh, OK. 1300 works for me. :) 19:10:39 ok, thanks. 19:10:57 I'd like to hear from sheel at least too, he brought this up to start with… 19:12:38 tangchen: could you reply to the thread please? That might bump it to the top of sheel's inbox. 19:13:10 OK, I'll reply. 19:13:12 next week is odd, so it looks like we'd keep this slot, but we should get the room booked so we don't lose it 19:13:21 and have the new time in two weeks 19:13:31 tangchen: thanks 19:13:51 dtroyer: Welcome. And thanks for the changes. 19:14:19 #topic reviews 19:14:33 anyone have reviews to bring up here? 19:15:33 Is the keystoneauth patch ready for reviews? https://review.openstack.org/#/c/276350/ 19:15:33 rtheis: patch 276350 - python-openstackclient - Moving authentication from keystoneclient to keyst... 19:16:22 * dtroyer reads stevemar's last comment 19:16:36 agreed, it doesn't merge until after the next release 19:16:45 otherwise, how does it look? 19:18:13 sorry, I lost connectivity 19:18:32 np, that's usually when it happens ;) 19:19:40 I don't have other reviews to bring up 19:20:05 I'd like to invite you to review the floating ip rework 19:20:07 https://review.openstack.org/#/c/300388/ 19:20:07 tangchen: patch 300388 - python-openstackclient - Transfer "ip floating pool list" to "floating ip p... 19:20:20 This thread. 4 of them. 19:20:34 tangchen: I want to hold off on those also until after the next release 19:21:02 and the server group chain too 19:22:19 rtheis_: is https://review.openstack.org/#/c/304826/ good now, once the deps are in? 19:22:19 dtroyer: patch 304826 - python-openstackclient - Fix client certificate/key support for Network v2 ... 19:22:34 I'd like that in before the release if possible 19:22:50 yes, once we have deps then that is good to go 19:22:56 I think I lost connectivity too.... 19:23:21 also https://review.openstack.org/#/c/300305/ before the release 19:23:22 dtroyer: patch 300305 - python-openstackclient - Append existing information during port set 19:23:37 And how about this, https://review.openstack.org/#/c/293997/ 19:23:38 tangchen__: patch 293997 - python-openstackclient - Enhance exception handling for "network delete" co... 19:23:51 I think those are the only fixes for new commands left 19:24:24 yep 19:24:41 i’d like some feedback on how to move forward with https://review.openstack.org/#/c/296582/ 19:24:42 knikolla: patch 296582 - python-openstackclient - WIP - Calls to K2K Federated Service Providers 19:24:56 tangchen__: that probably should wait until after release 19:25:07 once the change to keystoneauth merges 19:25:59 rtheis_: OK, will wait after the release. 19:27:12 knikolla: I haven't looked at that in depth, it looks like once https://review.openstack.org/#/c/276350/ goes in you'll have a bit of work to do. 19:27:12 dtroyer: patch 276350 - python-openstackclient - Moving authentication from keystoneclient to keyst... 19:27:31 you could rebase on top of that and see what changes out from under you. 19:28:09 also, —sp needs thought. 19:28:32 dtroyer, rtheis_: BTW, I never took part in the OSC release job. Would you please tell me what could I do to help ? 19:28:35 We (usually) prefix global options with —os- (and ran into some trouble with —profile because we didn't do that recently) 19:28:50 dtroyer: so —os-sp? 19:28:54 but we also rarely use abbreviations or sing letter options 19:29:02 *single letter 19:29:21 —os-service-provider is long though…other options? 19:29:25 dtroyer: well i initially had it as —service-provider, but after typing it on each single command i had to abbreviate it 19:29:30 but we have other long options too 19:30:12 dtroyer: i really feel like it should be as short as possible without breaking things 19:30:35 dtroyer: also what other things need to accompany the change? (release notes/docs?) 19:30:46 is that something that will be typed often? or set in clouds.yaml and left alone? 19:31:07 or in the environment? 19:31:15 dtroyer: i imagine it will be typed often 19:31:37 dtroyer: as there could be multiple service providers 19:31:54 dtroyer: i’m not sure if it could be inserted in clouds.yaml. i imagine it might. 19:32:06 if I'm a could user, mucking about in my VMs, do I change service providers much? 19:32:13 *cloud user 19:32:30 dtroyer: knikolla when I use my 9 regions I use --os-cloud and --os-region name 19:32:31 I have no idea the use cases here 19:32:37 not sure what service-provider is exposing 19:33:07 clarkb: service provider exposes other openstack deployments federated with keystone 2 keystone 19:33:32 seems like that would typically be in clouds.yaml 19:33:40 that's what I am thinking too 19:33:41 via the auth info 19:34:50 knikolla: the other bits we would want to see in that review are an update to the openstack man page (global option docs) and a release note 19:35:33 and somewhere a description of how it is used, or how to know if you need to use it? 19:36:05 dtroyer: i’ ll work on that part of the documentation. 19:36:17 dtroyer: but it’s something that most clouds will not make use of. 19:36:58 ok. somehow we should convey that so new users don't think it is something they always need to know 19:37:21 dtroyer: agreed. 19:37:46 any other reviews? 19:38:18 I don't have any review now. 19:38:18 nothing else from me 19:39:44 #topic bugs 19:39:55 Are there bugs that need the team's attention? 19:40:31 nothing now for me. 19:40:39 I had one thing I wanted to ask if it would be considered a bug. list image images in a script pages. So my script doesn't get a full list of images and can't properly operate on all of them without using a ridiculously large --limit arg 19:40:53 is this by design or should the paging only happen when stdout is attached to something useful? 19:40:53 tangchen__: I commented in a couple bugs you own asking if they could be closed 19:41:15 no rush on reply but would be nice to close what we can 19:41:42 clarkb: hmmm… I don't recall seeing that, it is a recent change? 19:41:49 rtheis_: OK, I didn't notice that. Will reply soon. 19:41:55 thanks 19:41:59 dtroyer: I don't think so, but I can dig up more details and file a bug if that is helpful 19:42:01 I don't think it should page without some sort of arguemnt to cause it 19:42:11 dtroyer: cool I will go ahead and file a bug 19:42:17 is that for v1 or v2 Image? 19:42:29 I believe v2 19:42:47 that may be part of it (for me anyway) 19:43:36 clarkb: I do think that forcing off paging when stdout is not a tty would be good to do in general 19:43:50 dtroyer: great will include that in the bug 19:44:06 thanks 19:45:03 any other bugs? 19:45:32 nothing else 19:46:02 #topic open discussion 19:46:17 What's on your minds today? 19:47:02 dtroyer, rtheis_: BTW, I never took part in the OSC release job. Would you please tell me what could I do to help ? 19:47:06 translation...do the docs and help get translated? 19:47:51 I noticed the network commands aren't using from openstackclient.i18n import _ 19:48:04 should they be? 19:48:32 tangchen__: the release process itself is pretty simple, one review to the releases repo asking for the tag, and a followup to the requirements repo to bump the cap 19:48:51 most of what I do is sanity-checking things like the release notes and docs 19:49:22 rtheis_: I don't think any of our text files are translated, and only the _() marked strings. 19:49:49 I'd guess that the percentage of help strings that are wrapped for translation is embarassingly small 19:50:29 so that is something we should add to the list of things to think about and do soon 19:50:43 ah! 19:50:47 dtroyer: open a bug or bp to track? 19:50:48 rtheis_, dtroyer: Sorry, I didn't know that. So should all help strings be marked with a _(), right ? 19:51:31 rtheis_: Yes, that is what I am thinking. 19:51:45 rtheis_: just one if it's a bug… 19:52:18 tangchen__: I think we've decided that only the help strings should get translated 19:52:44 dtroyer: OK. 19:52:59 dtroyer: okay, I'll open one bug 19:53:30 rtheis_: Please get me subscribed. 19:53:36 ok 19:53:41 thx 19:54:05 I'll have the etherpad for the summit session up soon, be thinking about what we should be dealing with in person in Austin 19:54:45 I will talk a little on the UX study we completed recently 19:54:52 (hint: help is a mess) 19:56:01 we have one fishbowl session, one meetup-style session immediately following the fishbowl, and Friday afternoon workgroup 19:57:00 One thing I'd like to ask, maybe it is a long work. All other commands except network are using other client now, not sdk. Will we plan to migrate them all to sdk, and abandon other clients ? 19:57:17 tangchen__: that is the long-term plan 19:57:24 unfortunately, I will only be in Austin on Monday and Tuesday 19:57:36 we used the SDK for network because those are all new commands, the others we're waiting for SDK 1.0 to release 19:57:36 dtroyer: yes 19:57:55 rtheis_: :( 19:58:07 dtroyer: OK. 19:58:35 my meeting conflict took much longer than expected 19:58:42 i'll read the scroll back :( 19:58:50 someone want to read stevemar his list of actions? 19:59:14 no wonder he'll accept any meeting time, he's booked all week anyway! 19:59:27 (the joys of being a core PTL) 19:59:48 :) 20:00:25 ok, we're at time… thanks everyone! Same time next week, then summit! 20:00:29 #endmeeting