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