19:00:42 <dtroyer> #startmeeting openstackclient
19:00:42 <openstack> Meeting started Thu Mar 31 19:00:42 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:45 <openstack> The meeting name has been set to 'openstackclient'
19:00:55 <dtroyer> Hey folks, who is here?
19:01:00 <rtheis> hi
19:01:01 <jgregor> Hey
19:01:07 <sheel> hi
19:01:08 <baumann> o/
19:01:24 <singhj> o/
19:01:58 <jungleboyj> o/
19:02:44 <dtroyer> for the first time in a while we have some non-default agenda items
19:02:46 <dtroyer> #link https://wiki.openstack.org/wiki/Meetings/OpenStackClient#Next_Meeting_Agenda
19:03:01 <sheel> dtroyer: :)
19:03:11 <baumann> Happy to help out :D
19:03:14 <dtroyer> I added the first one first because It should be much shorter and I want to get to it
19:03:27 <dtroyer> #topic meeting time
19:04:06 <dtroyer> There was a discussion in IRC yesterday about changing the meeting time.  The initial proposal was to move it earlier on Thursday
19:04:36 <dtroyer> IRC meeting rooms are mostly booked at the time that was suggested
19:05:08 <sheel> yep, I checked it... from 1300 til 1800 -all days were booked
19:05:14 <dtroyer> also, it drives the time deeper into the night for APAC folks
19:05:28 <dtroyer> many project alternate meeting times to attempt to deal with this
19:06:10 <sheel> I would suggest for alternate in our case as well if possible
19:07:19 <stevemar> o/
19:07:26 <dtroyer> Since we do not have everyone represented here, we should have the final discussion on the ML to find an acceptable alternate time, if that is where we want to go
19:07:56 <rtheis> sounds good
19:08:09 <rtheis> any initial suggestion for alternate time?
19:08:11 <stevemar> dtroyer: we could use a doodle thing
19:08:23 <dtroyer> sheel: would you mind starting that, and proposing a couple of times to consider?
19:08:50 <dtroyer> a doodle works for me too
19:08:51 <sheel> dtroyer: I think it is ok to keep 14:00 UTC to 16:00 UTC
19:09:05 <sheel> dtroyer:  means any slot between this time
19:09:20 <dtroyer> I want to be sure to get input from Tang and the others in APAC
19:10:30 <dtroyer> sheel: can you start an ML thread about this?
19:10:39 <sheel> dtroyer: sure, will do it
19:11:04 <dtroyer> #action sheel begins the meeting time conversation on ML
19:11:18 <dtroyer> ok, next up…
19:11:29 <dtroyer> #topic Cinder and OSC
19:11:45 <dtroyer> who wants to get this started?
19:11:46 <baumann> We'll let sheel start this one off I think
19:11:56 <sheel> ok, so this is about Using the "volume" keyword before all volume commands
19:12:18 <sheel> that we have for cinder
19:12:27 * stevemar pokes DuncanT and dulek
19:12:37 <dtroyer> I want to clarify something about that
19:12:39 <sheel> The idea was suggested in yesterday's cinder meeting to have volume before every cinder command in OSC
19:12:45 <sheel> yes please
19:12:59 <stevemar> dtroyer: apparently we're doing a great job of upsetting cinder folks :D
19:13:01 <rtheis> there are some objects that are common where this isn't needed
19:13:02 <dtroyer> when we use 'volume' in 'volume type' for example, it isn't a prefix, it is as part of the resource name
19:13:21 <baumann> dtroyer: Yeah I noticed that. Like volume type or volume qos
19:13:26 <dtroyer> the distinction means it isn't a blanket assumption that all 'cinder commands' gets it
19:13:36 <dtroyer> it is part of the resource name
19:13:58 <baumann> dtroyer: The thing we are worried about is that if someone wants to create a "snapshot" for example, how do they know they aren't creating a "stack snapshot" or a "manilla snapshot"?
19:14:24 <dtroyer> that makes sense to use 'volume snapshot', but because that is the resource name, not because it is a 'cinder command'
19:14:34 <dtroyer> the end result is the same, but the path to get there is different
19:14:47 <sheel> dtroyer:  right
19:14:49 <dtroyer> in other APIs, it is not always the same word used
19:15:00 <dtroyer> that's why I want to be clear on the path
19:15:16 <baumann> dtroyer: Agreed. But wouldn't it make it easier for the user if all volume commands just had the "volume" prefix?
19:15:22 <dtroyer> no
19:15:26 <dtroyer> how does a user know that?
19:15:38 <jungleboyj> dtroyer: What do you mean?
19:15:39 <sheel> for user these resources are nothing but the names that we are giving..
19:15:46 <dtroyer> part of the entire reason for OSC to exist is to free the user from knowing which API owns which resource
19:16:02 <sheel> so adding volume makes good sense here
19:16:09 <baumann> dtroyer: I agree 100%. But they have to differentiate between commands if other services use them
19:16:20 <dtroyer> so making a blanket statement that all commands supporting an API get the API name is a bad one in my opinion
19:16:29 <baumann> dtroyer: And if we always used "volume" before volume commands, there would never be confusion from users
19:16:42 <sheel> dtroyer: actually idea is to segregate components
19:16:42 <baumann> dtroyer: I don't disagree with you
19:17:01 <jungleboyj> dtroyer: I don't understand how we can free users from knowing what resource they are acting upon.
19:17:23 <baumann> dtroyer: But consistency across projects might prove to be difficult in that case, right?
19:17:31 <dtroyer> the know what resources they need, not which API or project controls them
19:18:02 <jungleboyj> So, if they are working on volume resources we shouldn't hide that.
19:18:17 <baumann> dtroyer: But would it hurt to have volume before all of the volume resources?
19:18:18 <jungleboyj> having a generic 'snapshot' command is incredibly confusing.
19:18:20 <dtroyer> so a great example is 'flavor'  we have a stand-alone flavor resource that is for servers, other projects came along later and want to use flavor so they qualify it with the thing it describes
19:18:35 <dtroyer> 'server flavor' should be a thing, and probably will be at some point
19:18:43 <dtroyer> note 'server' and not 'compute'
19:18:49 <dtroyer> this is why I make that distinction
19:18:56 <sheel> if we say snapshot, they are related to volume
19:19:01 <baumann> dtroyer: Then the user will need to determine if "server" has a flavor before using flavor for compute
19:19:14 <sheel> so adding volume before them is ok for user as well
19:19:47 <jungleboyj> dtroyer: That is where things fall apart.  There is no consistency to me it seems.  It is first come first serve and left to the user to try to figure out if they need just flavor or 'server flavor' or 'volume flavor' .... but wait, what was the first flavor?
19:20:16 <dtroyer> so I can't go back and change history 4 years ago
19:20:31 <dtroyer> if I was starting fresh now, it would be 'server flavor' and not just 'flavor'
19:20:48 <dtroyer> so that is why 'volume snapshot' makes perfect sense
19:20:50 <baumann> dtroyer: Could the projects go back and change history? :)
19:20:57 <dtroyer> but not because of the API that is being called
19:21:02 <jungleboyj> dtroyer: :-)
19:21:04 <dtroyer> but because of the kind of snapshot it is
19:21:05 <sheel> same is with backup, they used to be for volume backup
19:21:14 <baumann> dtroyer: That was actually one of our topics as well. Could we go back into snapshot and rework it all to be "volume snapshot"?
19:21:28 <dtroyer> baumann: I do expect we will add the qualified versions of flavor and others at some point
19:21:38 <sheel> dtroyer: so at least adding volume before backup and snapshot is good option
19:21:39 <dtroyer> but that is a loooooong transition period
19:21:44 <jungleboyj> dtroyer: It was suggested that we add 'volume snapshot' and eventually deprecate the 'snapshot' one.
19:21:50 <sheel> dtroyer:  and we are open to work on that
19:21:56 <baumann> dtroyer: Most definitely is a long transition
19:22:00 <dtroyer> sure, that is the same thing
19:22:16 <dtroyer> but again, we CAN NOT break backward compatibility for a while
19:22:32 <sheel> dtroyer: yes, we can deprecate older with new in parallel for some time
19:22:39 <sheel> dtroyer: as suggested by jungleboyj
19:23:05 <dtroyer> right, that is the process.  plus a major rev.  I expect our next major rev will have a number of breaking changes
19:23:16 <sheel> dtroyer: great
19:23:32 <baumann> dtroyer: It sounds like we are pretty much on the same page here, right?
19:23:34 <sheel> dtroyer: I will propose this change through one spec
19:23:35 <jgregor> dtroyer: Gotcha
19:24:04 <dtroyer> we are on the same page if it is clear that the process is to clearly name resources and not to just assume an API name goes at the front of a command
19:24:36 <sheel> dtroyer: yes, that is why i am saying we should propose it through spec for clear cut understanding
19:24:40 <rtheis> +1
19:24:47 <jungleboyj> sheel: ++
19:24:52 <dtroyer> yes…restating it for the log ;)
19:25:02 <jgregor> +1
19:25:17 <sheel> dtroyer:  ok, I will propose one next week...
19:25:33 <sheel> thanks , may be we can move to next topic
19:25:40 <dtroyer> go ahead
19:25:45 <jungleboyj> dtroyer: Just to be clear, I think we aren't trying to replace there there used to always be the word 'cinder' I.E. cinder snapshot but to clearly label when we are acting on volumes, etc.
19:25:54 <dtroyer> #action sheel to propose a spec outlining resource naming
19:26:21 <jungleboyj> dtroyer: Does that help with your concern?
19:26:59 <dtroyer> jungleboyj: yes.  The reason I make the distinction is the wording I way in yesterday's meeting log seemed to be just to use a blanket prefix
19:27:28 <jungleboyj> dtroyer: I think we were thinking that way, but I see your concern.  We need to find the right middle ground.
19:27:55 <jungleboyj> dtroyer: Thank you for discussing/considering this and we can keep working it through a spec.
19:28:11 <dtroyer> the middle ground is where the user lives.  and btw, we are doing UX testing on OSC to get an idea of how far off we are
19:28:43 <jungleboyj> dtroyer: That is good.
19:28:57 <baumann> Definitely. Thanks for working with us dtroyer. I feel like we can get some good stuff done working together on this.
19:29:04 <sheel> dtroyer: that's really good ... may be jgregor  and baumann  attend if time allows
19:29:10 <jungleboyj> baumann: ++
19:29:18 <dtroyer> this is all to make the user's life easier, even if it makes ours harder
19:29:25 <dtroyer> OpenStack is hard enough as is
19:29:28 <jgregor> dtroyer: Tep, thanks for the insight
19:29:39 <baumann> dtroyer: +1
19:29:49 <jungleboyj> dtroyer: +!
19:30:06 <dtroyer> next?
19:30:09 <sheel> ok, so should we move ahead?
19:30:12 <sheel> ok, here we go
19:30:14 <sheel> Keyword "properties" vs "metadata"
19:30:43 <sheel> should i copy paste large text here
19:31:24 <sheel> This may be ok if we are using property for metadata in OSC.
19:31:25 <sheel> But corresponding component must be informed about changes
19:31:25 <sheel> for their counterparts for better user experience.(I am explaining further what i mean by better user experience)
19:31:25 <sheel> Further, this may not be related as components are different and their implementations
19:31:25 <sheel> are independent.
19:31:25 <sheel> So, keeping different names may be ok, which is fair enough.
19:31:25 <sheel> But actual thing is that there are certain documents/components which use metadata instead of property.
19:31:26 <sheel> In case user see metadata in docs or related component but property in OSC, then this may spoil the target for achieving good user experience.
19:31:26 <sheel> Also, we are trying to generate single CLI for user in OSC in same way as we have single horizon for GUI.
19:31:27 <sheel> But here also we are loosing similarity in terms as horizon displays metadata.
19:31:27 <sheel> So, I would suggest to keep parity for different terms upto the extend it is possible.
19:31:28 <sheel> This may be discussed and decided whether property should be changed to metadata or vice-versa.
19:31:28 <sheel> But something needs to be changed.
19:31:44 <baumann> sheel: Give me a minute to read this novel ;)
19:31:50 <sheel> haha
19:31:54 <jgregor> baumann: +1
19:32:01 <jungleboyj> Ahhhhh Spam bot!
19:32:03 <jungleboyj> ;-)
19:32:47 <rtheis> sheel: OSC is using --property not --metadata options today, are you looking to change that?
19:33:05 <sheel> rtheis:  this may be changed in other components
19:33:10 <baumann> rtheis: Yes or at least talk about the whys
19:33:16 <sheel> rtheis: this is just for discussion where to change
19:33:41 <baumann> About why we use properties vs metadatas in osc*
19:34:09 <dtroyer> OSC strives for consistency within itself.  we go to great length to hide differences in projects
19:34:25 <stevemar> dtroyer: apparently cinder uses both properties and metadata?
19:34:42 <stevemar> they also argue that all the docs/manuals/APIs all say "metadata"
19:34:44 <dtroyer> the decision to use properties was made almost 4 years ago, in a discussion with an admittedly small group, but it included over half of the PTL's at the time
19:34:49 <stevemar> so we are the ones being inconsistent :)
19:34:50 <jgregor> stevemar: That sounds right, but we use metadata alot more
19:35:10 <sheel> stevemar:  :)
19:35:46 <sheel> stevemar:  dtroyer rtheis what you guys think about changing property to metadata ?
19:35:55 <sheel> just a quick thought only
19:36:03 <rtheis> not a fan
19:36:13 <dtroyer> I have no desire to make that large of a consistency break
19:36:14 <jgregor> sheel: I am thinking we should actually change to property
19:36:21 <baumann> jgregor: +1
19:36:45 <sheel> dtroyer:  ok, no issues from my side
19:36:52 <sheel> dtroyer: I am open for reverse as well
19:37:05 <baumann> In the meeting yesterday, opinions seemed to be split about this in Cinder. But I personally think properties sounds way better than metadata :D
19:37:18 <sheel> dtroyer: so, should we inform other projects about changing things vice-versa
19:37:20 <sheel> ?
19:37:32 <jgregor> Atleast switching metadata to property makes more sense to me. We definitely seem to be overusing metadata in Cinder as I see it.
19:37:38 <dtroyer> baumann: that was part of the consensus in the original discussion.  we thought it was clearer to users
19:37:45 <baumann> sheel: Or we can at least keep the conversation open. I don't think we are going to be able to force either side
19:37:57 <sheel> stevemar:  jungleboyj  rtheis ^^
19:38:02 <baumann> dtroyer: Yeah putting myself in a user's shoes, properties makes way more sense
19:38:05 <sheel> baumann: this is just an idea for now
19:38:12 <baumann> sheel: Exactly :)
19:38:23 <sheel> baumann: we have to start somewhere to go ahead... so taking views only for now
19:38:27 <sheel> :)
19:38:55 <rtheis> does cinder use both properties and metadata on the same resource
19:39:00 <stevemar> i think there are two issues here, where is DuncanT?!
19:39:13 <baumann> stevemar: For real!
19:39:19 <stevemar> i swear someone told me that cinder has both properties and metadata, as in they were distinct things
19:39:24 <sheel> stevemar:  DuncanT  seems not present today for time being
19:39:39 <sheel> stevemar:  ah, actually we were about to use this in one proposal
19:39:45 <dtroyer> there are two (at least) kinds of metadata on a volume, volume properties and properties copied from the image in case it came from glance
19:39:50 <dtroyer> is this correct?? ^^^^^
19:39:51 <sheel> stevemar:  for now, as far as  i know, we use metadata only
19:40:08 <stevemar> we could also... support --metadata very easily with an alias
19:40:13 <baumann> stevemar: I'm pretty sure they are distinct things in cinder, but I'm not sure
19:40:14 <jungleboyj> dtroyer: Yes, I think that is correct.
19:40:29 <sheel> dtroyer: user metadata and image metadata
19:40:34 * dtroyer glares at stevemar
19:41:02 <baumann> dtroyer: I think we should all just listen to stevemar... :D
19:41:16 <stevemar> dtroyer: hey it's possible, that's all i'm saying
19:41:20 <dtroyer> ha!  then we'd all be cheering for the Blue Jays
19:41:28 <rtheis> :)
19:41:33 <stevemar> we're making a come back this year!
19:41:42 <jungleboyj> Blue Jays.  :-)
19:41:50 <jungleboyj> My favorite bird.
19:41:56 <stevemar> but we *could*, the only hiccup would be the output (list/show)
19:42:18 <stevemar> to keep the baseball theme going... it'll show we play ball with cinder :P
19:42:33 <dtroyer> stevemar: why do we want to make things inconsistent?
19:42:40 <jgregor> Definitely an interesting option.
19:42:43 * dtroyer dusts off his brushback pitch
19:42:55 <stevemar> we could suppress it in the help
19:43:00 <stevemar> just an alias
19:43:18 <stevemar> if people *really* like typing metadata, they still can
19:43:32 <baumann> stevemar: dtroyer: I don't want to make things worse for you guys. I don't know how everyone else thinks.
19:43:35 <dtroyer> so if a user can't find it, why add it?  we do that for getting rid of things already in use
19:43:46 <stevemar> true true
19:44:04 <stevemar> if someone is migrating from cinderclient to osc, they will have to make a lot of changes anyway
19:44:15 <stevemar> volume-type vs volume type
19:44:19 <baumann> But I feel like making it consistent is more important than appeasing Cinder. (Don't tell anyone I said that)
19:44:33 <stevemar> heathen!
19:44:36 <sheel> this is on records :)
19:44:45 <jungleboyj> baumann: !?!
19:44:45 <baumann> baumann is just an alias
19:45:00 <jungleboyj> baumann: is actually jgiffith ?
19:45:09 <jgregor> ha
19:45:10 <sheel> haha
19:45:21 <stevemar> dtroyer: maybe we need to step back and take a look at use cases / user stories.. who will be using OSC -- new folks and folks migrating from cinderclient
19:45:40 <stevemar> it only impacts one of those groups
19:45:55 <dtroyer> stevemar: We did 9 UX study sessions last week.  we'll have some results soon.  doing a bunch with ops-types in Auston
19:45:56 <jgregor> Overall though,  I do agree that keeping things consistent seems the better way to go
19:46:04 <dtroyer> we are getting feedback
19:46:16 <stevemar> dtroyer: oh thats nice
19:46:26 <sheel> we are left with 14 more minutes
19:46:36 <dtroyer> and the consistency is often mentioned, especially from AWS and project CLI users
19:46:41 <stevemar> maybe we don't make a decision this time around, wait for more data from UX feedback
19:46:46 <dtroyer> right sheel, what next?
19:46:59 <jgregor> stevemar: +1
19:47:09 <sheel> dtroyer: Name is not a necessary field in cinder, but is in openstackclient
19:47:35 <sheel> dtroyer: one patch was proposed for some changes
19:47:35 <sheel> https://review.openstack.org/#/c/294146/1
19:47:41 <baumann> I think only size is required in cinderclient
19:47:48 <dtroyer> I did that because I wanted … wait for it … consistency.  It isn't harmful from an operational standpoint
19:48:16 <dtroyer> I can see where we might make that optional, but my purity brain cells are shaking
19:48:31 <dtroyer> also, using "" as a name works ;)
19:48:35 <dtroyer> but that is bad UX
19:48:44 <sheel> dtroyer: agree on this
19:49:27 <baumann> dtroyer: I don't personally see a harm in requiring a name. But this isn't my battle either. I don't remember who was worried about this from the Cinder team
19:49:48 <dtroyer> in that review, rtheis is right… we'll want to test both cases
19:50:03 <dtroyer> baumann: that was basically my thinking.
19:50:18 <jgregor> dtroyer: So is Name a field that is required across multple commands in OSC?
19:50:27 <sheel> dtroyer:  will add test case for those soon
19:50:36 <dtroyer> for create commands, yes
19:50:45 <dtroyer> it is the name of the resource that is being created
19:50:57 <sheel> http://lists.openstack.org/pipermail/openstack-dev/2016-March/090375.html
19:51:02 <sheel> for reference
19:51:29 <dtroyer> there have been a number of places where not having name and ID causes minor pain in using OpenStack APIs
19:51:42 <dtroyer> at least you don't let the user specify ID ;)
19:51:49 <jgregor> dtroyer: Gotcha.
19:51:52 * dtroyer cough flavors cough
19:52:17 <jgregor> dtroyer: Yea, I do not think it is a big deal either way
19:52:21 <stevemar> baumann: i think DuncanT was just highlighting differences
19:52:49 <baumann> stevemar: Yeah, I think you are right
19:53:03 <baumann> There wasn't any serious backlash from it as much as I remember.
19:53:20 <dtroyer> i'd prefer to leave it.  if there are technical reasons it should change we can change it
19:53:29 <sheel> Ok, so for now we can target https://review.openstack.org/#/c/294146/1 and discuss later on about other cases like volume create and other create commands
19:53:32 <sheel> right?
19:53:33 <baumann> dtroyer: Did that recent mailing list thread come to a consensus?
19:53:48 <dtroyer> we changed from verb-object to object-verb for tab-completion for example
19:54:02 <dtroyer> baumann: I think I killed that thread off, didn't see any replies
19:54:14 <baumann> dtroyer: I noticed that too. You must be powerful
19:54:16 <dtroyer> ^^ not intentionally
19:54:30 <dtroyer> I wish
19:54:45 <stevemar> dtroyer: maybe we just need to draw a line in the sand and say "expect differences, sorry"
19:54:51 <dtroyer> coming up on 5 minutes
19:55:01 <sheel> dtroyer: 6
19:55:05 <sheel> :)
19:55:06 <dtroyer> anything else here?  I do have one review I want to point out yet
19:55:18 <stevemar> do it now!
19:55:20 <sheel> I think done....
19:55:27 <dtroyer> ok
19:55:28 <jgregor> dtroyer: Nope, think we have everything covered
19:55:29 <sheel> baumann: jgregor  anything else we have?
19:55:38 <baumann> sheel: dtroyer: I think we are good for now
19:55:43 <dtroyer> #topic reviews
19:55:45 <sheel> great
19:55:55 <dtroyer> https://review.openstack.org/#/c/297063/
19:56:29 <dtroyer> we talked about this last week, and just after the meeting I realized we should have used —no-address-scope there, and in general use —no-NN rather than —clear-NN
19:57:01 <dtroyer> there is only one use of —clear- in the wild atm
19:57:12 <stevemar> which command is that?
19:57:20 <rtheis> yes,  router
19:57:22 <dtroyer> router set and/or unset
19:57:38 <dtroyer> one thought is that —clear makes sense when there are multiple things
19:57:51 <dtroyer> I think it is simpler to remember if everything just uses —no-
19:57:57 <rtheis> router set [--route|--clear-routes]
19:58:34 <stevemar> i think --no- is better
19:58:42 <stevemar> less typing
19:58:52 <rtheis> devref here captures using --no https://review.openstack.org/#/c/297718/
19:59:01 <dtroyer> it's also a GNU standard, not that we would ever admit to that here
19:59:18 <dtroyer> ok, just wanted to highlight this since we left it different in last weeks' log
19:59:32 <stevemar> ++
19:59:35 <stevemar> good meeting
19:59:38 <dtroyer> thanks everyone, we're out of time
19:59:39 <sheel> #link https://review.openstack.org/#/c/292043/      this is for volume transfer, I am waiting for approval on command signature -  refer line 84      -> #link https://etherpad.openstack.org/p/cinder-command-support
19:59:55 <sheel> ok, lets close
19:59:56 <dtroyer> and thanks for stopping by Cinder folks… if you have more questions you know where to find us
20:00:05 <sheel> thanks :)
20:00:16 <dtroyer> volume transfer ;)
20:00:21 <dtroyer> #endmeeting