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