14:08:10 <ajo> #startmeeting neutron_qos
14:08:11 <openstack> Meeting started Wed Jan 27 14:08:10 2016 UTC and is due to finish in 60 minutes.  The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:08:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:08:15 <openstack> The meeting name has been set to 'neutron_qos'
14:08:21 <ajo> Hi everyone :-)
14:08:31 <ihrachys> howdy
14:08:41 <irenab> hi
14:08:47 <ajo> #link https://etherpad.openstack.org/p/qos-mitaka The usual etherpad-agenda
14:09:31 <ajo> Last meeting was a bit lonely, due to strange things with ics, or human error and misleading from my side :)
14:10:26 <ajo> We had a couple of things merged since last meeting
14:10:43 <ajo> RBAC spec:  https://review.openstack.org/#/c/254224/ .. yey hdaniel !
14:10:52 <hdaniel> :))
14:10:54 <ajo> and Validation for ml2 extension driver to be enabled when qos service plugin is used with the plugin: https://review.openstack.org/#/c/253853/
14:11:10 <ajo> yes slawek, probably more QoS related stuff was merged,
14:11:59 <ihrachys> prolly. let's not celebrate for too long look at stuff NOT merged :)
14:12:10 <ihrachys> *and look
14:12:12 <ajo> :)
14:12:24 <ajo> yep
14:12:31 <ajo> #topic Tracking items
14:12:46 <ajo> If somebody dares to call me optimist, will be right. I'm still working in the RPC callback rolling upgrade core logic:  https://review.openstack.org/#/c/265347/
14:13:23 <ajo> I was working on another patch right now, and I will continue after meeting, it looks considerable well, thanks ihrachys for the reviews
14:13:46 <reedip_> ajo : Hello
14:13:59 <ajo> hi reedip_ welcome
14:14:05 <ihrachys> I think we should be almost there with it; as long as tests are ready.
14:14:23 <ihrachys> honestly, I was not checking those since it seemed to me we should shake API first.
14:14:38 <ajo> ihrachys, yes, I think my current testing is reasonable, but I'm the writer, probably I must do an extra pass and verify I'm not missing stuff
14:15:02 <ajo> ihrachys, ack, let's get into testing afterwards
14:15:38 <ajo> also, I mush push a second patch for integration with the agent, adding some db migrations, I have a version locally for that which I haven't updated lately, now it's out of sync with the core logic api
14:16:04 <ihrachys> I suggest we get the first piece in, then care about the 2nd one
14:16:28 <ajo> yes, this is why I'm not updating the 2nd part patches without the 1st part being ready, it's too much rework every time
14:16:35 <ihrachys> righ
14:16:37 <ihrachys> *right
14:16:37 <ajo> wasted work
14:16:53 <ajo> ok, so let's keep that rolling, and going forward,
14:17:26 <ajo> as a note, when this (https://review.openstack.org/#/c/268040/1) is ready, the DSCP patches will need to be rebased on top of it
14:17:34 <ajo> but now that breaks the world,
14:17:49 <ajo> and it's quite far from my local version
14:17:54 <ihrachys> ajo: it's already based on l2-agent-extensions patch, I bet we don't want to have too deps
14:18:06 <ihrachys> *two deps
14:18:42 <ajo> right
14:18:56 <ajo> ok, they probably don't need the dept
14:19:18 <ajo> or to rebase on top of mine, as long as it's not merged until rpc callbacks upgrade support is merged
14:19:20 <ihrachys> we'll manage the order manually
14:19:27 <ajo> agreed
14:19:41 <ihrachys> not that there are people pushing the patch apart from us :)
14:20:14 <ajo> ihrachys: can we use the Depends-On for that?
14:20:25 <ajo> ihrachys, will the gate check the dependency is merged before ?
14:20:54 <ihrachys> ajo: we can, in theory. but I would keep test failures separate
14:21:05 <ihrachys> ajo: if you depends-on, you get all failures from all patches
14:21:20 <ajo> aha
14:21:24 <ajo> ok
14:21:45 <ihrachys> and honestly, I would not be bothered by dscp piece right now until we get the deps in. the deps are the blockers that concern me a lot.
14:22:21 <ajo> ok, let's try to move the upgrades quicker,
14:22:34 <ajo> ok, next topic then
14:22:44 <ajo> #topic RBAC status
14:23:01 <ajo> hdaniel, could you update about RBAC integration status? :)
14:23:05 <hdaniel> sure
14:23:28 <hdaniel> the patch is rewritten - to be used in a more "magical" way
14:23:33 <slaweq> hello
14:23:54 <hdaniel> per ihrachys suggestion - I've added metaclass to inject the functionality
14:24:05 <hdaniel> will push first wip patch today.
14:24:12 <ihrachys> nice
14:24:25 <hdaniel> wait, till you see it ,
14:24:29 <hdaniel> :)
14:24:32 <ihrachys> lol
14:24:34 <ajo> lol
14:24:38 <ihrachys> ok let's see it first indeed :D
14:24:53 <hdaniel> the client's patch needs to be rebased too, but I didn't have the time yet
14:25:09 <ajo> I must admit, magical sounds good and worrying ;D
14:25:18 <ajo> for example, mixins could seem magical at first sight
14:25:33 <ajo> so, let's see it :D
14:25:46 <hdaniel> mixins are like mushrooms - they are magical, but there's a price to pay ..
14:25:54 <ajo> lol
14:26:08 <hdaniel> ok, so I'm pretty sure I'll push the WIP draft today
14:26:21 <ihrachys> sounds reassuring :)
14:26:24 <ajo> thanks hdaniel  :)
14:26:37 <ajo> ok, next topic
14:26:46 <ajo> #topic Linux bridge integration
14:26:57 <ajo> slaweq, the stage is yours
14:27:08 <slaweq> ok, so
14:27:21 <slaweq> my patch for qos in linuxbridge is (I hope) almost ready
14:27:29 <slaweq> most reviewers gave "+1" for this
14:27:32 <ihrachys> it was pretty clean the last time I checked, yes
14:27:41 <slaweq> I have to update some docs and release notes to it
14:27:51 <ihrachys> we need fullstack, that's the concern now I guess
14:27:53 <slaweq> but I'm still fighting with this fullstack tests support
14:28:05 <ihrachys> have you tried to add rootwrap filters as I suggested before?
14:28:16 <slaweq> that is not so easy for linuxbridge (I'm testing connectivity there)
14:28:23 <slaweq> ihrachys: not yet
14:28:37 <slaweq> I'm in business trip this week and I have not too much time to do this
14:28:51 <slaweq> but I hope to do it today or tomorow
14:29:04 <ihrachys> that's fine. note that I will be pretty much off the next week.
14:29:17 <slaweq> FYI: fullstack test for connectivity is passing for me with linuxbridge but when I run it as root
14:29:36 <slaweq> when I run it as normal user that linuxbrigde agent is not spawning properly
14:29:44 <slaweq> and test is failing
14:29:54 <ajo> slaweq, looks like the root wrap filters for fullstack then
14:29:59 <ihrachys> ...and we suspect it may be missing IpNetNs rootwrap filter for lb agent
14:30:08 <slaweq> so I have to solve this issue and do some (big) refactoring to address all coments from reviewers
14:30:29 <slaweq> ajo, ihrachys: yes, it looks like that :)
14:30:31 <ihrachys> slaweq: pay special attention to John's comments, he is our fullstack guru :)
14:30:47 <slaweq> but I have to check it and check where I should configure rootwrap rules for tests
14:31:03 <slaweq> I know where to add it for "normal" working scripts but not for tests
14:31:31 <ihrachys> right. I think you need to run deploy_rootwrap.sh as part of fullstack target
14:31:38 <ihrachys> as we do for functional target
14:32:01 <slaweq> ok, thx for tips ihrachys
14:32:04 <ihrachys> ok, I guess we have a plan here.
14:32:11 <ihrachys> let's move on
14:32:13 <slaweq> so generally it is all about linuxbridge
14:32:23 <ajo> thanks slaweq and ihrachys  :)
14:32:29 <ajo> #topic DSCP markings
14:32:42 <ajo> njohnston, vhoward , any update on the topic?
14:33:14 <ihrachys> I need to admit I haven't looked into the code lately. was spending time on reviews for ajo and David for l2-agent-extensions.
14:33:25 <ajo> yes, I was going to point that out
14:33:34 <ajo> #link https://review.openstack.org/#/c/267591/
14:33:43 <ihrachys> right, that one
14:33:57 <ajo> and
14:33:58 <ihrachys> I think we are mostly ok with API part, just need testing coverage
14:33:59 <ajo> #link https://review.openstack.org/265347
14:34:01 <ihrachys> "just"
14:34:05 <ajo> ok
14:34:17 <ajo> is David around?
14:34:24 <ihrachys> davidsha:
14:34:38 <ajo> davidsha, ping :)
14:35:21 <davidsha> Hi, sorry
14:35:50 <ajo> I'd loop yamamoto and ann to check the patch :)
14:35:56 <davidsha> Nate said he was working on tests for the l2-agent
14:36:22 <davidsha> I'm working my way through the comments.
14:37:16 <ihrachys> oh nice that you do stuff in parallel. :)
14:37:22 <davidsha> :)
14:37:46 <ihrachys> I try to get back to the patch every day, hopefully I down slow down it
14:37:55 <ihrachys> ajo: ok, I will add them.
14:38:08 <ajo> I have pinged yamamoto_, akamyshnikova on irc, but cannot find Ann's email
14:38:16 <ajo> ihrachys, : thanks
14:38:39 <ajo> ok,
14:38:46 <ajo> #topic Open discussion
14:38:58 <ajo> anybody want's to raise any other topic or important bug?
14:39:02 * ajo looks at the bug list
14:39:05 <reedip_> ajo : pimg
14:39:11 <reedip_> ping*
14:39:23 <ajo> hi reedip, go ahead :)
14:39:23 <ihrachys> I just want to say we need more reviews on our patches in general
14:39:24 <irenab> ajo: any update on scheduling part?
14:39:51 <ihrachys> oh scheduling... I saw today the spec was -1'd
14:40:00 <ihrachys> due to some parallel effort from inside nova
14:40:04 <ajo> ihrachys: yes, probably I should be spending my time more in QoS patches instead of other stuff
14:40:10 <vikram> ajo: can you plz help approving https://bugs.launchpad.net/neutron/+bug/1505631
14:40:11 <openstack> Launchpad bug 1505631 in neutron "QoS VLAN 802.1p Support" [Wishlist,New] - Assigned to Reedip (reedip-banerjee)
14:40:41 <ihrachys> vikram: it will be discussed on next drivers meeting
14:40:48 <ajo> ihrachys, : true, I need to look at the other approach, I looked at it once a month ago, and it didn't look like compatible with what we wanted to do, but may be it's able to model our problem and I just didn't get it
14:40:51 <ihrachys> on one of next meetings ;)
14:40:52 <vikram> ihrachys: thanks
14:41:02 <irenab> ajo: the neutron side RFE for reporitng actual bw was rejected
14:41:17 <ajo> vikram, , correct, it has the same RPC callback upgrade support dependency as DSCP does,
14:41:24 <ihrachys> ajo: yeah, we should clarify that with nova folks before they get too far in their implementation
14:41:25 <vikram> ajo: yup
14:41:48 <reedip_> wow , open discussion indeed :)
14:41:53 <ihrachys> irenab: I think it was sort of 'postponed'
14:41:57 <ajo> irenab, yes, as ihrachys said, we need to clarify who pushes that, and how
14:42:02 <ihrachys> just because we are not sure how scheduler will work
14:42:08 <reedip_> ajo: I just wanted to share about  https://bugs.launchpad.net/neutron/+bug/1505627
14:42:09 <openstack> Launchpad bug 1505627 in neutron "QoS Explicit Congestion Notification (ECN) Support" [Wishlist,New] - Assigned to Reedip (reedip-banerjee)
14:42:09 <ajo> if it's going to be the agents, we don't need centralised reporting to neutron-server
14:42:09 <irenab> ajo: ihrachys agreed
14:42:35 <ajo> if somebody has some time to analyze again the other nova spec
14:42:37 <ajo> it would be great
14:42:44 <ajo> I have not enough bandwidth currently :(
14:43:06 <ajo> #link https://review.openstack.org/#/c/253187/  resource-providers: generic resource pools
14:43:21 <ajo> may be every host can be a resource pool...
14:43:24 <ihrachys> irenab: are you up for the challenge? :)
14:43:45 <ajo> but then , we'd have to see how to integrate us updating the resource pool details... I almost don't remember
14:43:51 <irenab> ihrachys: I am afraid I am over my BW currently
14:43:52 <ajo> may be jaypipes is up and around ;)
14:44:25 <ihrachys> that's sad
14:44:38 <ihrachys> well, we'll get to it some time
14:44:48 <ihrachys> ajo: should we have some todo in etherpad?
14:45:06 <ajo> reedip_, vikram we may look at that when we have bandwidth: but please, move this https://beta.etherpad.org/p/Notepad to etherpad.openstack.org
14:45:14 <ajo> beta.etherpad.org can be eventually deleted
14:45:19 <ajo> it's just a demo
14:45:26 <reedip_> ajo : ok, in a minute
14:46:04 <ajo> ihrachys, isn't that the track items?
14:46:13 <ajo> ihrachys,  slow moving are the ones unnatended
14:46:24 <ihrachys> ajo: yeah, but it's like a general scheduler thing. we need some details like the link to the alternative spec
14:46:52 <ihrachys> oh sorry, I see it's ther
14:46:54 <ihrachys> *there
14:47:09 <reedip_> ajo, vikram, ihrachys:  https://etherpad.openstack.org/p/QoS_ECN
14:47:13 <ajo> ihrachys, np, making it more clear
14:47:52 <ihrachys> ok, that's fine now
14:48:18 <ajo> thanks reedip_, link it to the bug so it doesn't get lost
14:48:26 <reedip_> already done ajo
14:49:51 <ajo> ok
14:49:55 <ajo> anything else ?
14:50:11 <ajo> or shall we do the farewell dance ? :)
14:50:15 * ihrachys dances
14:50:22 <irenab> :-)
14:50:25 <ajo> lol :)
14:50:30 <reedip_> lol
14:50:43 <jaypipes> ajo: I'm in the Nova mid-cycle...
14:50:50 <jaypipes> ajo: how can I help you?
14:50:54 <ajo> hi, jaypipes :)
14:51:05 <ajo> ok, let's not end the meeting, we have 10 more minutes
14:51:15 <ajo> we were talking about your spec: https://review.openstack.org/#/c/253187/
14:51:32 <ajo> and we wonder if we could use your model to track available bandwidth in hosts
14:51:42 <ihrachys> track and decide on
14:51:57 <ajo> yes, and decide on, for instance scheduling purposes
14:52:13 <ajo> jaypipes,  ^
14:52:35 <jaypipes> ajo: yes, I am almost done with the next revision which has a description of the use case of routed networks in Neutron and using generic resource pools in Nova to give the cloud user ability to specify a port and have Nova able to understand that that port is in a particular subnet, which is attached to a particular segment and that segment is attached to a rack of compute nodes.
14:53:10 <jaypipes> ajo: oh... bandwidth...
14:53:19 <ajo> jaypipes, ok, that's related, and probably more detailed the our intent
14:53:24 <jaypipes> ajo: sorry, that wasn't the use case I talked abotu with Carl.
14:53:35 <ajo> jaypipes, correct, it's something differnt
14:53:45 <ajo> our intent was to track available bandwidth on hosts
14:53:54 <ajo> towards providing bandwidth guarantees to instance ports
14:53:59 <ihrachys> yeah, Carl cares about L3, but here we have QoS case.
14:54:01 <jaypipes> ajo: the problem with QoS and bandwidth is that unlike other resources, bandwidth is an entirely transient thing. it changes from minute to minute.
14:54:19 <ajo> jaypipes, not for guarantees
14:54:40 <ajo> jaypipes, for guarantees you need to know the total host bandwidth (ingress & egress) over each specific physical network
14:54:52 <jaypipes> ajo: it's not a quantifiable resource, though... it's a qualitative assertion about something.. more of a capability than a resource.
14:55:04 <ajo> and then, it's left to the underlaying technology, to make sure the bandwidth limits and guarantees are kept within limits
14:55:09 <ajo> the important constraint is
14:55:41 <ajo> on a physical network:  sum(port[i].guaranteed_bw) < total_bw on that physnet
14:55:48 <ajo> for an specific host
14:56:22 <ajo> the idea is that no instance would be scheduled to that host, if it's using a port with an specific bw requirement, that we won't be able to guarantee
14:56:31 <jaypipes> ajo: what is the difference between "guaranteed bw" and normal bw?
14:56:38 <ajo> because we'd be overcommitting the host
14:57:04 <ajo> jaypipes, : the idea of the guarantee is that
14:57:18 <ajo> you provide a minimum bandwidth for a port (instead of a maximum)
14:57:18 <jaypipes> ajo: no, sorry, lemme rephrase my question...
14:57:45 <ajo> so, in any case, if the port is trying to use that bandwidth, (or more) it's packets are sent first
14:57:53 <ajo> then the packets of ports with no guarantees are sent
14:58:13 <ajo> or the packets of ports with lower guarantees (or already sending over it's minimum bandwidth guarantee)
14:58:40 <jaypipes> ajo: if a port has 100 total bw capacity, and 10 instances are given 10 guaranteed bw units each, is there some other process (not an instance, or some privileged thing?) that can consume bandwidth on that port and essentially overcommit the port to more bandwidth than SUM(port[i].guaranteed_bw)?
14:58:44 <ajo> there are a few ways to do it, but basically it's based on queues and packet prioritisation
14:59:07 <ihrachys> the assumption here of course is that underlying infra is capable to handle any bandwidth from any compute node
14:59:13 <ajo> jaypipes, if the guaranteed ports and not using the traffic, the unguaranteed can use it
14:59:21 <ajo> ihrachys,  correct
14:59:35 <ajo> that's another level of complexity I don't feel capable of tackling yet
14:59:38 <ihrachys> jaypipes: well, it does not require ideal fit, it's best effort
14:59:47 <ajo> correct,
15:00:00 <jaypipes> ajo, ihrachys: so I think the current modeling of generic resource pools will be able to meet these needs.
15:00:19 <ajo> jaypipes, thanks for the feedback, I will re-read your spec as soon as I can
15:00:21 <ihrachys> cool with me :)
15:00:24 <jaypipes> ajo, ihrachys: or at least the latest (almost ready to be uploaded) patch's model will meet those needs ;)
15:00:25 <ajo> an try to fit our needs with your model
15:00:33 <ihrachys> we need to consider the case, that's all we are asking :)
15:00:39 <jaypipes> yup, of course.
15:00:45 <ajo> thanks a lot :)
15:00:50 <ajo> I'm ending the meeting
15:00:51 <ihrachys> thanks a lot for replying!
15:00:56 <ajo> #endmeeting