19:08:19 #startmeeting OpenStackClient 19:08:20 Meeting started Thu May 7 19:08:19 2015 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:08:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:08:25 The meeting name has been set to 'openstackclient' 19:08:34 o/ 19:08:37 dang, I was too early 19:08:51 light agenda: https://wiki.openstack.org/wiki/Meetings/OpenStackClient#07_May_2015 19:08:55 #topic Summit planning 19:09:05 courtesy pings for dtroyer, dhellmann, stevemar, briancurtin, terrylhowe, lhcheng, sigmavirus24 19:09:32 current summit planning: https://etherpad.openstack.org/p/osc-liberty-summit-planning 19:09:55 I massaged the etherpad a bit for the schedule, no real content changes since last week 19:10:36 i think the amount of content is pretty good 19:10:56 I plan to push that into the schedule after the meeting 19:11:03 if i could add one more item... 19:11:37 federation support for osc, it should just be "use ksc plugins" 19:11:42 but i wanted to talk about it 19:11:52 maybe it can just be a side session with us and marekd 19:12:41 when would you do that? I don't think what I have will fill a session, want to do it then? 19:12:51 sure 19:13:47 ok, added 19:13:53 dtroyer, thanks 19:14:11 dtroyer, what do you mean by "Object Store commands"? do we have a list? 19:14:23 or just support more options and stuff 19:14:28 I don't have a list, it was #2 on the original list below 19:14:41 there are 'advanced' command that we don't have 19:15:26 have an example of one? or a way we can determine what's missing? 19:15:35 aside from using blanket terms :) 19:15:50 I don't, I'm not sure who wrote the pink text 19:16:03 we'd have to go a detailed comaprison with swiftclient again 19:16:19 i think that was terry 19:16:43 #4 is kind of done, and overlaps with ksc 19:16:53 This is good enough for the schedure, we can flesh it out in the session etherpad 19:17:10 i suppose 19:17:17 #4 is also going to change when I get back to writing code again 19:17:25 d'oh 19:17:30 one of the things I want to talk about is working out the precedence rules 19:17:52 I know there isn't consensus on how that should work 19:17:55 yeah 19:18:23 I think that's a work session topic 19:18:34 i don't think thats much of an issue, we just to state "this is the order" 19:18:41 is #7 done? I thought it might be but didn't find it 19:19:19 launchpad ¯\_(ツ)_/¯ 19:19:20 the issue with arguments is if env vars should even be included if —os-cloud is used 19:19:48 you mean don't evaluate env vars at all? 19:19:56 or only if --os-cloud is used? 19:20:15 don't use env vars at all if —os-cloud is used. 19:20:18 I don't agree with that 19:20:44 whats the use case for including them 19:20:50 there are well-established conventions how to do things like this in the UNIX world and I would like to follow those 19:20:56 i don't agree with that either... sounds fishy 19:21:54 dtroyer, going back to #7: yeah, it's done https://blueprints.launchpad.net/python-openstackclient/+spec/configuration-file 19:22:01 the example I wrote up is basically my situation at Nebula, having three clouds to switch between but someitmes needing to override project, I'd get MxN combinations in the config file without being to override that 19:23:28 oh so you put all your auth data into the config file 19:23:37 and OS_PROJECT=thing_you_need_now 19:23:47 rather than editing 19:23:49 you would have to without env vars 19:23:50 the file 19:23:54 yes 19:23:58 i like that 19:24:26 how about we prioritize things 19:24:33 OCC has some special handling for Rax regions but I think I'd use that the same way 19:24:45 sure 19:24:54 OCC has lowest priority, followed by env. vars, followed by inline args 19:25:12 works well if switching projects and such 19:25:20 and users 19:25:32 we could even ship config files that work with specific clouds 19:25:47 and have users only set uname/pass/project in env. 19:26:03 that's exactly what clouds-public.yaml is 19:26:18 I don't know if I'd want to package it, but we could point to a place to get one (them) 19:26:29 noice 19:26:53 Monty has reasonable defaults for 3 or 4 clouds in occ itself already anyway 19:27:31 so prioritization…want to do that now for a strawman to take into the session? 19:28:24 sessions are < 2 weeks away, i'm not pushing either position right now 19:28:34 if you want to hack something up, go ahead, i aint going to stop you 19:28:51 i don't think it'll change much 19:28:52 I thought you were talking about the session topics 19:29:28 yeah... i'm confused 19:29:49 meaning do we still chat about it at the session? 19:29:54 ok, so let's just move on to talking about releases, both priority topics can wait 19:30:09 okie 19:30:21 #topic releases 19:30:38 we didn't break everything with 1.2.0 \o/ 19:31:01 always a good thing! 19:31:03 so a couple of interesting things recently merged, want to do one more release before summit? 19:31:31 i'm down for that, it'll be nice to have the SP CRUD in 19:31:45 I thought you might want that… 19:32:09 so let's plan for Monday or Tuesday to do 1.3.0 19:32:17 this is the only not fixed, but targeted https://bugs.launchpad.net/python-openstackclient/+bug/1447704 19:32:17 Launchpad bug 1447704 in python-openstackclient "token issue fails for keystone v2 if OS_PROJECT_DOMAIN_NAME or OS_USER_DOMAIN_NAME are set" [Low,Triaged] - Assigned to Dean Troyer (dtroyer) 19:32:36 that's what sent me down the argparsing path 19:32:57 I hope I can get it resolved, but I'm not sure I want to merge it and release right away 19:33:34 it is low priority, with a workaround, that ... if fixed could hurt us bad 19:33:38 cost vs benefit 19:33:43 i'm okay with pushing it 19:33:57 ok 19:34:07 pushing it to m12 i mean 19:34:35 we just need to tell folks to unset OS_USER_DOMAIN_NAME and OS_PROJECT_DOMAIN_NAME 19:34:44 I would like to get some of my tests merged though, those also came out of that bug because we really don't properly test out global cli options 19:34:45 unless we apply another bandage :) 19:34:58 fair enough 19:35:18 we can release note that, we haven't [put known issues in there before but should for things like this 19:35:45 anything else you want to include? 19:36:34 that insecure/verify option is pretty bad 19:37:25 yeah, didn't someone propose a patch for that? 19:37:43 terry did, and I didn't like how he did it... 19:37:48 yar https://review.openstack.org/#/c/179367/ 19:38:19 let's get the test in for how it works now, then that one can fix the test 19:38:59 btw - "release before the summit" still leaves us with a decent sized window 19:39:07 I've got that branch (the —verify/—insecure tests) up riight now and should have https://review.openstack.org/179430 respun today 19:39:09 we can squeeze in a good amount of changed 19:39:40 your tests are failingzzz 19:40:13 I essentially disappear on Friday, let's cut off release window at wednesday at the latest? 19:40:32 fair enough 19:40:38 I wrote the test for hwo I want it to work, gotta make recognize what it is now 19:41:48 i dunno about this one 19:41:49 https://review.openstack.org/#/c/123539/ 19:42:09 I don't like those option names 19:42:12 did we include support for create/update to specify a parent project? 19:42:45 according to https://github.com/openstack/python-openstackclient/blob/master/openstackclient/identity/v3/project.py we did not 19:42:53 oh wait.. 19:42:55 i can't read 19:42:58 —paren tis there 19:43:01 —parent 19:43:32 I want the new options to match better 19:43:52 --children then? 19:44:04 can a project have multiple parents? 19:44:20 sort of 19:44:21 —children matches better than parent 19:44:30 not like mom and dad, but parent and grandparent 19:44:41 ok, so his use of 'parents' isn't wrong in the help 19:44:42 i mean that seriously 19:44:48 right 19:44:53 right, all the way up the tree 19:44:57 list should just be --parents and --children 19:45:16 the arguments should be singular: —parent and —child 19:45:18 err... "show" not list 19:45:29 why singular? 19:45:45 oh, so we also have to deal with another lits of items on a show output... 19:45:52 because everything in osc is singular 19:45:54 \o/ 19:46:14 doing those in csv is always fun 19:46:23 s/fun/broken 19:47:39 blah, i don't like lists in show output 19:47:45 but we do it in several spots already 19:48:02 so the python api takes parents_as_list and subtree_as_list? 19:48:15 yeah, don't ask 19:48:27 because there was another parents_as_something 19:48:46 Ill re-comment in that review and we can argue from there again 19:49:28 parents_as_ids is the alternate 19:50:30 I always think these things will be short… and here we are a ten-till 19:51:31 oh! one more topic for summit… Jamie and I had a long chant about taking over the world again the other night, but the 'what do we do about stable backports' needs to be clarified somewhere 19:51:52 hmmm… it seemed like a chant, some of the packaging bits get said over and over... 19:52:13 right, thats going to be an interesting discussion 19:52:18 stevemar: I think you were around for the beginnning, about https://review.openstack.org/180018 19:52:36 yep 19:52:50 dtroyer: stable backports? 19:53:33 ah. 19:53:44 yeah, we need to clarify that, bugs only 19:53:53 I wonder if we should install osc into a virtualenv in devstack, like we do with tempest 19:54:16 it works well, but is a sub-optimal user experience interactively 19:54:27 that was the first venv part I did, all clients actually 19:54:32 ah 19:54:44 but never merged it because the servers seemed like a better win 19:54:50 I haven't used devstack in a while, actually, so I'm still coming up to speed on recent changes 19:55:48 I swear I'm going to try pex any day now… 19:56:09 https://pypi.python.org/pypi/pipsi is interesting, too 19:56:53 I looked at that when starting the venv bits, ther was a reson I didn't persue it, need to find it in my notes 19:57:07 oh man 19:57:08 curl https://raw.githubusercontent.com/mitsuhiko/pipsi/master/get-pipsi.py | python 19:57:17 ^- lost any concept of credibility right there 19:57:27 yeah, that always inspires confidence in a project 19:57:42 * dhellmann notes that is how pip is installed, too 19:58:09 dhellmann: it is? 19:58:12 thoughts on backporting to stable? 19:58:14 get-pip.py? 19:58:19 sorry, derailing. ECHANNEL. 19:58:19 ah, it insists on everything in its own venv, which is exactly what folk didn't want for the servers 19:58:42 dtroyer: oh, I thought that's what we *were* doing? 19:58:58 I mean, I didn't want it, but I thought we were doing it anyway 19:58:59 pip might be sailing through on the dstufft exception because we know him? 19:59:11 dtroyer: both have a bootstrapping issue 19:59:18 dhellmann: no, we built some infrastructure to allow it, but it's not the default 19:59:23 ah, ok 19:59:25 I wrote the server venv code to be able to do that and tested it that way, but sdague wants to put them all in one by default 19:59:33 ++ 19:59:41 yeah, what he said 19:59:47 timeeee 19:59:47 although I guess we'll need 2 for the python 3 stuff 19:59:56 #endmeeting