19:01:56 <dtroyer_zz> #startmeeting openstackclient
19:01:56 <openstack> Meeting started Thu Sep 29 19:01:56 2016 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:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:59 <aohuanxuan> o/
19:02:00 <openstack> The meeting name has been set to 'openstackclient'
19:02:01 <stevemar> oh hai
19:02:07 <aohuanxuan> hi
19:02:20 <stevemar> aohuanxuan: good evening/morning! :)
19:02:40 <aohuanxuan> good morning :)
19:03:09 <dasanind_> hi
19:03:55 <dtroyer_zz> ok, let's get going...
19:04:05 <dtroyer_zz> #topic release status
19:04:24 <dtroyer_zz> still holding 3.3.0, I guess it's going to go all the way until next week
19:04:53 <dtroyer_zz> we should consider if there is anything merged in the last week that might not want to be put into a release immediately
19:05:10 <dtroyer_zz> I don't think there is anything…. anyone?
19:05:35 <stevemar> hey hey
19:05:52 <stevemar> the release ban should be lifted next week :)
19:06:09 <aohuanxuan> ok
19:06:18 <dtroyer_zz> I think my hesitation is due to know knowing off the top of my head about all of the command formats that have been merged
19:06:37 <stevemar> dtroyer_zz: nothing super critical to be honest
19:06:59 <stevemar> (that comment is about anything else that needs to be included)
19:07:13 <dtroyer_zz> ok, cool.  I'll re-visit updating the release commit early next week
19:07:41 <dtroyer_zz> well, Monday actually.  I am travelling Tues-Thurs so time is sporatic
19:08:28 <dtroyer_zz> #topic reviews
19:08:38 <dtroyer_zz> Anyone have any specific review to discuss?
19:08:56 <stevemar> there are a bunch of volume related ones
19:09:33 <aohuanxuan> yes...
19:10:14 <aohuanxuan> https://review.openstack.org/#/c/363574/ seems like the cinder team don't like it
19:10:33 <stevemar> aohuanxuan: yeah, theres that one :(
19:11:21 <dtroyer_zz> they tend to not like any changes to the db model they created, even if it is an artificial distinction
19:11:53 <stevemar> i like the current proposal, aohuanxuan had a good idea for re-using the key-value arg we created
19:12:13 <stevemar> instead of doing --remote-identifier and --remote-type or whatever nonsense was there first
19:12:43 <stevemar> its just 2 extra options when there are always a bunch, i don't think it'll confuse admins vs non-admins
19:13:18 <dtroyer_zz> that is a decent compromise.  frankly, the admin/not-admin distinction is low on my concern list mostly because it hasn't been a problem for us so far
19:13:25 <stevemar> also, with keystone, there is no admin vs non-admin, it's just a role ... if they *really* want admins to only use it, then make it part of cinder-manage
19:13:37 <dtroyer_zz> exactly
19:13:44 <aohuanxuan> yes, I think it is ok add it as a admin-only option
19:14:07 <stevemar> We can add (Admin required) to the help if that eases their concern
19:14:20 <dtroyer_zz> we still want to keep using specific options when needed, I'd rather not get into passing through arbitrary blobs too much
19:14:28 <dtroyer_zz> we should have that in the help
19:14:33 <aohuanxuan> ok
19:15:31 <dtroyer_zz> others?
19:15:44 <aohuanxuan> so what about the idea of using the "key=value" format there?
19:16:03 <stevemar> aohuanxuan: i like it
19:16:13 <dtroyer_zz> that is the part that I think is a good compromise
19:16:31 <stevemar> dtroyer_zz: theres the rename backup
19:16:31 <dtroyer_zz> it should not be our first choice for things like this though
19:16:47 <stevemar> dtroyer_zz: https://review.openstack.org/#/c/353931/
19:17:03 <aohuanxuan> ok
19:17:33 <aohuanxuan> yeah, backup restore
19:17:38 <stevemar> dtroyer_zz: we spoke about it on sept 15, you made call, but i posted some comments :)
19:18:39 <dtroyer_zz> stevemar: right.   (reads last comment)  I'd like to understand why v1 and v2 have to behave differently
19:18:57 <aohuanxuan> yes it is different
19:19:06 <aohuanxuan> it is my question
19:19:58 <aohuanxuan> looks like they are inverse
19:20:14 <dtroyer_zz> can we make them act the same?  how much work to make v1 work like v2?
19:20:32 <aohuanxuan> we can also add --force option for v1
19:20:39 <aohuanxuan> not much
19:20:44 <aohuanxuan> but if we do that
19:21:21 <aohuanxuan> then the --force should specified everytime when we specify --volume
19:22:06 <aohuanxuan> because we have a way to create a new volume for the restoring with v1 API
19:22:32 <dtroyer_zz> we could do a set of options for 'reuse-existing' and 'only-create-new' or something like that
19:23:33 <aohuanxuan> yeah, I think reuse-existing in similar to force, right?
19:23:56 * stevemar comes back
19:24:05 <dtroyer_zz> yes it is
19:25:31 <aohuanxuan> I mean in the v1 API, we can only use existing volume for restoring if we specify --volume
19:26:11 <dtroyer_zz> in your comment, though, that is the same for v1 and v2
19:26:30 <dtroyer_zz> it is the two cases with —volume specified that are different, that I would like to be not different
19:27:53 <aohuanxuan> but the v1 API dosen't support create a new volume for restoring
19:28:22 <dtroyer_zz> then we create it manually then use it for the restore call
19:28:37 <dtroyer_zz> we are not limited to only the APIs that directly support the command :)
19:28:54 <aohuanxuan> oh! good idea!!
19:29:14 <aohuanxuan> I get it
19:29:36 <dtroyer_zz> \o/    OSc is in the business of hiding bits like that from the user
19:29:53 <aohuanxuan> Yes
19:30:03 <aohuanxuan> it looks cool
19:30:25 <aohuanxuan> then we can make v1 and v2 the same
19:30:58 <stevemar> next up for reviews is https://review.openstack.org/#/c/365910/
19:31:07 <stevemar> which is another problematic command :)
19:31:56 <dtroyer_zz> I never wanted to implement anything containing the word 'member', especially since that concept is going away
19:32:08 <dtroyer_zz> had this all worked out with markwash a long time ago, and never got it done
19:33:12 <dtroyer_zz> should that be image add project?
19:33:37 <stevemar> thats what it is today
19:33:46 <dtroyer_zz> so why change?
19:34:14 <dtroyer_zz> I saw no motivation for that
19:35:11 <stevemar> ugh: Image members are not necessarily projects.  Glance has an option, owner_is_tenant, that controls whether images in a particular installation are owned by the project or the user.  (It's not a per-image setting, it's for the entire site.)  In such a cloud, you can't share an image with a project, you can only share with another user.
19:36:03 <stevemar> that stinks
19:36:03 <dtroyer_zz> does the user know the difference?  cna we discover which to use in those cases?
19:36:57 <stevemar> no idea
19:37:25 <dtroyer_zz> because I would much rather have 'image add project' and 'image add user' as two commands than 'image add <somthing-new-not-used-anywhere-else>'
19:37:37 <dtroyer_zz> call it what it is
19:40:27 <dtroyer_zz> ok, any other reviews?
19:41:21 <aohuanxuan> no, I haven't
19:43:58 <dtroyer_zz> #topic bugs
19:44:27 <dtroyer_zz> any specific bugs to talk about?
19:45:11 <stevemar> there have been a few RFE lately
19:45:36 <stevemar> on the topic bugs, i also cleaned up some BPs that were implemented or duplicates
19:45:46 <dtroyer_zz> I saw that, thanks!
19:45:50 <stevemar> this was a weird RFE: https://bugs.launchpad.net/python-openstackclient/+bug/1628412
19:45:51 <openstack> Launchpad bug 1628412 in python-openstackclient "Logging within the interactive shell of the openstack command" [Undecided,New]
19:46:45 <dtroyer_zz> heh, sounds like a controlled environment
19:46:51 * dtroyer_zz has worked in those
19:47:20 <stevemar> not sure if we can do anything specific in osc for that, might be a cliff enhancement
19:48:11 <dtroyer_zz> it would be in cmd2 most likely
19:48:19 <dhellmann> it used to do that by default, actually
19:48:24 <dhellmann> cliff, that is
19:48:31 <dhellmann> way way back at the beginning
19:48:50 <stevemar> oye... cmd2, that's another thing on the list
19:48:52 <dhellmann> it just used the logging module to do it, and it logged everything regardless of whether you were using interactive mode or not
19:49:11 <dhellmann> at least I think that was cliff, maybe I'm thinking of another project
19:49:28 <dtroyer_zz> I don't recall that, but I've forgotten a lot over the years
19:49:56 <dhellmann> yeah, maybe that was something else, but we could use the same approach -- if the needed env var is set, configure logging to write to a file
19:50:06 <dtroyer_zz> it does sound reasonable and should be doable
19:50:06 <dhellmann> as well as stderr
19:50:29 <stevemar> dhellmann: should i retarget the bug to cliff?
19:50:57 <dtroyer_zz> add cliff for now maybe?
19:51:01 <dhellmann> stevemar : I'm not sure. maybe? we'd probably want to use an openstack-specific variable name like OPENSTACKCLIENT_LOG_FILE or something
19:51:05 <dhellmann> yeah
19:51:09 <stevemar> k
19:51:09 <dtroyer_zz> OSc still might be involved in the plumbing
19:51:13 <stevemar> yeah
19:52:31 <stevemar> dtroyer_zz: i want to close this as WONTFIX: https://bugs.launchpad.net/python-openstackclient/+bug/1623860
19:52:32 <openstack> Launchpad bug 1623860 in python-openstackclient "'Openstack complete' command output is not clear" [Undecided,New]
19:52:56 <stevemar> i think the originator didn't know what the complete command was intended for
19:53:17 <dhellmann> yeah
19:53:43 <stevemar> i doubt we want to remove it from the help
19:53:43 <dtroyer_zz> I think it is totally usable for end-users, if you know what it does
19:53:58 <dtroyer_zz> maybe just a clearer explanation
19:54:15 <dhellmann> that couldn't hurt
19:54:48 <stevemar> okay, maybe some additional text here: https://github.com/openstack/cliff/blob/21f133f17ba2ec7a4b370a74bd08b536abddf1de/cliff/complete.py#L154
19:55:48 <stevemar> don't really know what to add ... maybe just add more logging before and after?
19:56:08 <stevemar> this is also a very frustrating bug: https://bugs.launchpad.net/python-openstackclient/+bug/1621126
19:56:09 <openstack> Launchpad bug 1621126 in python-openstackclient "cinder hardcodes the service type to "volumev2"" [Undecided,Confirmed]
19:56:15 <dhellmann> where do we document how you use complete to set up bash completion?
19:56:29 <dtroyer_zz> that plus an actual explanation in our doc, err, adding a doc for that
19:56:48 <stevemar> dhellmann: http://docs.openstack.org/developer/cliff/complete.html
19:57:21 <dhellmann> stevemar : I mean where is the user documentation for how to insert that stuff into their shell?
19:57:30 <stevemar> dhellmann: DNE :P
19:57:49 <stevemar> i guess we could add that to OSC docs
19:57:50 <dhellmann> so that could either go in the command help, or a reference to it could go there
19:57:52 <dhellmann> yeah
19:58:49 <stevemar> just gotta add "openstack complete | sudo tee /etc/bash_completion.d/osc.bash_completion > /dev/null" to the osc docs somewhere
19:58:52 <stevemar> i'll tackle that one
19:59:12 <dtroyer_zz> maybe an actual doc for the 'complete' command?
19:59:55 <stevemar> dtroyer_zz: oh true
20:00:12 <stevemar> currently there isn't one
20:00:20 <stevemar> endmeeting time :(
20:00:36 <dtroyer_zz> nope.  we should have one for help too, especially once that gets more complicated and so on
20:00:40 <dtroyer_zz> #endmeeting