19:03:32 <dtroyer> #startmeeting openstackclient
19:03:34 <openstack> Meeting started Thu Jan  5 19:03:32 2017 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:37 <openstack> The meeting name has been set to 'openstackclient'
19:04:13 <stevemar> howdy
19:04:20 <dtroyer> Thanks to stevemar and huanxuan we have an actual agenda at
19:04:23 <dtroyer> #link https://etherpad.openstack.org/p/osc-weekly-meeting
19:04:38 <huanxuan> o/
19:04:56 <huanxuan> hi dtroyer and stevemar
19:05:01 <stevemar> hi huanxuan!
19:05:12 <dtroyer> courtesy meeting ping: dhellmann, rtheis,, sheel,, thingee, ankur-gupta-f
19:05:37 <dtroyer> #topic releases
19:05:47 <dtroyer> Lets start with a release bit first though, should be quick
19:05:56 <huanxuan> ok
19:06:13 <dtroyer> I'd like to get two releases in before the freeze, one early next week and the second a week or so later
19:06:34 <dtroyer> this touches on 	▪	https://review.openstack.org/412614
19:06:49 <dtroyer> in that introduces volume v3, but is not complete.
19:07:03 <stevemar> dtroyer: that sounds good. we're 2 weeks away from non-client library freeze, and 3 weeks aware from library freeze
19:07:18 <dtroyer> do we want to hold off on that until it is more complete?  I'm unsure about leaving something partly done like that in a stable release
19:07:55 <stevemar> how is it "partly done" ?
19:08:18 <dtroyer> AIUI it is just a clone of v2 at this point, no new changes
19:08:34 <huanxuan> yes it almost is
19:09:04 <huanxuan> there are some new features in v3
19:09:21 <dtroyer> are those features im plemented in the initial review?
19:09:26 <stevemar> no they are not
19:09:50 <dtroyer> that's what I mean about incomplete… that might give off bad expectations to say 'v3' and not have anything that really is v3 yet
19:10:22 <stevemar> we've never claimed support for an entire API version as being "complete"
19:10:31 <dtroyer> to flip the coin, will it be less frustrating for users to have a stable release with a) and incomplete v3 or b) no v3?
19:10:39 <dtroyer> no, but it doesn't do _anything_ new yet
19:11:04 <stevemar> we claimed we had v2 support for cinder last release when we didn't have most of it done yet
19:11:43 <dtroyer> but it used a v2 endpoint.
19:11:55 <stevemar> this one doesn't?
19:11:56 <dtroyer> see? I can defend both positions here, somebody push me one way or the other! :)
19:12:25 <stevemar> i'm not sure how many users actually use volume api v3
19:12:28 <dtroyer> I don't think our volume discovery is 'done' and there is no microversioning yet
19:13:39 <dtroyer> what I'd like to do is have the next release be our stable (modulo bug fixes) and the release just before freeze be our continuing development to get us into a solid place during the freeze
19:14:09 <dtroyer> last cycle was frustrating with the amount of stuff that piled up, I'm thinking that's a great time to work on the tests (more to come on that later)
19:14:31 <dtroyer> so here is a proposal:
19:14:48 <dtroyer> * we hold off on the volume v3 review until after the next release
19:14:52 <stevemar> eh... i can go either way, i see the point of delivering something incomplete
19:15:01 <dtroyer> * after the next release we only do bug fixes for a couple of days
19:15:17 <dtroyer> * whatever we have there becomes stable (way early yes, but there is a reason)
19:15:36 <dtroyer> then we can get in the v3 and other new features and release the first post-stable before the freeze
19:15:56 <dtroyer> thoughts?
19:16:14 <stevemar> i can dig it
19:16:33 <huanxuan> I agree
19:16:45 <stevemar> we're old and used by too many things to go crazy with features at the last minute
19:17:27 <stevemar> one release, then another release with bug fixes  => what we deliver for ocata ... sounds good to me
19:17:36 <dtroyer> ok, we'll run with that then…
19:17:49 <dtroyer> moving on…
19:17:52 <dtroyer> #topic bugs
19:18:37 <dtroyer> lets start with hhttps://bugs.launchpad.net/os-client-config/+bug/1635696
19:18:37 <openstack> Launchpad bug 1635696 in os-client-config "Having a '{' or '}' in password causes formatting errors" [High,Confirmed]
19:18:53 <dtroyer> no, that's not what I meant, but we'll go with it
19:19:31 <stevemar> hmm?
19:19:35 <dtroyer> this one was introduced when o-c-c started using the new string substitution syntax
19:19:54 <dtroyer> so we either need to undo that or start escaping strings
19:20:35 <stevemar> i'm not sure how impactful it is, so far 2 users have hit it
19:21:14 <dtroyer> that we know of…  yeah, not sure if it's High or Medium actually
19:21:37 <dtroyer> but it applies to _all_ config values that o-c-c handles, not just passwords
19:22:34 <stevemar> like username and such
19:22:54 <stevemar> though why you would have { or } in user or proejct name is beyond me
19:23:07 <dtroyer> right, I don't know where else to expect to see this
19:23:44 <dtroyer> we should kick ot over with mordred and shrews and see of they've run across anything and have a preference
19:23:44 <stevemar> i don't know where the fix goes for this, otherwise i'd jump in
19:24:04 <dtroyer> it's o-c-c, that is what introduced the issue
19:24:34 <dtroyer> we could work around it in osc or osc-lib, but we have a lot of that crap already that I'm trying to remove
19:25:44 <dtroyer> I think since it isn't a top priority, we can take the time to talk with the other o-c-c cores
19:26:21 <mordred> oh
19:26:23 <mordred> wow
19:26:59 <mordred> yeah. let's ... uhm ... fix that
19:27:03 <dtroyer> hey mordred!  welcome…
19:27:18 <stevemar> o/ mordred
19:28:32 <stevemar> mordred: any take on this one? have you run into this issue in occ/shade?
19:28:45 <mordred> I haven't - but then I also haven't had any { in passwords
19:29:15 <dtroyer> I think it affects any config values, but we couldn't come up with a place that '{' chars might be common
19:29:31 <mordred> password seems like the most likely place
19:29:53 <dtroyer> since that's user-changeable I don't think this is a top priority
19:29:54 <mordred> I wonder if maybe we just don't run the substitution on the password field :)
19:29:58 <stevemar> i would think the fix happens here: https://github.com/openstack/os-client-config/blob/master/os_client_config/config.py#L789-L823
19:30:14 <mordred> I cna't come up with ANY reason for using substitution vars in your password
19:30:46 <stevemar> definitely not
19:30:57 <dtroyer> stevemar: are there other auth password-like attributes that might need this fix?
19:31:21 <stevemar> maybe if you are using ADMIN_TOKEN?
19:32:03 <dtroyer> pkiz is old news, what is the char set for fernet tokens?  I think UUID is safe
19:32:55 <dtroyer> I am OK with making a list of values to skip substitution on and going from there
19:33:26 <stevemar> dtroyer: yah
19:33:45 <dtroyer> ok, lets keep going…
19:33:48 <dtroyer> now for the fun one: 	https://bugs.launchpad.net/python-openstackclient/+bug/1652317
19:33:48 <openstack> Launchpad bug 1652317 in Manila "OpenStackSDK refactoring caused various OSC networking commands to fail" [Critical,New]
19:34:16 <dtroyer> We missed this because our functional tests were no-ops for a few months :(
19:34:39 <dtroyer> that's been fixed, and SDK 0.9.11 was blacklisted in parallel with us skipping the broken tests
19:35:10 <dtroyer> so we still have 7 tests to fix (sdk 0.9.12 is out and will either break or get blacklisted again when it hits u-c)
19:35:48 <dtroyer> I was thinking about pinging the folks that originally write those tests to follow up with them and fix them
19:35:55 <dtroyer> unless someone just wants to pick it up?
19:36:19 <stevemar> i've got a full plate :(
19:36:34 <huanxuan> I think I can do it
19:37:21 <stevemar> dtroyer: i'd say these are must-fix bugs
19:37:57 <dtroyer> yes, I'd like to have this done for stable release, we should be back on latest SDK for stable
19:38:34 <dtroyer> huanxuan: thanks, you don't need to to the full rewrite that I've started for this, just make them work
19:39:35 <huanxuan> ok, zhiyong, jiahui and I will try to fix them
19:40:05 <dtroyer> and finally, https://bugs.launchpad.net/python-openstackclient/+bug/1650026
19:40:05 <openstack> Launchpad bug 1650026 in python-openstackclient "Trying to get help for a command errors out with "__init__() got an unexpected keyword argument 'project_name'"" [High,Confirmed]
19:40:20 <stevemar> another must-fix :(
19:40:35 <dtroyer> I have not looked in to this one… is it still happening as reported?
19:41:58 <stevemar> i think so, i checked it last week or so
19:42:33 <sshank> dtroyer, I ran into issue that when I was testing my neutron dhcp patch.
19:43:12 <stevemar> it does only affect networking commands
19:44:02 <dtroyer> I have not come across it in the network func test work I've been doing
19:44:31 <dtroyer> fiwi, I'm using a devstack config from clouds.yaml, not env vars
19:44:51 <dtroyer> I wonder if env vars is the common thread?
19:45:05 <dtroyer> sshank: ^^^ ???
19:45:07 <sshank> dtroyer, I sourced from openrc. Maybe that's causing the issue.
19:45:22 <dtroyer> so was mriedem in the bug report
19:45:28 <dtroyer> I'll try that too
19:46:03 <stevemar> possible, i was using env. vars too
19:47:20 <dtroyer> let's follow up in the bug with that…
19:48:36 <mriedem> yeah i do: source devstack/openrc admin
19:48:43 <mriedem> then all hell breaks loose
19:48:44 <dtroyer> FWIW, I see it too using openrc
19:48:57 <mriedem> note that i get a warning about OS_TENANT_NAME or something when sourcing that way
19:49:01 <mriedem> might be ID
19:49:04 <mriedem> but guessing that's somehow related
19:49:11 <dtroyer> mriedem: is there a chance you can try using clouds.yaml to verify that it doesn't see the problem?
19:49:26 <mriedem> dtroyer: probably not today
19:49:28 <dtroyer> I think the OS_TENANT_NAME is just a hard-coded warning in openrc
19:49:51 <dtroyer> mriedem: no worries, we can follow up in the bug
19:49:52 <dtroyer> thanks
19:49:57 <stevemar> dtroyer: thats correct, its an openrc warning
19:50:35 <dtroyer> #topic OSC metapackage
19:50:49 <dtroyer> stevemar: enlighten us!
19:51:24 <stevemar> oh right
19:51:42 <stevemar> i've got the infra and governance patches done
19:51:48 <stevemar> just needs an initial commit -- https://review.openstack.org/#/c/414380/
19:51:52 <stevemar> but a passing one :)
19:52:03 <dtroyer> coolness
19:52:07 <stevemar> not sure how i bungled the doc build, but i managed to
19:52:29 <dtroyer> I'll throw some eyes on it later
19:52:42 <stevemar> locally, the docs are being generated one folder up from where they should be
19:52:50 <stevemar> i imagine it's a case of a missing ".."
19:52:56 <stevemar> or one too many
19:53:32 <stevemar> once that passes we could technically "release" it at any time
19:54:18 <dtroyer> how do you feel about doing a stable release of this?  we could wait until the last minute to get some more time with it?
19:54:40 <dtroyer> but promoting it (eventually) as the documented way to get OSC
19:55:05 <stevemar> probably best to get more time with it, i have no idea what the ramifications are of installing it
19:55:08 <dtroyer> for Ocata
19:55:16 <dtroyer> ok, I can live with that
19:55:17 <stevemar> you mean Pike?
19:55:29 <dtroyer> well, yes, now for Pike
19:55:37 <stevemar> we can modify the install docs and such for Pike
19:56:28 <dtroyer> ok, 4 minutes, one more thing...
19:56:35 <dtroyer> #topic functional tests
19:56:59 <dtroyer> I was just wondering if there was anything to add to the functional test rewrites I've started.
19:57:15 <dtroyer> I have seen a couple of reviews with devs starting to change to that format
19:57:19 <dtroyer> \o/
19:57:22 <stevemar> oh?
19:57:24 <huanxuan> yes
19:57:28 <stevemar> i thought it was just you? :P
19:57:50 <dtroyer> apparently I'm not as far off the trail as I thought?
19:58:11 <huanxuan> jiahui and zhiyong will doing that as well
19:58:18 <stevemar> the new changes are good to me
19:58:19 <dtroyer> anyway, anything to add to that?  I've noted wanting to add some alternate output format testing
19:58:38 <stevemar> add it to the backlog
19:58:53 <dtroyer> and I just pushed up a rewrite for (compute) flavor to add a check for the bug Jens fixed this morning
19:59:13 <stevemar> are we good with using the etherpad for the meeting agenda?
19:59:25 <dtroyer> I do not plan to do all of these myself, but want to target the one we have or think we may have issues with
19:59:39 <dtroyer> I am…was the issue with the wiki the locking down of account creation?
19:59:55 <stevemar> yeah, and just annoying to update tbh
20:00:14 <stevemar> we've been using it in keystone for about a year
20:00:38 <stevemar> 8 months
20:00:39 <dtroyer> it is fine with me… I've started doing non-openstack stuff with folk in etherpads, it's becoming my more common doc environment!
20:00:42 <huanxuan> yes, it is good
20:00:56 <dtroyer> ok, with that we're out of time
20:01:00 <dtroyer> thanks everyone!
20:01:02 <huanxuan> yes
20:01:04 <dtroyer> #endmeeting