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