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