19:01:18 <dtroyer> #startmeeting openstackclient
19:01:19 <openstack> Meeting started Thu Dec  8 19:01:18 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:23 <openstack> The meeting name has been set to 'openstackclient'
19:01:27 <dtroyer> who is here?
19:09:06 <ankur-gupta-f> me
19:09:10 <ankur-gupta-f> :)
19:10:20 <dtroyer> o/
19:10:30 <ankur-gupta-f> I have just one item: https://review.openstack.org/#/c/396727/ discussion over introducing new command "replace"
19:10:55 <ankur-gupta-f> dtroyer: I will let you and armax: figure out how to proceed with Auto Allocated Topology
19:12:50 <dtroyer> so what is being set in network tag is what?  You are really setting a tag on another resosurce, correct?
19:13:01 <ankur-gupta-f> correct
19:13:14 <ankur-gupta-f> so 'add' 'remove'
19:13:22 <ankur-gupta-f> currently only enabled for networks
19:13:31 <dtroyer> so —tag for <resource> set and unset should be the way to do it
19:13:44 <dtroyer> 'network tag' is itself not a resource
19:16:13 <ankur-gupta-f> so the full command would be
19:16:40 <ankur-gupta-f> "openstack tag add network --resource-type networks --tag "blah"
19:16:44 <ankur-gupta-f> that seems convoluted
19:16:55 <dtroyer> network set —tag <tag> <network>
19:17:29 <dtroyer> why would you go anywhere other than 'network' resrouce to set a tag on a network?
19:18:33 <dtroyer> a tag isn't a thing by itself, it is an attribute of a thing
19:18:37 <dtroyer> where thing == resource
19:20:09 <ankur-gupta-f> okay. network set, network unset makes sense.
19:20:17 <ankur-gupta-f> how would i deal with the replace.
19:20:28 <ankur-gupta-f> what is does is removes all existing tags on a resource and puts on new ones
19:20:55 <dtroyer> we've done that elsewhere in the network commands:  network set —no-tags —tag a —tag b mynet
19:21:32 <dtroyer> also, I think unset has an —all-XXX option
19:21:40 <dtroyer> so two ways to clear the list
19:21:46 * stevemar sneaks in
19:23:14 <dtroyer> look at router:   set —no-route —route XXX <router> does the same type of thing
19:23:21 <dtroyer> and unset —route
19:23:52 <dtroyer> so we do 'replace' with '—no-XXX —XXXX <arg>'
19:24:03 <ankur-gupta-f> got it will take a look. thanks
19:24:28 <dtroyer> I do want to talk about https://review.openstack.org/#/c/391331/ a bit
19:24:58 <ankur-gupta-f> Did you go through Armando's comments?
19:25:17 <dtroyer> I just saw them
19:25:27 <dtroyer> I think 'least surprise' is what we need to aim for
19:25:54 <dtroyer> if the API has a —dry-run option, show can be implemented with that, right?  that way nothing actually changes?
19:26:20 <ankur-gupta-f> --dry-run option does something really stupid. It validates that all the other resources have been set up
19:26:24 <ankur-gupta-f> then returns True or False
19:26:47 <dtroyer> oh, so not like it means in, say, rsync?
19:27:05 <dtroyer> then yeas, the comment to rename that is a good one
19:27:17 <dtroyer> but rats, I thought that might be a way to safely at least see what was there
19:27:36 <dtroyer> ok, I'll respond in the review
19:28:28 <ankur-gupta-f> since there is only one auto_allocated_topology per project, it may be possible to do a check if it exists and through different methods return the id of topology
19:28:48 <dtroyer> that would be the way to do a show command then.
19:29:07 <ankur-gupta-f> the --dry-run option returns the same dictionary values except instead of 'id' : <###> it returns 'id': <dry-run=True>
19:29:14 <dtroyer> and if create when one exists errors, I think users would understand
19:29:46 <ankur-gupta-f> so then i cud just replace <dry-run=True> with the previously grabbed id
19:29:55 <dtroyer> and have a —or-show option on create and that will exactly replicate the neutronclient behaviour as I understand it
19:30:39 <ankur-gupta-f> but it would have to be a required option. "create --or-show" "create --or-show --dry-run" and "delete" would then be the actions
19:31:28 <dtroyer> no, not required.  if it isn't present…   I _really_ want the commands to behave the same everywhere
19:31:58 <dtroyer> we might be able to live with documenting that create always has an implied —or-show, but that's second choice to me
19:33:19 <ankur-gupta-f> so then if the --or-show option isn't present it holds the same functionality if the option was there.
19:33:39 <ankur-gupta-f> yea there will have to be beefed up docs for this one
19:33:59 <dtroyer> for sure
19:34:38 <dtroyer> if there is no simple way to error on create when it already exists, then yes, —or-show would be essentially defaulted to True
19:36:57 <ankur-gupta-f> okay. Will stab at both network tag and AAT by EOW
19:37:14 <dtroyer> great, thanks!
19:37:21 <ankur-gupta-f> https://review.openstack.org/#/c/382530/ looks fine to me may need extra eyes
19:37:28 <dtroyer> do either of those require unreleased SDK stuffs?
19:37:54 <ankur-gupta-f> tag is implemented as a plugin within Neutronclient. AAT SDK has been merged couple days ago
19:38:36 <dtroyer> but not released?
19:38:44 <dtroyer> oh, wait… tag is a plugin?  not in SDK?
19:39:01 <ankur-gupta-f> yea
19:39:12 <dtroyer> which?
19:39:20 <ankur-gupta-f> tag is a plugin
19:39:44 <dtroyer> ugh, no wonder it iwas going to be its own command… OSc itself doesn't use neutronclient
19:40:04 <dtroyer> and we don't (yet) have a way for plugins to extend other commands
19:40:10 <ankur-gupta-f> yes I probably should have clarrified
19:41:29 <dtroyer> so that just isn't going to work
19:42:09 <dtroyer> and we can't merge AAT until the sdk bits show up in a release
19:42:17 <dtroyer> and g-r is updated
19:43:04 <briancurtin> dtroyer: we can probably release soon, i’m waiting on one thing to figure out of it can be in the next release or if the fix should wait for another approach that is in progress
19:43:04 <ankur-gupta-f> yea. but i have sinking feeling AAT will take some time to get everyone to agree :)
19:43:37 <dtroyer> ankur-gupta-f: will that mean SDK changes?  or is what is there going to be enough?
19:43:56 <ankur-gupta-f> what is there is good enough for what we want to do with OSC
19:44:05 <dtroyer> briancurtin: no worries, I just have a hard time keeping track of what OSC reviews also need SDK releases
19:44:14 <dtroyer> ankur-gupta-f: cool
19:45:33 <dtroyer> moving on…
19:45:44 <ankur-gupta-f> yes please.
19:46:08 <dtroyer> stevemar: Do you have an opinion on the last comments in https://review.openstack.org/#/c/352477/ re argument order?
19:46:19 <stevemar> dtroyer: literally just sat down :)
19:46:42 * dtroyer doesn't give away how he knew that
19:46:58 <stevemar> dtroyer: which arguments, the create ones?
19:48:01 <dtroyer> <qos-rule> <qos-policy>
19:48:24 <dtroyer> that feels backward to me, we don't have a precedent for most-specific first or last anywhere
19:48:43 <stevemar> ah right, for 'set'
19:48:49 <dtroyer> the order above is how neutronclient does it
19:48:51 <stevemar> and show
19:48:55 <dtroyer> for any command that needs both
19:48:57 <stevemar> and... delete
19:49:00 <dtroyer> :)
19:49:25 <dtroyer> DNS is the only common place I can come up with that does more-specific first ordering
19:49:34 <stevemar> dtroyer: https://github.com/openstack/python-openstackclient/blob/master/doc/source/command-objects/object.rst
19:49:43 <stevemar> we do <container> <object>
19:49:44 <dtroyer> duh
19:49:47 <dtroyer> of course
19:49:49 <dtroyer> thanks
19:49:51 <stevemar> so less specific -> more specific
19:50:00 <stevemar> :)
19:50:03 * dtroyer sends a dessert pizza to stevemar
19:50:08 <dtroyer> thanks
19:50:16 <stevemar> i'm intrigued by this concept
19:50:44 <dtroyer> it's a great bikeshed
19:51:03 <stevemar> (i meant the concept of a dessert pizza, not the ordering)
19:51:49 <dtroyer> oh, cherry pie filling, cinnamon, frosting on a pizza crist
19:52:01 <dtroyer> you name it, Pizza Ranch has it :)
19:52:18 <stevemar> :)
19:52:26 <dtroyer> the only other thing on my list is Adam's https://review.openstack.org/290253
19:52:40 <dtroyer> No other keystoners have weighed in on that, is it a thing or not?
19:54:12 <stevemar> it's a thing
19:54:15 <dtroyer> and no, I have not asked him directly yet
19:54:21 <stevemar> but he has to fix the client first: https://bugs.launchpad.net/python-keystoneclient/+bug/1647934
19:54:21 <openstack> Launchpad bug 1647934 in python-keystoneclient "implied role get fails with key error" [Medium,Confirmed]
19:54:37 <dtroyer> ah, ok.  so that's whe the periodic rebase
19:54:41 <stevemar> but we support the routes on the server side, so we should have client bindings
19:54:52 <dtroyer> if it is going to merge someday we should get it cleaned up so it is ready then
19:55:01 <stevemar> dtroyer: we? :)
19:55:14 <dtroyer> :)
19:55:20 <dtroyer> I'll review it, he can clean it
19:55:27 <stevemar> :)
19:55:31 <dtroyer> you can keep PTL'ing for a few more months
19:55:39 <stevemar> \o/
19:55:47 <dtroyer> 5 min warning, anything else?
19:55:51 <stevemar> umm
19:55:56 <huanxuan> dtroyer, stevemar: tangchen let me tell you that he has changed his work and he is not allowed to work on OpenStack now, he is very sorry for that and he will try him best to do something help in OSC in his spare time
19:56:11 <stevemar> huanxuan: oh no :(
19:56:17 <huanxuan> :(
19:56:33 <stevemar> huanxuan: let him know that i appreciated all the work he did
19:56:39 <dtroyer> huanxuan: thanks for relaying the message, and let tangchen know we are sorry to hear about that
19:56:42 <huanxuan> haven't see him for a long time
19:56:50 <huanxuan> yes I will
19:57:14 <dtroyer> so, we have a quorum of cores here then
19:57:32 <dtroyer> I move huanxuan gets +2, do I have a second?
19:57:37 <stevemar> yep!
19:57:57 <dtroyer> huanxuan: welcome to the core team, as soon as I get it added in Gerrit
19:58:01 <huanxuan> really!! I am very happy to hear that !!!
19:58:07 <ankur-gupta-f> nice!
19:58:12 <huanxuan> thanks very much!!!
19:58:20 <stevemar> huanxuan: you've done amazing work ^_^
19:58:23 <huanxuan> I am very honor to join !!
19:58:25 <dtroyer> we are very thankful for the work you have done and have certainly proved your ability and judement
19:58:28 <dtroyer> thank you very much
19:58:48 <huanxuan> thanks !  I will continue to do more works for OSC!
19:59:03 <stevemar> :)
19:59:07 <dtroyer> that's why we trap you as a core :)
19:59:32 <stevemar> congrats huanxuan o\
19:59:37 <huanxuan> ^ ^ thank!
20:00:14 <dtroyer> added… use your new powers and continue to do good work
20:00:26 <dtroyer> and thanks everyone, we are out of time
20:00:35 <ankur-gupta-f> thanks all. And congrats huanxuan
20:00:36 <huanxuan> really exciting to hear that~~~~
20:00:37 <dtroyer> #endmeeting