13:04:05 <dtroyer> #startmeeting openstackclient
13:04:05 <openstack> Meeting started Thu Dec 15 13:04:05 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:04:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:04:10 <openstack> The meeting name has been set to 'openstackclient'
13:04:32 <dtroyer> So first off...
13:04:36 <dtroyer> #topic releases
13:04:50 <dtroyer> We released OSC 3.5.0 yesterday
13:04:54 <huanxuan> nice
13:05:02 <huanxuan> \o/
13:05:25 <dtroyer> and OSC 2.4.1 last week in the first of our stable releases
13:05:54 <dtroyer> they both contains a couple of bug fixes that were biting folk badly
13:06:17 <huanxuan> yes, I saw it
13:06:27 <huanxuan> good news!
13:06:27 <dtroyer> Unless something comes up I do not plan to do another release until early next year
13:06:41 <huanxuan> ok
13:07:08 <dtroyer> #topic reviews
13:07:58 <dtroyer> Looking through open reviews, I see only one more SDK refactor in the queue (I +2 ports this morning)
13:08:31 <dtroyer> I do not know if that is the last one, will need to look in to that.
13:09:15 <dtroyer> These need to be complete for the SDK 1.0 to be released.  I do not know if briancurtin is waiting on us for that yet, I don't think so
13:09:21 <huanxuan> I do not think it is the last one
13:09:34 <dtroyer> ok, thanks.
13:10:01 <huanxuan> https://review.openstack.org/#/c/407324/ seems like this is in progress
13:10:41 <dtroyer> right, that was the only one proposed that I found that is not approved
13:11:17 <dtroyer> are there any other reviews that we should discuss?
13:11:42 <huanxuan> I have one
13:11:46 <huanxuan> https://review.openstack.org/#/c/367673/
13:11:50 <huanxuan> purge command
13:12:08 <huanxuan> Steve and I are working on it
13:12:21 <dtroyer> cool, I have not looked at that in a while
13:12:50 <dtroyer> I will give it some attention, probably tomorrow
13:13:00 <huanxuan> ok, thanks :)
13:13:57 <dtroyer> like quotas, this is a good case for where we need the ability to extend commands from plugins
13:14:45 <huanxuan> yes
13:16:13 <huanxuan> by the way, we have completed some cinder commands in OSC, i remember we have more than 80% volume v2 commands completed now
13:16:45 <dtroyer> good news!
13:17:02 <huanxuan> yes!
13:17:55 <huanxuan> https://review.openstack.org/#/c/407983/ this one stevemar and I want let youtake one last look
13:20:34 <stevemar> o/
13:20:35 <dtroyer> hmmm… interesting idea there to add multiple volumes in one command, I like that
13:20:55 <dtroyer> there may be other places we can do that, like group add user, etc
13:21:05 <huanxuan> yes it is
13:21:10 <dtroyer> that is a nice non-breaking addition
13:21:10 <stevemar> (sorry i'm late)
13:21:32 <dtroyer> stevemar: welcome to the early-morning-for-north-america edition of OSC meeting!  :)
13:21:33 <huanxuan> hi stevemar~
13:21:58 <dtroyer> stevemar: any specific reviews you want to discuss?
13:22:12 <stevemar> just catching up in the meeting log, didn't want to interrupt
13:22:42 <dtroyer> we have covered our lists
13:22:52 <stevemar> I wanted to mention a few...
13:22:54 <stevemar> 1) https://review.openstack.org/#/c/410848/1
13:23:02 <stevemar> another attempt at image member update
13:23:12 <stevemar> that's the third attempt :)
13:23:38 <stevemar> maybe https://review.openstack.org/#/c/410848/ is a better link
13:25:23 <dtroyer> <sigh>   I know I had this worked out form a command standpoint three years ago
13:25:49 <dtroyer> and had buyoff from the Glance PTL (at the time, markwash)
13:26:18 <stevemar> also on the table -- https://review.openstack.org/#/c/398123/ - https://review.openstack.org/#/c/403393/ - https://review.openstack.org/#/c/410008/
13:26:47 <stevemar> dtroyer: i don't know much about updating member projects, seems like a funky transaction
13:27:09 <stevemar> i definitely don't like the command that jordanP proposed
13:27:44 <dtroyer> that part of the Image API was not thought through very well and we'll pay that price for a while yet
13:28:01 <dtroyer> that's why we went to a bit of work to 'normalize' it
13:28:27 <dtroyer> I'll dig up my notes and put them somewhere
13:29:45 <stevemar> dtroyer: okay, we can skip that one if it's weird
13:30:36 <dtroyer> 398123: that's an odd one, I still think we should have a common config, but we can go ahead with it as-is once it's passing tests
13:30:43 <stevemar> dtroyer: jordan makes a good point though, we need *something*
13:31:28 <stevemar> dtroyer: the other option for 398123 was something huanxuan brought up -- we can add a "is default" column to the output
13:31:35 <dtroyer> we can build "something" that doesn't make for a back-compat problem in the near future
13:32:18 <dtroyer> 398123: as a user, I'd rather have the —default option than have to iterate through a list
13:32:38 <dtroyer> I'm not opposed to the column, but the option is better UI
13:32:42 <dtroyer> UX
13:32:46 <stevemar> rgr
13:33:02 <stevemar> i'll fix the test after the meeting
13:33:21 <dtroyer> 403393: I need to look at this, is the command itself still in flux?
13:34:01 <huanxuan> yes
13:34:17 <stevemar> 403393: i think we should use backup import/export in this case. just the original author is AFK :P
13:34:18 <huanxuan> I think jiahui will continue the work
13:34:43 <stevemar> huanxuan: yeah, we gave the original author a chance
13:35:03 <dtroyer> ok
13:35:16 <stevemar> huanxuan: please make sure jiahui adds his name to the commit message, "Co-Authored-By: ... " so he gets credit
13:35:31 <huanxuan> ok, I will let him know it
13:35:35 <stevemar> (i think you've been working with him?)
13:35:42 <huanxuan> yes I am
13:35:49 <stevemar> i can tell ;)
13:35:59 <stevemar> you teach as good as you code!
13:36:06 <dtroyer> ++
13:36:14 <huanxuan> thank you :)
13:36:27 <stevemar> and now 410008
13:36:46 <dtroyer> 410008: is there not a way to tell when —remote-source was used to create a volume?
13:36:48 <stevemar> dtroyer: this is basically the 'unmanage' part of 'manage'
13:36:57 <dtroyer> right
13:37:01 <stevemar> hmm
13:37:04 <stevemar> good question
13:37:16 <stevemar> maybe it's a volume property?
13:37:22 <dtroyer> if there is the option shouldn't be necessary, we're already doing the lookup anyway
13:37:30 <dtroyer> thats what I was wondering
13:37:41 <dtroyer> if not, I'm OK with this as is
13:37:54 <stevemar> dtroyer: theres also the fact that a user may actually want to delete the volume properly
13:38:20 <stevemar> that'll wipe the data that's on the volume
13:38:32 <dtroyer> even for remote source?
13:38:46 <stevemar> if we inspect that it was created from remote, and always unmanage, then we are never able to do that
13:38:52 <dtroyer> ok, if that's a distinction, then we need the option
13:38:57 <stevemar> i dunno if it's a real scenario or not
13:39:06 <stevemar> but users do funny things
13:39:40 <dtroyer> oh yes they do
13:40:43 <stevemar> but i think smcginnis OK'ed the approach, at least he did when i spoke to him in person
13:40:50 <dtroyer> there is one thing that needs fixing in that review, relnote
13:40:58 <huanxuan> yes
13:41:01 <dtroyer> I lef tthe question in the review
13:41:04 <stevemar> ah yeah
13:41:24 <stevemar> good catch
13:42:23 <dtroyer> stevemar: I did have a question on purge…
13:42:40 <stevemar> shoot
13:42:46 <dtroyer> since we can not extend commands like that form plugins, what happend if a project is purged but say heat templates still exist
13:42:55 <dtroyer> can heat still clean them up if the project is gone?
13:43:11 <dtroyer> or is that dependant on each API implementation?
13:44:15 <stevemar> dtroyer: that probably depends on how each service handles their delete
13:44:38 <stevemar> i don't see why they would depend on the project existing, but some projects do funny things
13:44:48 <dtroyer> does keystone soft-delete the project?
13:44:57 <stevemar> no, it's removed from the db
13:44:58 <dtroyer> or is it gone from the database?
13:45:22 <stevemar> we do not have a soft delete, though folks are starting to ask for it
13:45:42 <dtroyer> if it was there, you could have a 'was this once valid?" API
13:46:15 <dtroyer> so I'm not sure how to protect users with purge …
13:46:17 <stevemar> dtroyer: why can't we extend that command?
13:46:32 <dtroyer> from plugins, we haven't built that ability yet
13:46:40 <stevemar> oh *yet*
13:46:48 <stevemar> so its the same problem as quotas
13:46:57 <dtroyer> yup, exactly the same
13:47:04 <stevemar> but this is more destructive
13:47:10 <dtroyer> much!
13:47:15 <stevemar> :)
13:47:21 <stevemar> warning before it's run?
13:47:41 <stevemar> "you should really use a dry run first!"
13:47:51 <stevemar> there is a --dry-run option
13:47:58 <dtroyer> the other problem is that even if we had the ability, if the plugin wasn't installed in that specific client, we wouldn't check it
13:48:18 <dtroyer> maybe we need to loop through the service catalog looking for services that do not have plugins?
13:48:20 <stevemar> true
13:48:24 <dtroyer> maybe we should do that anyway?
13:48:40 <dtroyer> on command at least, help users discover what else they mght want to install
13:49:17 <dtroyer> #idea add command to compare service catalog with installed plugins to see what may be missing
13:49:27 <stevemar> definitely room for improvement
13:49:54 <dtroyer> —dry-run is a great idea, assuming it has the rsync meaning.  but it still doesn't know what it doesnt know
13:50:34 <dtroyer> users have the power of "rm -rf"...
13:50:42 <stevemar> i think the current command will satisfy the majority of users (more once we add network stuff)
13:50:51 <dtroyer> is there a way to re-create a project (if it gets purged) but a project needs it to exist to clean up?
13:51:07 <dtroyer> ie, re-create a specific uuid?
13:51:21 <stevemar> nope!
13:51:33 <dtroyer> keystone-manage extension coming!
13:52:00 <dtroyer> this is the kind of command that we need to have documented all of these details so users know the risks
13:52:31 <stevemar> is was discussed in keystone-meeting 2 weeks ago
13:52:35 <stevemar> i was shot down
13:52:47 <stevemar> last thing to discuss
13:52:50 <dtroyer> what was shot down?
13:53:00 <stevemar> specifying the project id
13:53:16 <dtroyer> ah, ok.  wait until CERN needs it :)
13:53:34 <stevemar> i continued to try and twister cinder arms at their meeting last week: http://eavesdrop.openstack.org/meetings/cinder/2016/cinder.2016-12-07-16.00.log.txt
13:53:40 <stevemar> see 16:38:54
13:53:58 <stevemar> they are still hung up on "why isn't this in our client!"
13:54:08 <stevemar> and have now changed requirements :)
13:54:32 <stevemar> now they want support for microversions, v3 of their API, and manila standalone support
13:55:07 <dtroyer> that will never change
13:56:04 <stevemar> just annoying
13:56:18 <stevemar> they seemed surprised that neutron deprecated their CLI
13:56:32 <stevemar> i guess they'll get the message when nova deprecates theirs too :P
13:56:38 <dtroyer> kudos for trying to keep them in the game, but that's exactly one reason why I haven't spent too much time trying to convince project to drop their cli
13:57:01 <stevemar> eventually they will all come around :)
13:57:05 <stevemar> just trying to keep them informed
13:57:08 <dtroyer> they don't care much about it until they lose control, and that's how they see it, loss of control
13:57:23 <stevemar> womp womp
13:57:28 <dtroyer> <shrug>  we'll build the better mousetrap
13:58:00 <dtroyer> Cinder is one of the projects that has a bigger NIH factor than most
13:58:06 <dtroyer> Not Invented Here
13:58:15 <dtroyer> funny, given it's a fork of Nova
13:58:15 <stevemar> *shrug*
13:58:30 <stevemar> what isnt a fork of nova :P
13:58:37 <dtroyer> keystone light
13:59:02 <dtroyer> ok, almost out of time, anything else?
13:59:37 <huanxuan> nope
13:59:41 <stevemar> nope
13:59:47 <stevemar> thanks for chairing
13:59:51 <dtroyer> ok, let's end a minute early!
13:59:52 <stevemar> o\
13:59:54 <dtroyer> thanks guys!
13:59:58 <huanxuan> thank you dtroyer and stevemar
13:59:58 <dtroyer> #endmeeting