19:01:18 #startmeeting openstackclient 19:01:19 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:23 The meeting name has been set to 'openstackclient' 19:01:27 who is here? 19:09:06 me 19:09:10 :) 19:10:20 o/ 19:10:30 I have just one item: https://review.openstack.org/#/c/396727/ discussion over introducing new command "replace" 19:10:55 dtroyer: I will let you and armax: figure out how to proceed with Auto Allocated Topology 19:12:50 so what is being set in network tag is what? You are really setting a tag on another resosurce, correct? 19:13:01 correct 19:13:14 so 'add' 'remove' 19:13:22 currently only enabled for networks 19:13:31 so —tag for set and unset should be the way to do it 19:13:44 'network tag' is itself not a resource 19:16:13 so the full command would be 19:16:40 "openstack tag add network --resource-type networks --tag "blah" 19:16:44 that seems convoluted 19:16:55 network set —tag 19:17:29 why would you go anywhere other than 'network' resrouce to set a tag on a network? 19:18:33 a tag isn't a thing by itself, it is an attribute of a thing 19:18:37 where thing == resource 19:20:09 okay. network set, network unset makes sense. 19:20:17 how would i deal with the replace. 19:20:28 what is does is removes all existing tags on a resource and puts on new ones 19:20:55 we've done that elsewhere in the network commands: network set —no-tags —tag a —tag b mynet 19:21:32 also, I think unset has an —all-XXX option 19:21:40 so two ways to clear the list 19:21:46 * stevemar sneaks in 19:23:14 look at router: set —no-route —route XXX does the same type of thing 19:23:21 and unset —route 19:23:52 so we do 'replace' with '—no-XXX —XXXX ' 19:24:03 got it will take a look. thanks 19:24:28 I do want to talk about https://review.openstack.org/#/c/391331/ a bit 19:24:58 Did you go through Armando's comments? 19:25:17 I just saw them 19:25:27 I think 'least surprise' is what we need to aim for 19:25:54 if the API has a —dry-run option, show can be implemented with that, right? that way nothing actually changes? 19:26:20 --dry-run option does something really stupid. It validates that all the other resources have been set up 19:26:24 then returns True or False 19:26:47 oh, so not like it means in, say, rsync? 19:27:05 then yeas, the comment to rename that is a good one 19:27:17 but rats, I thought that might be a way to safely at least see what was there 19:27:36 ok, I'll respond in the review 19:28:28 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 that would be the way to do a show command then. 19:29:07 the --dry-run option returns the same dictionary values except instead of 'id' : <###> it returns 'id': 19:29:14 and if create when one exists errors, I think users would understand 19:29:46 so then i cud just replace with the previously grabbed id 19:29:55 and have a —or-show option on create and that will exactly replicate the neutronclient behaviour as I understand it 19:30:39 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 no, not required. if it isn't present… I _really_ want the commands to behave the same everywhere 19:31:58 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 so then if the --or-show option isn't present it holds the same functionality if the option was there. 19:33:39 yea there will have to be beefed up docs for this one 19:33:59 for sure 19:34:38 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 okay. Will stab at both network tag and AAT by EOW 19:37:14 great, thanks! 19:37:21 https://review.openstack.org/#/c/382530/ looks fine to me may need extra eyes 19:37:28 do either of those require unreleased SDK stuffs? 19:37:54 tag is implemented as a plugin within Neutronclient. AAT SDK has been merged couple days ago 19:38:36 but not released? 19:38:44 oh, wait… tag is a plugin? not in SDK? 19:39:01 yea 19:39:12 which? 19:39:20 tag is a plugin 19:39:44 ugh, no wonder it iwas going to be its own command… OSc itself doesn't use neutronclient 19:40:04 and we don't (yet) have a way for plugins to extend other commands 19:40:10 yes I probably should have clarrified 19:41:29 so that just isn't going to work 19:42:09 and we can't merge AAT until the sdk bits show up in a release 19:42:17 and g-r is updated 19:43:04 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 yea. but i have sinking feeling AAT will take some time to get everyone to agree :) 19:43:37 ankur-gupta-f: will that mean SDK changes? or is what is there going to be enough? 19:43:56 what is there is good enough for what we want to do with OSC 19:44:05 briancurtin: no worries, I just have a hard time keeping track of what OSC reviews also need SDK releases 19:44:14 ankur-gupta-f: cool 19:45:33 moving on… 19:45:44 yes please. 19:46:08 stevemar: Do you have an opinion on the last comments in https://review.openstack.org/#/c/352477/ re argument order? 19:46:19 dtroyer: literally just sat down :) 19:46:42 * dtroyer doesn't give away how he knew that 19:46:58 dtroyer: which arguments, the create ones? 19:48:01

19:48:24 that feels backward to me, we don't have a precedent for most-specific first or last anywhere 19:48:43 ah right, for 'set' 19:48:49 the order above is how neutronclient does it 19:48:51 and show 19:48:55 for any command that needs both 19:48:57 and... delete 19:49:00 :) 19:49:25 DNS is the only common place I can come up with that does more-specific first ordering 19:49:34 dtroyer: https://github.com/openstack/python-openstackclient/blob/master/doc/source/command-objects/object.rst 19:49:43 we do