13:06:27 <dtroyer_zz> #startmeeting openstackclient
13:06:28 <openstack> Meeting started Thu Sep 22 13:06:27 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer_zz. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:06:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:06:31 <openstack> The meeting name has been set to 'openstackclient'
13:06:41 <aohuanxuan> o/
13:07:46 <dtroyer_zz> ok, let's get started…
13:07:52 <dtroyer_zz> #topic releases
13:08:16 <dtroyer_zz> We're still waiting on g-r to branch before we'll be able to make another release
13:08:43 <dtroyer_zz> I updated 3.3.0 Tuesday to include more of the new merges, will do again next week if we're still in this boat (likely)
13:08:56 <rtheis> ok
13:09:53 <dtroyer_zz> #topic reviews
13:10:21 <dtroyer_zz> there is a good sized backlog, I've not had time to dive into any of the thornier ones yet this week
13:10:32 <dtroyer_zz> anything you guys want to bring up here?
13:10:38 <rtheis> I have one
13:10:44 <rtheis> https://review.openstack.org/#/c/310193/11/doc/source/command-options.rst
13:10:55 <rtheis> and it relates to https://review.openstack.org/#/c/368320/ and https://review.openstack.org/#/c/308201/
13:11:36 <rtheis> you raised concerns in one of the reviews and wanted to double check on the devref approach is still okay
13:12:24 <dtroyer_zz> was that my comment about the base being too complex?
13:12:35 <rtheis> I think so
13:13:04 <rtheis> we are adding and removing values from lists with set and unset
13:13:31 <rtheis> then discussed (a long time ago) overwrite support which seems to be adding to the complication
13:13:37 <dtroyer_zz> it made perfect sense to me when we first talked about it, and after <time passes> reading that it seemed like we were going to a lot of work to maintain a list of attributes
13:13:40 <rtheis> it is in the devref
13:13:54 <rtheis> sure
13:14:09 <dtroyer_zz> this is one of the tings I want to look at more in the UX study in Barcelona
13:14:10 <rtheis> maybe we drop the overwrite support and just set and unset keys
13:14:35 <rtheis> ack
13:14:43 <rtheis> should we hold these changes until then?
13:14:46 <dtroyer_zz> I think I also put a comment on a review that wanted to make a new resource for what amounts to a property and pushed back on that too
13:14:59 <dtroyer_zz> I can't make up my mind!  ;)
13:15:03 <rtheis> :)
13:15:33 <dtroyer_zz> it isn't the property list mechanics in this case so much as the overall complexity of the port and other network commands due to the sheer number of options they have
13:16:09 <rtheis> ok
13:16:16 <dtroyer_zz> I think these two reviews are OK, I'd like to ponder the devref change a bit more though, still feeling like two ways to remove the list of attributes may be ok too
13:16:40 <rtheis> sounds good
13:17:19 * dtroyer_zz my Perl is showing a bit there
13:17:39 <aohuanxuan> Hi dtroyer_zz, I want to discuss more about "manage/unmanage" of volume and snapshot
13:17:48 <dtroyer_zz> ok
13:17:50 <aohuanxuan> I think we may need to decide whether we need new options in create command or new command
13:17:50 <dtroyer_zz> go ahead
13:18:04 <dtroyer_zz> what is the case for a new comamnd?
13:18:40 <aohuanxuan> new options make the "create" command more complex
13:19:13 <dtroyer_zz> how will a user know which create command to sue then?
13:19:15 <dtroyer_zz> *use
13:19:43 <dtroyer_zz> complexity is a warning flag, for sure, but it isn't enough by itself…look at server create for example
13:20:56 <aohuanxuan> https://review.openstack.org/#/c/369854/
13:21:13 <aohuanxuan> sorry
13:21:22 <aohuanxuan> the wrong link
13:21:29 <aohuanxuan> https://review.openstack.org/#/c/363574/
13:21:52 <aohuanxuan> Patrick East leave some comment here
13:23:10 <dtroyer_zz> I read that as his main point is we should have admin-only commands
13:23:33 <dtroyer_zz> which comes up every cycle or two.  that is not practical in many cases
13:23:48 <dtroyer_zz> also, what percentage of users of OSC are admin users?  I have no idea, but it isn't small
13:25:13 <aohuanxuan> then we can use new admin-only options to replace the admin-only command?
13:26:15 <dtroyer_zz> yes, we do that in a lot of places already
13:26:34 <rtheis> aohuanxuan: sometime admin-only options are defined as such by policy files
13:26:50 <rtheis> which makes things even more confusing
13:27:50 <rtheis> but, as dtroyer_zz said we use it a lot ... network commands have examples
13:28:22 <dtroyer_zz> aohuanxuan: did we answer your question?
13:28:46 <aohuanxuan> OK, I get it, then I will continue to do the work by adding new options, actually I just worry about the complexity of the "create" command, so I need make sure it
13:30:18 <dtroyer_zz> thanks, we do need to keep complexity in mind, that is basically my point on the reviews rtheis brought up.
13:31:18 <aohuanxuan> Ok, also, if you have time, could you talk about the patch https://review.openstack.org/#/c/355701/ with me
13:31:49 <dtroyer_zz> the error state one?
13:31:56 <aohuanxuan> Yes
13:32:58 <aohuanxuan> I have ask for help to Cinder team for this one and I get some explain about the error
13:33:04 <dtroyer_zz> the whole idea of being able to set an error state (basically just a db change) from a REST API sits funny with me.  that feels like something that should only be done very carefully, and with the cinder-manage command
13:33:52 <dtroyer_zz> I recall Nova team talking about moving all of nova-manage into the REST API (years ago) and it hasn't happened.  Is cinder thinking that too?
13:35:26 <aohuanxuan> uh , I do not know, I have not ask for it, maybe I will ask them next time
13:35:38 <dtroyer_zz> also, in some other places we have preferred to use explicit state options, so this might be instead —available|—error instead of --state
13:36:24 <dtroyer_zz> usually those are booleans though
13:36:40 <dtroyer_zz> ok, I may have just talked myself out of suggesting that :)
13:36:52 <aohuanxuan> --available|--error looks nice, but maybe we can set more than two status
13:37:31 <dtroyer_zz> right, we would add more options as required, but I think our actual pattern is usually to use —status <value> when it is not boolean, so never mind
13:38:07 <aohuanxuan> sorry I type English a little slowly :(
13:38:21 <dtroyer_zz> no worries
13:38:51 <aohuanxuan> so we can still use --status <value> in this patch?
13:39:14 <dtroyer_zz> yes, I think it is good as is
13:39:33 <aohuanxuan> OK, get it, thanks :)
13:40:00 <dtroyer_zz> I'm still unsure about setting error, but not enough to make you remove it
13:40:42 <aohuanxuan> yes, I am afraid maybe someone will use it in some case
13:41:09 <dtroyer_zz> lets talk about https://review.openstack.org/#/c/353931/ if we are done with the last one
13:41:33 <aohuanxuan> Yes
13:41:42 <aohuanxuan> I also want to ask it to you
13:41:49 <dtroyer_zz> we need to maintain backward-compatibility, so the <volume> positional argument still needs to be accepted and used, but not documented
13:42:07 <dtroyer_zz> or rather, properly deprecated
13:42:20 <aohuanxuan> Ok
13:43:54 <aohuanxuan> But I want to make sure can we also remove the   <volume> positional argument in the v1 command
13:44:01 <aohuanxuan> and add "--volume"
13:44:12 <dtroyer_zz> yes, please make them act the same as much as possible
13:45:51 <aohuanxuan> Yes, I will do it, I saw there is also a default value of volume_id in the v1 API, I will figure out it
13:46:03 <dtroyer_zz> ok, thank you
13:46:51 <dtroyer_zz> reedip brought up https://review.openstack.org/#/c/357973/ in -sdks earlier this morning, he doesn't appear to be online now though
13:47:52 <dtroyer_zz> I don't think we want 'router add gateway' because gateway isn't a resource, and the gateway is really an attribute of the router
13:48:57 <rtheis> yeah, this one is tricky
13:49:05 <dtroyer_zz> this is one I haven't looked at in detail yet, rtheis, how do you feel about tangchen's 'router set —gateway <>' suggestion?
13:49:43 <dtroyer_zz> as written, 'router gateway' is also a new resource
13:49:47 <rtheis> there is also 'router add network' option
13:49:57 <dtroyer_zz> when it is really a reouter attribute
13:50:11 <rtheis> yeah, it really is a router attribute
13:50:20 <rtheis> I'm okay with set
13:50:42 <rtheis> It does get a bit complicated with all of the options on the gateway
13:51:03 <dtroyer_zz> right…these get messy fast
13:52:06 <dtroyer_zz> I wonder if it would be helpful to have a resource glossary with more detail, such as listing the attributes, and relationships?
13:52:38 <rtheis> that would be nice
13:52:43 <dtroyer_zz> "routers have ports", "routers have gateways, gateways have attributes (but are not resources?)" etc
13:53:12 <dtroyer_zz> I know the concepts, but not necessarily how Neutron has modelled them
13:53:18 <dtroyer_zz> I'm sure others are in that boat
13:53:31 <rtheis> we could add to the command doc for each resource
13:53:49 <rtheis> Right now there is a small description of the resource
13:53:49 <dtroyer_zz> yes, that is absolutely the right place for that
13:54:05 <dtroyer_zz> and I want to encourage those docs to get more information in them anyway
13:54:39 <dtroyer_zz> dang, almost out of time…
13:54:44 <dtroyer_zz> #topic bugs
13:54:49 <dtroyer_zz> I want to squeeze this in yet
13:55:12 <dtroyer_zz> https://bugs.launchpad.net/python-openstackclient/+bug/1625745
13:55:12 <openstack> Launchpad bug 1625745 in python-openstackclient "floating ip column name change breaks grenade" [High,Confirmed]
13:55:34 <dtroyer_zz> I think this is due to the nova-net/neutron differences in column names
13:55:50 <dtroyer_zz> and was exposed when DevStack changed default from nova-net to neutron
13:56:18 <dtroyer_zz> the tl;dr is that we need to do some column mapping here to stay back-compatible
13:57:02 <dtroyer_zz> I'm not sure how to fix this for what column name to output, the bug is specificall on the input name though and that is easy
13:57:20 <dtroyer_zz> anyway, just wanted to raise it here for something we need to consider
13:57:33 <rtheis> I was planning to bring this up as well
13:57:57 <rtheis> I subscribed tangchen for his awareness...  maybe he has time to look at it
13:58:41 <dtroyer_zz> I think we need to talk about our approach to column names overall, and if we should get strict on them and require code changes when fields are added for example
13:58:57 <dtroyer_zz> a good session/workroom topic
13:59:02 <rtheis> I agree
13:59:10 <dtroyer_zz> rtheis: will you be in Barcelona?
13:59:11 <rtheis> this become more important with SDK
13:59:14 <rtheis> I will
13:59:17 <dtroyer_zz> \o/
13:59:37 <dtroyer_zz> aohuanxuan: will you be there also?
13:59:48 <aohuanxuan> yes, I will too :)
13:59:53 <dtroyer_zz> I think tangchen has his visa?
13:59:59 <aohuanxuan> not yet
14:00:10 <aohuanxuan> maybe need some more time
14:00:13 <dtroyer_zz> hrm, ok
14:00:33 <dtroyer_zz> oh, we're out of time… thanks everyone!
14:00:36 <rtheis> thanks
14:00:37 <dtroyer_zz> #endmeeting