13:03:44 <dtroyer> #startmeeting openstackclient
13:03:44 <openstack> Meeting started Thu Jun  2 13:03:44 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:03:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:03:48 <openstack> The meeting name has been set to 'openstackclient'
13:04:02 <tangchen> It is night for me. :) hahaha
13:04:30 <rtheis> good night too :)
13:04:51 <tangchen> :)
13:05:49 <dtroyer> Shall we get started?
13:05:56 <dtroyer> #topic releases
13:06:01 <tangchen> let's go
13:06:18 <dtroyer> We did the 2.5.0 release last week, the last planned release before 3.0
13:06:46 <dtroyer> I wanted to hold off making any breaking merges until we had a bit of time to make sure 2.5.1 was not immediately necessary
13:07:08 <dtroyer> we seem to be clear of that
13:07:21 <dtroyer> anyone know of anything otherwise?
13:07:43 <rtheis> dtroyer: I may have one...
13:08:16 <rtheis> I just found an issue late yesterday that I think is related to --enable-beta-commands
13:08:47 <rtheis> Somehow, --enable options are getting ignored on commands now
13:09:15 <rtheis> I need to investigate further as to why this is.  Any ideas?
13:09:22 <dtroyer> oh good grief…yes
13:09:42 <dtroyer> global option names bite again
13:10:12 <dtroyer> I forget the exact setting, but argparse will swallow up substring matches sometimes
13:10:39 <dtroyer> that's another reason we use —os on most global options
13:10:39 <rtheis> oh boy
13:11:09 <rtheis> so is it best to just change to --os prefix for this?
13:11:37 <dtroyer> possibly, or something similar
13:11:55 <dtroyer> even just —os-beta-commands?
13:12:07 <rtheis> sure
13:12:14 <rtheis> I like that
13:12:24 <rtheis> I'll open a bug and work on a fix today.
13:12:31 <dtroyer> ok, thanks
13:12:52 <rtheis> I didn't expect argparse to have such a "feature"
13:12:59 <dtroyer> I have a feeling though that we'll need to jump to 2.6.0 based on what has already merged…I will review
13:13:11 <rtheis> ok
13:13:51 <dtroyer> IIRC argparse does this when combined with… tab complete maybe?
13:14:03 <dtroyer> no, not tab complete… dang, I forget exactly what it is
13:15:30 <rtheis> that's ok
13:15:32 <dtroyer> anything else release-wise?  This means we need to still hold off on the bigger breaking things for a while, probably next week
13:15:43 <rtheis> I don't have anything else
13:15:52 <tangchen> none for me
13:16:17 <dtroyer> #topic reviews
13:16:34 <dtroyer> So I was wanting to go through the stuff we have been holding back here
13:16:49 <dtroyer> we can still look at the list, but wait on them
13:17:28 <tangchen> Are we going to do the ip refactor now ?  after 2.5.0
13:17:48 <dtroyer> yes, that set is one in this category
13:17:52 <tangchen> I mean this series. https://review.openstack.org/#/c/300388/
13:17:54 <tangchen> OK
13:18:21 <dtroyer> also Navid's KSA and it's follow on reviews from Alvaro
13:18:39 <dtroyer> and Henry's role assignment
13:19:19 <rtheis> ok
13:19:44 * dtroyer is looking at the list from last week
13:20:24 <dtroyer> so the only things I am unsure about is what may be new since last Thursday
13:21:24 <dtroyer> other than release-type issues, any reviews we need to talk about?
13:21:55 <rtheis> Looking for opinions on command object for https://review.openstack.org/#/c/319522/
13:22:13 <rtheis> This is for neutron rbac policies
13:22:47 <dtroyer> wow, yeah, yuck
13:23:13 <rtheis> Similar for https://review.openstack.org/#/c/320604/ which is start of OSC neutron plugin
13:23:32 <rtheis> that is, plugin for network advanced services
13:24:09 <rtheis> no rush on these, just wanted to bring them up for attention
13:24:20 <dtroyer> sure, thanks, I had not seen them
13:24:44 * dtroyer was sleeping much of yesterday, too much holiday weekend maybe :(
13:25:05 <rtheis> :)
13:25:27 <dtroyer> interestingly enough, the recent ML thread about changing the *aaS release model brings up the near-deadness of at least two of those projects
13:26:33 <dtroyer> back to the RBAC bit though, I don't think we can assume that 'rbac' is network-only in the long term
13:26:53 <dtroyer> but yes, it's a bad name all on its own
13:27:36 <rtheis> yeah, it seemed similar to qos in my mind
13:27:50 <dtroyer> how does 'network policy' fit?  it feels like it might still be too ambiguous
13:28:18 <rtheis> network has qos policies
13:28:21 <dtroyer> qos has a better case though, as it is the common term in the networking world.  like IP
13:28:24 <rtheis> and rbac policies
13:28:31 <dtroyer> ah, ok
13:28:51 <rtheis> we have "volume qos" today
13:28:58 <dtroyer> what role does the R in RBAC refer to?
13:29:53 <dtroyer> users or servers?
13:30:19 <rtheis> trying to sort that out now
13:30:20 <tangchen> I think it is users.
13:30:25 <dtroyer> I have always thought of it as user-related but don't see how that work in a neutron context
13:31:11 <rtheis> it is users actions allowed for network objects enforced on a project
13:31:46 <rtheis> I haven't played with it much
13:32:22 <dtroyer> Identity uses plain role here
13:32:23 <tangchen> me nither...
13:32:33 <dtroyer> so a) it owns that object, but b) doesn't use rbac
13:32:41 <dtroyer> name
13:33:10 <dtroyer> ok, let's keep the conversation going in the reviews
13:33:24 <dtroyer> I'll leave some comments after the meeting
13:33:30 <rtheis> thanks dtroyer
13:33:42 <tangchen> thanks.
13:34:09 <dtroyer> tangchen: in https://review.openstack.org/#/c/321977/ I noticed you added an exception for when no option (—enable|—disable) is present
13:34:16 <dtroyer> I thought we started removing those complaints
13:34:52 <dtroyer> thinking that if the user does not specify a change, that is not an error
13:35:30 <tangchen> Well, that makes sense. So, a warning msg ?
13:36:02 <tangchen> I think we should let the user know nothing has changed.
13:36:03 <dtroyer> maybe… I still lean toward nothing though
13:36:39 <dtroyer> maybe an info message, that will be silent unless -v is set
13:37:35 <tangchen> I think nothing will be a little strange. The command is not complete. but it looks like it has been executed correctly.
13:37:53 <dtroyer> but it has been executed correctly
13:38:02 <dtroyer> it did nothing correctly
13:38:03 <dtroyer> :)
13:38:35 <tangchen> Well, I'd vote for a warning, but info is also ok for me.
13:38:45 <dtroyer> set commands usually have more options, if this one grows more we would need to remove the specific warning about --enable
13:38:56 <dtroyer> because then it would not be an issue
13:40:03 <tangchen> sorry, what specific warning about --enable ?
13:41:14 <dtroyer> if we did the same thing to 'user set', for example, you would have a warning if —enable or —disable was not present
13:41:40 <tangchen> Oh, I see
13:41:41 <dtroyer> which is totally acceptable
13:41:47 <tangchen> just like service set
13:42:10 <tangchen> OK
13:42:20 <tangchen> I'm OK with nothing output.
13:42:36 <tangchen> Then we need to fix some other commands.
13:42:43 <dtroyer> yes we do
13:42:50 <tangchen> OK, I'm on it
13:42:56 <dtroyer> thanks
13:43:15 <dtroyer> any other reviews?
13:43:30 <rtheis> none from me
13:43:48 <tangchen> none for me, but I have two things need some advice.
13:43:55 <tangchen> please give me 5 min in the end
13:44:02 <dtroyer> ok, will do
13:44:06 <dtroyer> #topic bugs
13:44:37 <dtroyer> I saw https://bugs.launchpad.net/python-openstackclient/+bug/1587927 and never considered that before, we have another thing to sort out
13:44:37 <openstack> Launchpad bug 1587927 in python-openstackclient "Quotas command is not plugable" [Undecided,New]
13:45:14 <dtroyer> that is a good example of when we want a plugin to be able to modify another command
13:45:21 <dtroyer> other times we don't want that
13:45:24 <dtroyer> fun times ;)
13:45:42 <rtheis> that is interesting
13:46:16 <dtroyer> I played with something similar by adding —ram —cpu and —disk to server create a while back via a plugin
13:46:42 <dtroyer> but that technique isn't viable for actual use because it depends on install order
13:47:11 <dtroyer> also, https://bugs.launchpad.net/python-openstackclient/+bug/1580870 is asking for what looks to be nova-net commands?
13:47:11 <openstack> Launchpad bug 1580870 in python-openstackclient "Fixed IP reserve/unreserve/show in computeV2" [Undecided,New] - Assigned to aohuanxuan (huanxuan-ao)
13:47:29 <dtroyer> if they are part of Compute
13:48:01 <rtheis> nova-net is back to deprecated, isn't it?
13:48:34 <dtroyer> let's see… it is an even year, and even month, an even day, so I think yes?
13:48:49 <rtheis> :)
13:49:14 <tangchen> If they are just for nova, yes.
13:49:43 <dtroyer> If we do those for Network and adding them for Compute is near-trivial, then maybe.  Otherwise I think at this point we should have a Really Good Reason to add more nova-net-only commands
13:50:03 <dtroyer> I'll ask that in the bug…
13:50:19 <rtheis> agreed
13:50:24 <tangchen> OK
13:50:49 <dtroyer> other bugs to raise?
13:50:55 <tangchen> non for me
13:51:00 <rtheis> nothing else
13:51:15 <dtroyer> #topic open discussion
13:51:25 <dtroyer> what is on your ming, tangchen?
13:51:35 <tangchen> https://blueprints.launchpad.net/python-openstackclient/+spec/log-usage
13:51:44 <tangchen> Need some advice for this
13:52:01 <tangchen> I'm often confused the way to use a logger.
13:52:12 <tangchen> I can see 3 loggers in OSC
13:52:24 <tangchen> Shall we give some rules on how to use them ?
13:53:00 <dtroyer> good idea, yes
13:53:28 <rtheis> https://github.com/openstack/python-openstackclient/blob/master/openstackclient/common/command.py#L37
13:53:34 <dtroyer> I can see places where all of those make sense though, the rule will probably be based on what type of message is being reported
13:53:41 <rtheis> I thought this was an attempt at that
13:54:10 <dtroyer> rtheis: I would agree with that.
13:54:27 <tangchen> sorry, I don't quite understand
13:54:31 <dtroyer> the default for commands seems like it should be using self.log()
13:54:40 <tangchen> what do you mean richard ?
13:55:07 <dtroyer> self.app.log() should be for things that are not command-specific
13:55:17 <dtroyer> so volume's use there probably needs to be changed
13:55:25 <tangchen> yes
13:55:50 <tangchen> OK, I can start the work from volume.
13:56:07 <tangchen> then we can discuss more in the reviews, and give a rule in doc finally.
13:56:10 <dtroyer> the module-level LOG is likely the least necessary one for reporting
13:56:19 <dtroyer> sounds good
13:56:51 <tangchen> one more thing
13:56:57 <tangchen> http://docs.openstack.org/contributor-guide/writing-style/word-choice.html
13:57:02 <rtheis> tangchen: just wondering if we can expand what is already done so commands have less to worry about, but I realize more is needed as you point out
13:57:04 <tangchen> someone showed me this...
13:57:24 <tangchen> OK, Richard. :)
13:57:42 <dtroyer> ooooh! nice!
13:58:22 <tangchen> What I want to ask is, are we going to accept patches like this ?
13:58:31 <tangchen> maybe...openstack->OpenStack
13:58:36 <tangchen> too trivial, I think
13:58:40 <dtroyer> for fixing docs?
13:58:44 <tangchen> yes
13:58:48 <rtheis> depends
13:58:52 <dtroyer> we'll accept them, but I really don't want to see one for each
13:58:53 <tangchen> there was one today.
13:58:59 <tangchen> yes
13:59:25 <tangchen> She abandoned finally. And maybe will give a big one at last.
13:59:29 <dtroyer> I used to do sweeps through fixing a bunch of help and docs all at once, broken by APi or something to keep it from getting too big
13:59:49 <tangchen> OK, I see.
13:59:59 <tangchen> no question for me today. :)
14:00:16 <dtroyer> but style and form do matter, so we do want to fix these things
14:00:52 <rtheis> agreed
14:01:01 <tangchen> OK
14:01:01 <rtheis> nothing else from me
14:01:10 <dtroyer> ok, we're out of time
14:01:13 <dtroyer> thanks guys!
14:01:22 <dtroyer> #endmeeting