19:06:24 <dtroyer> #startmeeting openstackclient
19:06:25 <openstack> Meeting started Thu Mar 10 19:06:24 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:06:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:06:28 <openstack> The meeting name has been set to 'openstackclient'
19:06:55 <dtroyer> looks like a good turnout so far, let's get started...
19:07:03 <dtroyer> #topic reviews
19:07:35 <dtroyer> There has been a good bit of activity this week, any specific reviews that need highlighting?
19:08:22 <rtheis> https://review.openstack.org/#/c/290785/ is good for team awareness
19:08:26 <rtheis> thanks dtroyer
19:09:17 <dtroyer> I added the rest that I wrote lastnight before 'quickdraw' stevemar did his edits...
19:09:29 <rtheis> nice
19:09:38 <dtroyer> so there is anow a general section too that should just show what we currently do
19:09:45 <dtroyer> a new***
19:10:24 <dtroyer> I think we need to keep doing these docs as the tribal knowledge is exposed with all of the newer contributions
19:10:40 <dtroyer> which, btw, is fantastic!
19:10:45 <rtheis> I agree
19:11:07 <dtroyer> I'm hoping to even write some code again soon ;)
19:11:28 <dtroyer> ok, I'll throw out one thing that I brought up in the last day or so
19:12:01 <rtheis> https://review.openstack.org/#/c/290138/ ... this is still a WIP but I was interested in opinions on the command object name.  It is currently "segment" but am considering a change to "network segment".
19:12:27 <dtroyer> https://review.openstack.org/#/c/288441/ and another? review around 'ip floating' work
19:12:36 <dtroyer> (will come back to mine, reading rtheis comment)
19:13:42 <dtroyer> that needs a deeper read, but yeah, I think 'network segment' is a clearer resource name
19:14:18 <rtheis> dtroyer: thanks
19:14:23 <dtroyer> that create command may take some thinking too ;)
19:15:11 <rtheis> yeah, neutron team is still working out API details.
19:15:22 <dtroyer> so this is totally new?
19:15:25 <rtheis> yes
19:15:38 <rtheis> REST API is still a WIP
19:15:55 <dtroyer> request #1 - don't allow the user to specify the ID (similar to how flavors work)
19:16:05 <dtroyer> I say that because —segmenetation-id looks liek it might be that?
19:16:42 <rtheis> I think I need to change the name on that since it isn't a resource UUID
19:17:01 <dtroyer> I wondered if I misunderstood what it was...
19:17:27 <rtheis> it is a vlan ID when vlan used
19:17:37 <dtroyer> but thanks, the ability to suss out the CLI when the REST API is still in development is nice, we can hopefully make it better from a user perspecive early on
19:18:43 <rtheis> neutron team will probably want this command in python-neutronclient as an OSC plugin ... which I'm looking at now
19:19:04 <dtroyer> uh, we don't use neutronclient and I don't want to re-add it.
19:19:20 <dtroyer> but yeah, a plugin should work ok
19:20:32 <dtroyer> any more there?
19:20:38 <rtheis> nothing else
19:20:43 <dtroyer> back to https://review.openstack.org/#/c/288441/ then
19:21:13 <dtroyer> I remarked in that review, or the other one I can't find ATM about how the 'ip floating' (and ip fixed too) resources are poorly formed commands
19:21:20 * dtroyer did that early one
19:22:06 <rtheis> here's the other https://review.openstack.org/#/c/262397
19:22:06 <dtroyer> I think we should go ahead and fix what needs fixing with them, we need to maintain compatability, but this might be a case where we re-implement them as 'floating ip' and 'fixed ip' with the more consistent comamnd structure
19:22:51 <dtroyer> I didn't want my comments to seem like we shouldn't move forward here
19:23:47 <dtroyer> it does raise the situation where we might want to look at command aliases again
19:24:02 <dtroyer> but in this case I want to change the arguements
19:25:05 <rtheis> ip floating delete, list and show refactors have merged already ... did you want to back those out?
19:25:17 <dtroyer> no, we should finish that work
19:25:30 <dtroyer> but changes, such as making pool optional, should wait
19:25:46 <dtroyer> there are a couple of things in those commands I did wrong initially
19:27:36 <rtheis> ok, so keep the refactor going but save incompatible changes for re-implemented commands ?
19:27:43 <dtroyer> yes
19:27:50 <rtheis> sure
19:28:06 <rtheis> apply new commands to network and compute or just network
19:28:49 <dtroyer> both
19:28:54 <rtheis> ok
19:29:00 <dtroyer> we'll be supporting nova-net for some time yet
19:29:35 <dtroyer> when the refactor is complete, I'll take a stab at the new parser configuration…
19:29:51 <rtheis> the release notes for the refactor claim that Command ``ip floating delete`` is now available for neutron network.
19:29:58 <rtheis> similar for list and show
19:30:09 <rtheis> did these not work for neutron before...I haven't tried
19:30:32 <dtroyer> I thought they had not been implemented yet
19:31:27 <rtheis> Not with direct calls to neutron, but wasn't sure if they were pass through nova to neutron like security groups
19:32:36 <dtroyer> I think they were
19:32:45 <rtheis> ok
19:33:25 <dtroyer> any other reviews to talk about?
19:34:14 <dtroyer> ok, how about…
19:34:17 <dtroyer> #topic bugs
19:35:27 <rtheis> I think it would be good to fix https://bugs.launchpad.net/python-openstackclient/+bug/1554302
19:35:27 <openstack> Launchpad bug 1554302 in python-openstackclient "Error message improvement in OSC commands" [Medium,Confirmed] - Assigned to Tang Chen (tangchen)
19:36:11 <rtheis> Tang noted that he hasn't found a way to improve it in the bug description
19:36:12 <dtroyer> yes, we rely too much on the exception-from-HTTP-resposnse
19:36:31 <dtroyer> this is another reason I wrote up that doc about command errors
19:36:32 <rtheis> curious if anyone has ideas on how to fix
19:37:08 <dtroyer> it'll take a bit of work to create the list of exceptions/error messages to look for
19:37:29 <singhj> what are some other instances when that error is returned?
19:37:29 <dtroyer> and is complicated by the non-standard way many errors are returned…ie, they are not specified in the APi and are subject to change
19:37:45 <singhj> I know that the extensions missing case is one
19:38:09 <dtroyer> the API WG has spent time with trying to nail error handling down a bit at the REST level, we would benefit greatly from services doing that
19:38:48 <dtroyer> I do think, though, a generic bug like this isn't so useful…how do we know when it is closed?
19:39:26 <rtheis> If we focus on network case, there is often error message details available
19:39:36 <dtroyer> Jas, the extensions missing is another example of where we need to add specific error handling in commands
19:39:38 <rtheis> neutronclient will extract those
19:39:57 <dtroyer> right, but they are subject to change IIRC, they are not considered part of the API contract
19:40:15 <dtroyer> we can best-effort those, and that's about it for now
19:40:22 <rtheis> ok
19:40:59 <dtroyer> when we do, we should put a copy of the reference error message in a comment so if/when it changes we know what was used to generate the detection code
19:41:46 <dtroyer> this is something else that should go in that doc I proposed yesterday, once we sor tit out
19:42:09 <rtheis> +1
19:42:49 <singhj> so you guys are planning to map the returned messages with something the user will get?
19:43:40 <dtroyer> When the response from the server isn't so useful to the end user, yes
19:43:57 <dtroyer> and we have a lot of that right now
19:44:22 <dtroyer> it varies per service since they mostly vary to some degree
19:46:11 <dtroyer> in other bug news, I'm going to combine https://bugs.launchpad.net/python-openstackclient/+bug/1554892 and https://bugs.launchpad.net/python-openstackclient/+bug/1554893, this is just breaking things apart too far.  plus, it should be part of the volume blueprint
19:46:11 <openstack> Launchpad bug 1554892 in python-openstackclient "Add support for Un-manage Volume(Stop managing a volume) " [Undecided,New] - Assigned to Sheel Rana (ranasheel2000)
19:46:12 <openstack> Launchpad bug 1554893 in python-openstackclient "Add support for manage volume functionality" [Undecided,New] - Assigned to Sheel Rana (ranasheel2000)
19:46:45 <rtheis> sounds good
19:47:41 <dtroyer> any others?
19:47:48 <rtheis> nothing else from me
19:49:03 <dtroyer> #open discussion
19:49:19 <dtroyer> #topic open discussion
19:49:27 * dtroyer irc-command-fail
19:49:46 <dtroyer> What else shanll we talk about?
19:49:55 * dtroyer spelling-fail too
19:50:01 <rtheis> http://logs.openstack.org/75/286275/7/check/check-osc-plugins/b23e206/console.html  ... "Some commands overlap..." is the error for check-ose-plugins job
19:50:02 <dtroyer> good grief
19:50:17 <rtheis> stevemar ^
19:51:08 <rtheis> wondering about stevemar's plan on how we should resolve these errors
19:51:21 <dtroyer> they detect errors in other repos
19:51:31 <rtheis> I wasn't sure who to contact
19:52:00 <dtroyer> and I see some that look like they really don't follow our reccommended structure
19:52:28 <dtroyer> I think the error message there could be more helpful
19:52:38 <rtheis> yeah
19:52:53 <dtroyer> that might make a nice afternoon diversion
19:53:26 <dtroyer> I also think there is a limit to how far we can expect to police outside commands like this
19:53:54 <dtroyer> time to re-draw the layer map and make a cutoff maybe?
19:55:16 <rtheis> possibly, yes.  When I get some time, I'll try looking into the error
19:56:12 <dtroyer> anything else?
19:56:28 <rtheis> nothing else from me
19:56:49 <singhj> for the extension error message issue, I had some ideas
19:57:29 <dtroyer> ok
19:58:08 <singhj> maybe keep track of which options need which extension
19:58:29 <singhj> and upon error, check if required extensions exist
19:58:49 <singhj> via client.find_extension(ext)
19:58:52 <dtroyer> keeping track is a great idea
19:59:09 <dtroyer> what do you do different though if the extenion exists but there was a failire?
19:59:10 <rtheis> singhj: related code that may help here: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/common/availability_zone.py#L151
19:59:55 <singhj> well I was planning to catch the exception locally and checking and then just raising it up again if it weren't the reason
19:59:56 <dtroyer> ah, yes, ok
20:00:51 <rtheis> singhj: you could also check the extension if the option was specified to know before making the request
20:01:16 <dtroyer> I think I'd rather handle the error and incur the overhead only then rather than on every call
20:01:17 <rtheis> as long as users have access to list extensions
20:01:23 <dtroyer> we're at time…continue in -sdks?
20:01:30 <dtroyer> #endmeeting