13:00:58 <dtroyer> #startmeeting openstackclient
13:00:58 <openstack> Meeting started Thu Jan 12 13:00:58 2017 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:01 <openstack> The meeting name has been set to 'openstackclient'
13:01:29 <dtroyer> Good Thursday OSC-ers, anyone here yet?
13:01:37 <RuiChen> o/
13:01:38 <huanxuan> o/
13:01:51 <dtroyer> courtesy ping: dhellmann, rtheis, stevemar, sheel,, thingee, ankur-gupta-f
13:02:06 <huanxuan> hi dtroyer and RuiChen
13:02:38 <RuiChen> hi huanxuan :)
13:03:20 <dtroyer> OK, let's get started.
13:03:37 <dtroyer> #link https://etherpad.openstack.org/p/osc-weekly-meeting
13:03:49 <dtroyer> that is the agenda, which I was just filling out a few minutes ago...
13:04:24 <dtroyer> basically, right now we are focused on a couple of things toward getting two more releases before the freeze in a couple of weeks
13:04:28 <dtroyer> #topic releases
13:05:21 <dtroyer> We want to make a release soon, this week yet if possible, that fixes all of the SDK issues so the blacklists for SDK 0.9.11 and 0.9.12 can be removed
13:05:39 <stevemar> o/
13:05:47 <dtroyer> There are currently a couple of new-ish issues getting in the way of that
13:06:05 <huanxuan> yes
13:06:11 <dtroyer> can stevemar or huanxuan summarize that for us?  (I've only skimmed the scrollback so far)
13:06:51 <RuiChen> yeah, some guys report bugs about 0.9.2 sdk in channel yesterday
13:07:20 <huanxuan> yes, jiahui was fix them
13:07:20 <stevemar> huanxuan: you can summarize the current gate issues :)
13:07:29 <dtroyer> ((RuiChen, you mean 0.9.12?))
13:07:44 <RuiChen> yes, sorry 0.9.12
13:08:25 <huanxuan> stevemar: the current gate issues is about the unit test...
13:09:50 <stevemar> huanxuan: i think there are 2 gate issues with unit tests?
13:10:00 <stevemar> huanxuan: one for test_image: https://review.openstack.org/#/c/419445/
13:10:18 <stevemar> and another about Network qos rule
13:10:18 <huanxuan> yes, and two for test_network_qos_rule
13:10:33 <stevemar> you can see one of them here: https://review.openstack.org/#/c/419067/
13:10:48 <huanxuan> I think ralonsoh_ is working on them now
13:10:55 <dtroyer> I can reproduce the qos rule one locally
13:11:16 <stevemar> weird how that got merged!
13:11:20 <ralonsoh_> huanxuan: I'm on it
13:11:37 <ralonsoh_> because it only fails when scp_mark=0
13:11:40 <ralonsoh_> dscp_mark
13:11:50 <huanxuan> yes, I guess it is
13:11:50 <ralonsoh_> and it's random
13:12:30 <huanxuan> http://logs.openstack.org/45/419445/1/check/gate-python-openstackclient-python27-ubuntu-xenial/db77b56/console.html#_2017-01-12_12_37_46_480826
13:12:53 <huanxuan> Note that I found two errors in qos rule
13:13:27 <huanxuan> the second one is also caused by scp_mark=0 right?
13:13:33 <ralonsoh_> both
13:13:55 <huanxuan> ok, thank you ralonsoh_
13:14:09 <stevemar> huanxuan: i think they are the qos rule create and set? both trying to set dscp_mark=0 ?
13:14:49 <dtroyer> do we have a fix proposed for that yet?
13:15:06 <stevemar> dtroyer: no, ralonsoh_ is on it
13:15:19 <dtroyer> ok, I'll keep a watch out for it
13:15:22 <huanxuan> yes
13:15:23 <stevemar> we could skip the tests if necessary?
13:15:33 <dtroyer> looks like huanxuan is on the image test already
13:15:45 <huanxuan> yes, but not sure it works
13:16:02 <huanxuan> I am trying to do that
13:16:24 <dtroyer> that's another one that is racy, it passed the original review a number of times
13:17:23 <dtroyer> I am concerned that we are refactroing a bit too aggressively and making tests that step on each other when run in parallel
13:18:11 <stevemar> have to step away for a bit, sorry
13:18:34 <dtroyer> https://review.openstack.org/#/c/419445/ has already failed py27 unit tests
13:19:00 <dtroyer> with the qos failure
13:19:12 * dtroyer sigs
13:19:17 <huanxuan> I saw it, it failed by the qos rule
13:19:20 <dtroyer> we may need to hit both in a single review?
13:19:44 <dtroyer> ralonsoh_: what is your estimate for fixing the qos unit tests?
13:19:55 <ralonsoh_> 15 mins
13:20:10 <ralonsoh_> i'm passing the test locally
13:20:16 <dtroyer> ok, cool.  let's run that and if we can merge it we'll swing back and get the image test
13:20:32 <huanxuan> ok
13:20:44 <stevemar> back
13:20:45 <dtroyer> if it doesn't get through the check due to the image test, lets go ahead and merge the two reviews
13:21:45 <dtroyer> we don't need to wait for all jobs to finish… does everyone know how to check the results as it runs?
13:22:19 <stevemar> you can see results here http://status.openstack.org/zuul/ as they run, just type in the project name or patch number :)
13:22:45 <dtroyer> yes, thanks stevemar
13:22:56 <huanxuan> thanks stevemar
13:23:12 <dtroyer> the unit tests are fairly quick so we'll see a failure soon-ish
13:23:20 <huanxuan> yes
13:23:27 <huanxuan> I see it
13:23:56 <huanxuan> thank you
13:24:04 <dtroyer> ok, after the unit tests are clear, we think the functional tests are too now, correct?
13:24:12 <huanxuan> yeah
13:24:36 <ralonsoh> sorry for the delay. QoS fix: https://review.openstack.org/#/c/419461/
13:24:53 <dtroyer> thank you ralonsoh
13:24:54 <stevemar> \o/
13:24:58 <huanxuan> nice! thank you ralonsoh
13:25:48 <RuiChen> thank you ralonsoh
13:25:58 <dtroyer> so https://review.openstack.org/419129 needs to merge first, then https://review.openstack.org/418650 should be clear.  at which point we can remove the requirements change and merge that and be done with the skips
13:26:22 <dtroyer> _that_ is when I am proposing we do the next release
13:26:34 <dtroyer> I'm looking at the release notes in parallel to all of this
13:27:12 <dtroyer> so there may be the traditional relnote cleanup to merge last and that'll be the release commit (if we need it)
13:27:29 <dtroyer> so far it looks good, we're doing much better at the release notes!
13:27:31 <stevemar> we've been fixing the rel notes before merging
13:27:37 <stevemar> ;)
13:28:23 <stevemar> oh one more bug should be fixed before releasing...
13:28:26 <stevemar> https://review.openstack.org/#/c/418221/
13:28:56 <RuiChen> I have a new idea about it
13:29:00 <dtroyer> that, however, is not a proper fix
13:29:16 <stevemar> RuiChen: whats the new idea?
13:29:19 <dtroyer> we have to hack around auth plugin stuffs already due to o-c-c
13:29:25 <stevemar> RuiChen: nice job investigating so far
13:29:31 <RuiChen> how about add a new global option --legacy-networking=true/false, user decide which one he want talk to neutron or nova-network, we only need to do small modification in is_network_endpoint_enabled()
13:29:40 <RuiChen> thank you, stevemar
13:30:45 <dtroyer> There is no OS_NETWORK_API_VERSION=1 now (Neutron started at v2), we could use that as the trigger
13:31:15 <dtroyer> changing the default now is huge though, and is likely to break things, so we would have to queue that for osc 4
13:31:15 <RuiChen> you mean OS_NETWORK_API_VERSION=1 is nova-network?
13:31:26 <RuiChen> for osc
13:31:37 <stevemar> dtroyer: do users normally set OS_NETWORK_API_VERSION=1 to use nova-net?
13:31:47 <dtroyer> in theory yes
13:31:57 <stevemar> ha, theory
13:32:04 <stevemar> we've never made them do it before :)
13:32:06 <dtroyer> although our code doesn't recognize v1, so making it do that to force using nova-net would not break anything
13:32:18 <dtroyer> stevemar:  no, that doesn't do anything now
13:32:33 <dtroyer> we rely soley on the sc, which needs auth, which…
13:34:06 <stevemar> can we catch the exception and retry with real credentials?
13:34:34 <stevemar> sc => service catalog (to get the authentication information)
13:34:58 <dtroyer> if we had real credentials it would work already, this fails when those are not present.
13:35:00 <dtroyer> correct?
13:35:01 <stevemar> oh right, this only happens if there is no auth information right?
13:35:31 <RuiChen> we support no auth to show help message now
13:35:31 <dtroyer> so modifying the is_network_endpoint_enabled() check in client manager to fall back to api version if no sc might work
13:35:47 <dtroyer> RuiChen: right, and we need to keep it that way as much as possible
13:37:20 <RuiChen> the current question is that we pass usename and others to Token class
13:37:57 <RuiChen> these merge the fake token and correct user options
13:38:37 <dtroyer> stevemar: can I submit a change to ksa that removes all of the extra arg checking?  that causes more problems than it helps I think…
13:38:59 <dtroyer> token can just ignore username, and phase_of_moon for that matter if it doesn't want to see them
13:39:30 <stevemar> bah, you'd have to bug jamie to see what he set it up that way, probably for backwards compat reasons
13:39:34 <dtroyer> will jamielennox die with frustration?  :)
13:40:11 <stevemar> arggg... this is a tough one
13:40:21 <dtroyer> it forces us to filter out everyhting a user may have lying around that the current auth type can't deal with.  that is a plugin function.
13:40:38 <dtroyer> maybe I split them into two layers and we get to bypass the comatibility-checking layer
13:41:10 <dtroyer> I think we only care about required-but-missing, not unwanted-but-present args
13:41:33 <stevemar> to clarify what i said earlier, this only happens if authentication info is present (since it conflicts), if there are none then we are all clear
13:41:38 <dtroyer> anyway, thats for another day, and we'd still have to fight through o-c-c to do it too
13:41:55 <stevemar> going back to my catch and retry idea
13:42:13 <dtroyer> ok, yeah
13:42:35 <stevemar> can we catch the TypeError and retry by removing the TOKEN and URL ?
13:42:37 <dtroyer> so catch and remove auth info altogether?
13:42:50 <dtroyer> that too
13:42:53 <dtroyer> lets try it
13:43:24 <RuiChen> ok, I will try it
13:44:12 <dtroyer> ralonsoh_: https://review.openstack.org/419461 cleared unit tests!
13:44:57 <huanxuan> nice
13:45:09 <ralonsoh_> dtroyer: perfect!
13:46:04 <dtroyer> ok, so I also wanted to ask about https://review.openstack.org/#/c/418183/ and if that needs to get into the first release
13:46:22 <dtroyer> more SDK bits
13:48:16 <stevemar> no idea :)
13:49:27 <dtroyer> I'll test it locally on sdk 0.9.12 and find out...
13:50:07 <RuiChen> thank you dtroyer
13:50:11 <dtroyer> so to summarize, we have a list for the first release that includes unit test fixes, functional test fixes, and at least one more bug fix.
13:50:12 <huanxuan> ok, sound good
13:50:35 <dtroyer> we may be close getting that out this week yet, so likely Monday for that release
13:50:54 <huanxuan> ok
13:51:11 <RuiChen> sounds good, \o/
13:51:25 <dtroyer> then we do another one that contains the remvol of the sdk blacklists (which have to get through in between)
13:51:35 <dtroyer> and that's stable/ocata
13:51:38 <dtroyer> phew!
13:52:04 <stevemar> much smoother than stable/newton ! :)
13:52:19 <stevemar> did i just bring back nightmares for you dtroyer? :)
13:52:22 <dtroyer> so anything else that anyone wants in the stable/ocata branch needs to be ready to go by wednesday next week
13:52:42 * dtroyer has an auto-block set for triggery-things
13:52:55 <huanxuan> actually I want to implement more cinder v2 command
13:53:09 <dtroyer> how close is that huanxuan?
13:53:20 <huanxuan> https://review.openstack.org/#/c/414197/
13:53:24 <stevemar> the encryption-* stuff is close!
13:53:35 <dtroyer> ok, yes, that should be doable
13:53:35 <huanxuan> yes
13:53:46 <stevemar> thingee: and i have been reviewing it as it goes
13:53:58 <huanxuan> https://bugs.launchpad.net/python-openstackclient/+bug/1655624
13:53:58 <openstack> Launchpad bug 1655624 in python-openstackclient "implement cinder "get-pools" and "get-capabilities" commands in OSC" [Undecided,New] - Assigned to aohuanxuan (huanxuan-ao)
13:54:02 <dtroyer> we can work that once we make the release proposal, we don't need to wait for the final merges
13:54:07 <huanxuan> I report a bug for the last two commands
13:55:02 <huanxuan> But not sure it make sense or not
13:55:13 * dtroyer looking
13:55:31 <dtroyer> I'll respond in the bug, not sure about 'volume backend' but it may be ok
13:55:46 <huanxuan> ok
13:55:49 <stevemar> huanxuan: regarding the manage/unmanage commands, what happened there?
13:55:56 <dtroyer> we have 5 minutes left
13:56:01 <stevemar> i think we did volume manage, but not anything else?
13:56:22 <stevemar> there is: volume manage, snapshot manage, volume unmanage, snapshot unmanage
13:56:29 <huanxuan> yes
13:56:46 <stevemar> i think smcginnis had issues with it, or someone did?
13:56:47 <huanxuan> I plan to let jiahui and zhiyong help me about those
13:57:11 <RuiChen> sorry, I have a question about OSC version and bug fix
13:57:21 <huanxuan> ok please
13:57:35 <RuiChen> for example, Mitaka OpenStack adopt OSC version [1.8.0, 2.3.0], if a bug in current master impact the stable version 2.3.0, what we should do?
13:57:53 <RuiChen> release 2.3.1 or latest version to ship the fix?
13:58:05 <RuiChen> Our downstream team face the bug https://bugs.launchpad.net/python-openstackclient/+bug/1560157
13:58:05 <openstack> Launchpad bug 1560157 in python-openstackclient ""openstack network list" fails with "An SSL error occurred."" [Medium,Fix released] - Assigned to Richard Theis (rtheis)
13:58:19 <RuiChen> they want an official osc release to fix the bug, but not the latest version, because some new commands maybe can't use in Mitaka OpenStack, and the bug block whole the networking commands in SSL config.
13:58:30 <dtroyer> we _really_ do not want to get stuck on requiring a mitaka OSC for mitaka clouds, but encourage everyone to use current OSC
13:59:10 <vgridnev> Hey folks, seems like you out of time, right?
13:59:22 <dtroyer> one minute yet on my clock
13:59:23 <dtroyer> :)
13:59:34 <vgridnev> Ok, sorry
13:59:35 <stevemar> RuiChen: we can talk in -sdks
13:59:37 <dtroyer> RuiChen: let's move that to -sdks
13:59:38 <dtroyer> yes
13:59:42 <RuiChen> ok
13:59:48 <huanxuan> ok
13:59:49 <dtroyer> thank you everyone!
13:59:50 <RuiChen> thank you everyone
13:59:56 <huanxuan> thank you !
13:59:58 <dtroyer> #endmeeting