13:14:32 <dtroyer> #startmeeting openstackclient
13:14:33 <openstack> Meeting started Thu Nov  3 13:14:32 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:14:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:14:36 <openstack> The meeting name has been set to 'openstackclient'
13:14:43 <dtroyer> apologies for the delay...
13:14:57 <dtroyer> huanxuan: what are your questions?
13:15:44 <huanxuan> I have a question about multi positional parameters, when will we allow multi positional parameters for one command? I sometimes see there are some commands have multi positional parameters. I am a little confused
13:16:45 <dtroyer> #link http://docs.openstack.org/developer/python-openstackclient/commands.html#command-object-s-and-action
13:17:03 <dtroyer> that is the doc descrbing commands that have two resources (or objects)
13:17:18 <dtroyer> positional arguments are always resources
13:18:03 <dtroyer> it is commands like add and remove that have two resources:   group add user <groupname> <username>
13:18:41 <huanxuan> dtroyer: oh! I think I get it now!
13:19:30 <huanxuan> so, about this review: https://review.openstack.org/#/c/378058/
13:19:58 <huanxuan> the create command
13:20:14 <huanxuan> "remote_ip_prefix" should be a optional parameter, right?
13:21:26 <dtroyer> yes, apparently it is required, so a 'required option', as funny as that sounds
13:22:25 <huanxuan> ok, get it, thank you
13:22:36 <dtroyer> wow, 'meter label rule' is an awkward name
13:23:21 <huanxuan> yea, seems like it
13:23:24 <dtroyer> also, thats an extension… I thought extensions went into the plugin… I'll follow up with rtheis on that, my memory may be faulty
13:23:56 <dtroyer> anything else?  it seem to be just us so far...
13:24:06 <huanxuan> ok, I will wait for rtheis suggestions
13:24:16 <huanxuan> yes another one
13:24:36 <sindhu> dtroyer: Hi, I am not sure if this is the correct forum/venue to ask this, but can you pls explain a lil abt the importance of SDK refactor?
13:24:51 <dtroyer> don't wait on him, I'm not sure how much more of his time we have
13:25:02 <rtheis> dtroyer: neutron extension for meter label rule?
13:25:45 <dtroyer> rtheis: yes, I recall that extensions were going to go into the neutronclient plugins, is my memory bad?
13:25:52 <rtheis> plan is neutron advanced services and features would be OSC plugins
13:26:08 <rtheis> extensions that are considered core features would be in OSC
13:26:21 <dtroyer> ok, thanks.
13:26:27 <rtheis> since nearly everything in neutron is an extension :(
13:26:32 <dtroyer> "core extension" is almost as funny as "required option" :)
13:26:39 <dtroyer> ah, ok
13:26:41 <rtheis> right
13:26:41 <dtroyer> thanks
13:26:48 <rtheis> yw
13:27:31 <dtroyer> sindhu: re SDK refactor:  we have time, can discuss here.  #openstack-sdks would be the usual place though
13:27:42 <rtheis> huanxuan: you can reach out to amotoki or armax if you'd like to double-check
13:27:44 <dtroyer> sindhu: are you referring specifically to the network refactor stuff?
13:28:09 <sindhu> dtroyer: yes
13:28:18 <huanxuan> rtheis: ok, thanks
13:29:01 <huanxuan> my another question is what the main problem of volume transfer commands, I did some work for those commands, so, I am willing to rework them if it is necessary
13:31:06 <dtroyer> huanxuan: it is my opinion that users will think of a volume transfer as a status condition of a volume, not a top-level resource.  it describes something about a volume
13:31:14 <mattt> n/close
13:31:35 <dtroyer> so exposing it that way will make more sense than treating it like a thing
13:31:52 <dtroyer> users don't care how a thing is implemented int he database
13:32:28 <huanxuan> dtroyer: yes, sounds reasonable.
13:33:54 <huanxuan> so, what can we do to rework it, do you have some suggestions?
13:34:34 <dtroyer> for example, rather than 'create' we should use volume set —transfer
13:35:08 <dtroyer> and volume list —transfer to list volumes in that state, etc
13:35:31 <huanxuan> oh, I see, it sounds good
13:36:17 <dtroyer> sindhu: did you have something specific about the refactor?
13:37:27 <sindhu> dtroyer: just wanted to know the purpose of doing it :)
13:38:17 <dtroyer> it is because of changes that briancurtin is making to the SDK.  Since we started using the SDK before the 1.0 release for Network, we have to adapt to those changes and be able to work with both API styles
13:38:41 <dtroyer> it is exactly why we are not using the SDK for anything else until 1.0 release
13:39:22 <sindhu> dtroyer: you mean for compute and volume?
13:39:53 <dtroyer> yes, and the others too
13:40:25 <sindhu> dtroyer: Ok, cool. thanks!
13:40:53 <sindhu> dtroyer: will look into the changes being made :)
13:42:11 <dtroyer> anything else anyone?
13:42:15 <huanxuan> dtroyer: about the transfer rework, If needed, I will try to do it, I will going to report a bug or blueprint for it, you can check the report first to see if it make sense or not
13:42:24 <dtroyer> I'm still in summit-recovery so not much here
13:43:21 <dtroyer> huanxuan: ok, sounds good.  I do think there will be one thing we have to deal with that doesn't fit well, that is cleaning up old, unused transfers in the database.  I don't have that sorted out yet, maybe you will have a good idea!
13:43:41 <huanxuan> I will try it :)
13:45:19 <dtroyer> if nothing else, we'll end early…
13:45:23 <dtroyer> thanks everyone!
13:45:29 <huanxuan> thanks !
13:45:37 <sindhu> thanks!
13:45:43 <dtroyer> #endmeeting