14:05:29 <ajo> #startmeeting neutron_qos
14:05:30 <openstack> Meeting started Wed Feb 10 14:05:29 2016 UTC and is due to finish in 60 minutes.  The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:05:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:05:33 <openstack> The meeting name has been set to 'neutron_qos'
14:05:52 <ajo> I was telling on the neutron channel, that I may need to cut the meeting short, because I have no backup today to pickup kids from kindergarten
14:06:11 <ajo> so for just in case:
14:06:14 <ajo> #addchair moshele
14:06:17 <ajo> #addchair moshele
14:06:21 <ajo> #addchair ihrachys_
14:06:22 <ajo> :)
14:06:52 <ajo> #link https://etherpad.openstack.org/p/qos-mitaka
14:06:57 <ajo> I'm following the etherpad as usual
14:07:28 <ajo> for RPC callback upgrades, please review if you didn't already: #link https://review.openstack.org/#/c/265347/
14:07:40 <ajo> I must update the follow up patch on this one
14:07:51 <ajo> and actually finish it, but it's just finally glueing the pieces together
14:08:07 <ihrachys_> it should happen real quick
14:08:10 <ajo> sorry to be so slow with this, we're alreay in m-3
14:08:11 <ajo> exactly
14:08:36 <ajo> so, I'm putting myself a deadline to have a perfectly working & CI valid patch for monday
14:08:46 <ihrachys_> noted
14:09:15 <ajo> #action ajo finishes the RPC callback upgrades integration (next monday)
14:09:33 <ajo> #topic RBAC
14:09:42 <ajo> I don't see hdaniel here,
14:09:55 <ihrachys_> I guess we wait on hdaniel to update the pathc
14:10:01 <ajo> I wanted to ask him for an update, we finally saw the neutron client patches
14:10:03 <slaweq_work> hello
14:10:04 <ihrachys_> also would be cool to see kevinbenton on it
14:10:10 <ajo> ihrachys_++ good catch about that
14:10:13 <ajo> yeah
14:10:18 <ajo> I've seen kevin in some of the patches
14:10:25 <ajo> one of them, I mean
14:10:26 <ihrachys_> yeah, but not the db one
14:10:35 <ihrachys_> not the qos one, I mean
14:10:40 <ihrachys_> some general common db mixin only
14:10:49 <njohnston> sorry I'm late
14:10:55 <ajo> hi njohnston , np :)
14:11:07 <ajo> ok, I will ping hdaniel for updates
14:11:17 <ajo> and I will ask him if he needs some kind of help
14:11:38 <ihrachys_> right, let's help each other
14:12:00 <ajo> then we need the time for that, but, let's see where's needed
14:12:07 <ajo> ok, about Linux bridge integration
14:12:13 <ajo> slaweq_work, ?
14:12:20 <ajo> #topic LinuxBridge integration
14:12:22 <ihrachys_> slaweq_work: still seeing gate failures?
14:12:25 <slaweq_work> ajo: I'm still fighting with fullstack tests
14:12:31 <slaweq_work> ihrachys_: yes
14:12:39 <slaweq_work> yesterday I fixed issue with L2pop
14:12:40 * ihrachys_ saw some discussions around it yesterday, hoped it's fixed now :(
14:12:54 <ajo> yikes ':/
14:13:11 <slaweq_work> but main issue is now that on jenkins all 3 linuxbridge connectivity tests are failing
14:13:25 <slaweq_work> and in logs I can see that there is problem with connection to rabbitmq
14:13:26 <ajo> slaweq_work, : but related to your patch, or in general?
14:13:32 <ihrachys_> slaweq_work: any ideas how to move forward with jenkins-only failures?
14:13:44 <slaweq_work> I have no idea how to debug it
14:13:48 <slaweq_work> and what is wrong there
14:13:57 <slaweq_work> on my dev host all 3 tests are passing
14:14:05 <slaweq_work> and connection to rabbitmq is fine
14:14:28 <ajo> I would say, if we cannot get help for fullstack, may be we shall skip that, and do manual tests for now, then keep working on the fullstack test
14:14:40 <ajo> it's not the first time things have been tested manually,
14:14:41 <slaweq_work> I also have to check some functional tests which are failin and it is because of my changes in net_helpers.py
14:14:45 <ihrachys_> ajo: yes, we'll consider reverting the order.
14:14:58 <ajo> as long as we end up having a fullstack test
14:15:22 <ajo> to avoid regressions
14:15:28 <slaweq_work> maybe You know someone who I could ask about help in debuggin tests on jenkins
14:15:50 <ajo> jschwarz is our expert about fullstack, but not sure how available he is this month
14:15:53 <slaweq_work> I suspect that it can be problem with iptables for example
14:16:07 <slaweq_work> ajo: ok, I will try to catch him on irc
14:16:11 <ihrachys_> slaweq_work: in theory, infra should have a way to leave a failing node for debug, but it would require some talks around it
14:16:13 <ajo> and, may be amuller, but he was travelling ,
14:16:32 <ajo> ihrachys_, : yeah, I've been looking forward to see something like that
14:16:38 <ihrachys_> slaweq_work: in gate, you can check iptables rules in worlddump files
14:16:46 <ajo> like marking a run to stay up and attached to a floating IP for X minutes
14:17:05 <slaweq_work> ok, I will look for iptables config there
14:17:05 <slaweq_work> thx
14:17:25 <ihrachys_> slaweq_work: http://logs.openstack.org/38/248938/13/check/gate-neutron-dsvm-fullstack/93bde4e/logs/iptables.txt.gz
14:17:31 <ihrachys_> I think that's the rules we have in gate
14:17:54 <slaweq_work> ok, thx
14:18:04 <slaweq_work> so I think that it can be reason of problem
14:18:16 <ajo> ok
14:18:18 <slaweq_work> but is it possible to rules "in flight" in tests?
14:18:39 <ihrachys_> you mean change?
14:18:51 <ajo> Isn't that stored in the debug logs ?
14:18:55 <slaweq_work> yes, add some rules to allow connections to rabbit
14:18:55 <ihrachys_> not for global rules I think.
14:19:07 <ajo> ahh
14:19:10 <ihrachys_> ajo: the problem may be with global iptables not managed by neutron
14:19:13 <ajo> ok, global rules
14:19:16 <ajo> understood
14:19:18 <slaweq_work> ihrachys_: exactly
14:19:40 <ihrachys_> ok let's spin on the idea
14:19:58 <ihrachys_> ajo: next topic?
14:20:08 <ajo> yup
14:20:11 <ajo> #topic DSCP
14:20:17 <slaweq_work> ok, I will catch You if I will have other questions
14:20:18 <slaweq_work> thx
14:20:18 <ajo> vhoward, njohnston  ? :)
14:20:23 <ajo> thanks slaweq_work++
14:20:46 <ihrachys_> ajo: do you actively review the DSCP patch?
14:21:04 <ajo> ihrachys_, not lately, I must jump again into it
14:21:07 <njohnston> I think the DSCP patch itself is looking pretty good, but I know ihrachys_ was voicing some concern that the l2-agent-extensions-api prerequisite wouldn't be ready before M
14:21:13 <ajo> I did a review of the agent API, and I was starting another one
14:21:28 <ihrachys_> njohnston: we will get the piece in M, I am on reviewing this part right now.
14:21:47 <njohnston> ihrachys_: Excellent, that removes perhaps my biggest anxiety.
14:21:56 <ajo> do you mean,
14:21:56 <njohnston> davidsha: You have anything to add?
14:22:03 <ajo> we aim to merge a minimalistic API for now,
14:22:10 <ihrachys_> there are some concerns around testing and versioned objects, but nothing critical. davidsha does good job.
14:22:12 <ajo> and then a real first version for M?
14:22:25 <ihrachys_> ajo: no. the minimal API is the M deliverable.
14:22:31 <davidsha> No I think it's been covered, I'm just keeping dscp up to date with l2
14:22:32 <ihrachys_> nothing beyond that actively planned right now
14:22:49 <davidsha> Thanks :)
14:22:53 <ajo> sorry, I was mixing
14:22:54 <ajo> M/N
14:23:01 <ajo> I mean M for the minimal API
14:23:05 <ajo> and then N for a more broad API
14:23:13 <njohnston> You can see we have a gaggle of accompanying patches listed in the commit message for https://review.openstack.org/#/c/251738/23 all of which are dependent on it so the docs and client etc. can all merge as soon as the main feature merges.
14:24:04 <ihrachys_> ajo: in theory, yes. we'll see whether we have resources in N.
14:24:27 * njohnston would like to pitch in to that in N
14:24:27 <ajo> ihrachys_, ack
14:24:35 <ajo> njohnston++
14:24:55 <ajo> I think it's a good initiative to keep making the agents extensible
14:25:23 <ajo> it will make many other related projects much cleaner integrated to the L2 agents
14:25:44 <ajo> ok
14:25:56 <ajo> #topic Open discussion
14:26:21 <ajo> is there any high prio bug or thing that needs discussion ?
14:26:26 * ajo looks a the list of bugs
14:26:35 <ihrachys_> I will only note that client freeze is approaching, we need to get client pieces in asap, and that means dscp and rbac
14:26:49 <ajo> ihrachys_, Client freeze happens earlier than server?
14:26:55 <ihrachys_> yes, one week I think
14:26:59 <ihrachys_> as per amotoki
14:27:02 <njohnston> The DSCP client change shouldn't merge before the server change, though, right?
14:27:02 <ajo> was that always this way?
14:27:08 <ihrachys_> njohnston: right
14:27:12 <njohnston> ok
14:27:28 <ajo> I guess we could ask for an exception in that case
14:27:32 <ihrachys_> ajo: no idea, maybe new approach
14:27:42 <ihrachys_> ajo: yes, exceptions are always there. but better not.
14:28:13 <ajo> just make sure the client side is ready , I will work on reviewing all the QoS things more proactively, too many distractions lately from the good stuff
14:28:40 <ajo> It puzzles me a bit, since the workflow is the other way around server then client, ... why freezing client, then server ? :?
14:29:00 <njohnston> ihrachys_: Do you think you can lift your -2 from https://review.openstack.org/#/c/251738/23
14:29:08 <ihrachys_> ajo: to stabilize for release
14:29:17 <ihrachys_> ajo: the client is not just for neutron, it's also used by other projects
14:29:31 <ihrachys_> njohnston: done
14:29:38 <njohnston> ihrachys_: Thanks!
14:29:48 <ihrachys_> davidsha: I just posted comments for l2 agent extensions patch, please have a look.
14:30:21 <ihrachys_> ajo: I guess we could close the meeting and do some reviews/coding :)
14:30:27 <ajo> yeap
14:30:34 <ajo> next week there's no official meeting
14:30:53 <ajo> but given the incoming deadlines, if people wants to do it, and we have a free meeting room
14:30:54 <ajo> I'm all for it
14:30:59 <ajo> a short one is enough
14:31:05 <davidsha> ihrachys_: I'll start on them now.
14:31:15 <ajo> let's discuss that along the way, so... #endmeeting
14:31:18 <ajo> #endmeeting