14:00:08 <njohnston> #startmeeting neutron_qos
14:00:09 <njohnston> #chair ajo
14:00:09 <njohnston> #link https://etherpad.openstack.org/p/neutron_qos_meeting_chair for the meeting agenda
14:00:11 <openstack> Meeting started Wed Sep  7 14:00:08 2016 UTC and is due to finish in 60 minutes.  The chair is njohnston. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:16 <openstack> The meeting name has been set to 'neutron_qos'
14:00:17 <openstack> Current chairs: ajo njohnston
14:00:22 <ralonsoh> Hi
14:00:28 <davidsha> Hey
14:00:31 <njohnston> Hello everyone!
14:00:47 <njohnston> What would you call us, I wonder?  QoSians?  QoSites?
14:01:13 <ralonsoh> hehehe I don't know
14:01:23 <njohnston> ajo is here but has some other stuff going on, so he may be intermittent
14:01:36 <njohnston> #topic Barcelona
14:01:43 <njohnston> I only see one QoS talk, and it doesn't look like it is by anyone who I recognize
14:01:50 <njohnston> #link https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/15426/qos-qos-baby
14:01:59 <njohnston> Did anyone else get a QoS-related talk in to the summit?
14:02:09 <njohnston> I have one related to agent extensions with davidsha and mfranc213: https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/15187/under-the-trenchcoat-neutron-agent-extensions
14:02:29 <ralonsoh> I'll go to this one
14:02:38 <ralonsoh> We tried... whitout luck
14:03:03 <njohnston> That sucks
14:03:29 <njohnston> Well, let's hope for better luck in Boston!
14:03:37 <ralonsoh> yes!
14:03:50 <njohnston> #topic openstack client
14:03:59 <njohnston> Rather than spamming the list of openstack client changes, check the meeting agenda to get the list of 5 changes
14:04:26 <ralonsoh> status of this: almost finish
14:04:38 <njohnston> I don't think these are going to land in Newton now that N-3 has closed; it's pretty big for an FFE and I know there is still some churn
14:04:40 <ralonsoh> waiting for one update in infra config
14:05:07 <njohnston> what update?
14:05:21 <ralonsoh> to enable qos for functional tests
14:05:23 <ralonsoh> one sec...
14:05:33 <ralonsoh> https://review.openstack.org/#/c/366719/
14:05:43 <njohnston> thanks, I'll add that to the list to track
14:06:38 <njohnston> #topic RFEs
14:06:49 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1586056
14:06:49 <openstack> Launchpad bug 1586056 in neutron "[RFE] Improved validation mechanism for QoS rules with port types" [Wishlist,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:07:07 <njohnston> Two changes related to this
14:07:11 <njohnston> #link https://review.openstack.org/#/c/351858/ QoS notification driver changes
14:07:11 <njohnston> #link https://review.openstack.org/#/c/319694/ QoS validation improvements
14:08:05 <njohnston> Looks like slaweq is offline; I'll skip ahead
14:08:21 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1560963
14:08:21 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Hirofumi Ichihara (ichihara-hirofumi)
14:08:45 <ralonsoh> Front-end and SR-IOV merged
14:08:55 <ralonsoh> Linux Bridge in progress
14:09:11 <ralonsoh> I'll submit a new patch for LB this week
14:09:43 <njohnston> excellent!
14:10:06 <njohnston> #topic Bugs
14:10:14 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1614728
14:10:14 <openstack> Launchpad bug 1614728 in neutron "REF: qos: rule list in policy is too difficult to use" [Undecided,New]
14:10:37 <njohnston> I don't recall what we talked about this for last time, but IMHO it is opinion
14:10:46 <njohnston> ajo: Can you take a look at this when you have a chance?
14:11:19 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1603443
14:11:19 <openstack> Launchpad bug 1603443 in neutron "[QoS][DSCP] 'delete_dscp_marking' function raises exception, 'vif_port' not present" [Undecided,In progress] - Assigned to David Shaughnessy (david-shaughnessy)
14:11:32 <njohnston> #link https://review.openstack.org/#/c/345915/ Looking good, needs one more +2 review
14:11:55 <davidsha> Asked Ihar but he said he'd like ajo to have a look first.
14:12:17 <njohnston> #action ajo take a look at https://review.openstack.org/#/c/345915/
14:12:47 <njohnston> #link https://bugs.launchpad.net/python-neutronclient/+bug/1587291
14:12:47 <openstack> Launchpad bug 1587291 in python-neutronclient "Specifying '-F' or '--field' parameter in the qos related commands, returns abnormal result" [Low,In progress] - Assigned to Yan Songming (songmingyan)
14:12:52 <njohnston> There were three parts to this, only one remains, but it has issues
14:12:59 <njohnston> #link https://review.openstack.org/#/c/324545/
14:13:42 <ajo_> (sorry, I'm truly intermitent, network issues too)
14:14:08 <njohnston> and I just tagged this one qos
14:14:12 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1616547
14:14:12 <openstack> Launchpad bug 1616547 in neutron "qos: rule api definition shouldn't include tenant_id" [Undecided,In progress] - Assigned to Isaku Yamahata (yamahata)
14:14:28 <davidsha> ajo_: it's ok, we were just assigning you an excessive amount of work :P
14:14:44 <njohnston> there is a fix out, but it has a -1
14:14:46 <ajo_> lol
14:14:46 <njohnston> #link https://review.openstack.org/#/c/360009/
14:15:28 <njohnston> Any other bugs anyone is tracking that are QoS related?
14:15:57 <ajo_> Hmm
14:16:08 <ajo_> I'm not sure if the tenant_id there was for policy.json reasons
14:16:18 <ajo_> as soon as everything works, tenant_id should be ok there,
14:16:29 <ajo_> when we modeled that we thought that there was no need to replicate tenant_id to rules,
14:16:44 <njohnston> ajo_: Sounds like you are more informed on this than I am  :-)
14:17:14 <ajo_> I'll loop into the review
14:17:19 <njohnston> cool, thanks
14:17:35 <njohnston> #action ajo review https://review.openstack.org/#/c/360009/
14:17:46 <njohnston> #topic Other Changes
14:17:56 <njohnston> There is some OVO work that we can be aware of
14:18:03 <njohnston> #link https://review.openstack.org/356593 Qos Network Policy Binding OVO
14:18:10 <njohnston> #link https://review.openstack.org/356576 Qos Port Policy Binding to OVO
14:18:32 <njohnston> those are being actively worked on it seems
14:19:09 <njohnston> the only other one that looks like we should be aware of is
14:19:10 <njohnston> #link https://review.openstack.org/356472 Rename qos policy binding models class attr
14:20:02 <njohnston> Does anyone have anything else on their gerrit radar?
14:21:38 <njohnston> ok moving on
14:21:52 <njohnston> #topic Newton Postmortem
14:22:32 <njohnston> So I thought it would be good to set aside some time to talk about what worked well in the Newton timeframe, and what didn't work well.
14:22:44 <njohnston> Perhaps we can set ourselves up for success in the abbreviated Ocata cycle
14:23:02 <njohnston> davidsha ralonsoh ajo_: any thoughts?
14:23:23 <ajo_> can you update on what's the abbreviated Ocata cycle?, apparently, I'm completely outdated ':)
14:23:42 <davidsha> ajo_: Ocata is a 4 month cycle I believe
14:23:46 <njohnston> So the Ocata cycle is shorter than the others
14:23:58 <njohnston> in order to realign things for the summit and the pTG
14:23:58 <ajo_> why? for shifting dev & general conference?
14:24:11 <ajo_> ahaa
14:24:16 <ajo_> times of change :)
14:24:27 <davidsha> ajo_: the Idea is to have the summits half way through development so there can be course correction I think.
14:24:53 <ralonsoh> we need to plan in advance what to do next cycle, before the summit
14:24:55 <njohnston> "This schedule is based on the final Ocata release happening the same week as the PTG to kick off the Pike cycle, currently scheduled for late February 2017 about 16 weeks after the design summit in Barcelona."
14:25:01 <njohnston> https://review.openstack.org/#/c/357214/
14:25:31 <njohnston> Add to that the usual end-of-December PTO many people have
14:26:00 <ajo_> aha
14:26:09 <njohnston> So I think the only features that will make it are either ones that slipped from Newton and have a head start, or ones that are extremely disciplined.
14:26:32 <ajo_> ok, hmmm
14:26:42 <ajo_> but I see O release in end of February
14:26:46 <ajo_> isn't that 6 months ?
14:27:19 <davidsha> from the end of october?
14:27:21 <njohnston> 4.5 months from mid October
14:27:37 <ajo_> oh, sorry :)
14:28:12 <ajo_> ok, understood
14:28:17 <davidsha> to the topic on hand, I think the way ralonsoh was breaking up his feature was a very good idea. I think it's the best way to do things going forward.
14:28:40 <njohnston> +1 to that, the smaller, focused changes are easier to get review momentum
14:29:12 <davidsha> DSCP would have made it for mitaka if I'd broken the back end from the front end which was dependent on l2-agent-extension-api
14:29:15 <ajo_> I think that this cycle we got caught up by the complications of growing up the features on QoS (validation because of backend heterogeneity), and because of openstacksdk/client new restrictions
14:29:43 <ajo_> and you all did a very good job folks, I've been mostly looking this cycle
14:30:26 <ajo_> I agree, that breaking up stuff and prioritizing properly is the right thing to do
14:30:33 <njohnston> It seems like those 'growing up' features you mention are still in progress, but they really set the stage for the future
14:30:38 <ajo_> client + server changes, then the simplest backend, then the next, then the next.
14:31:06 <ajo_> and documentation
14:31:58 <davidsha> +1
14:32:09 <ralonsoh> +1
14:32:27 <njohnston> ajo_: Are there other 'growing up' features you think QoS needs to address other than the notification and validation changes?
14:32:56 <ajo_> no, I think that may help us keep a sustainable growth in the future.
14:33:04 <ajo_> via a more consistent API.
14:33:25 <ajo_> I can't foresee more, doesn't mean there won't be...
14:33:49 <njohnston> OK, so then those will need to be a high priority for Ocata
14:33:51 <ajo_> and, as you pointed up to me earlier today,
14:34:04 <ajo_> landing a feature, means landing it by the start of the cycle
14:34:06 <ajo_> to be safe
14:34:09 <ajo_> -1 / -2
14:34:21 <njohnston> yes
14:34:21 <ajo_> so that leaves headroom (-3) for the client, and final touch ups
14:34:28 <ajo_> and documentation
14:34:47 <ajo_> sometimes more complicated features may need to span across cycles.
14:35:14 <ajo_> and it's good if we can recognize that to avoid people getting frustrated. It's always amazing if we end before expected
14:35:25 <njohnston> :-)
14:35:29 <njohnston> +1 to that
14:35:41 <ajo_> for people I mostly mean developers, but I suppose consumers can also get frustrated waiting sometimes :)
14:36:28 <njohnston> YEs, I have gotten that, the "What do you mean <X feature I want> won't be in Newton?" from some consumer.
14:36:48 <ajo_> In next cycle(s) we have interesting challenges
14:37:16 <ajo_> probably finishing validation, ingress bw & min bw support, working out a bit more the documentation (thanks amotoki I've seen you're working on that too)
14:37:51 <ajo_> and, min bw strict support integration with nova resource pools, that's going to be funny, and... I suspect will span beyond ocata
14:38:10 <ajo_> well, TBH, I'm fairly confident, even more now with 4.5 months :)
14:38:48 <njohnston> Does anyone else have anything else to add?
14:38:54 <ajo_> but I guess we can be in position to consider any other small feature if it's important for anyone
14:39:09 <ajo_> or extending the support matrix of existing rules (DSCP for SR-IOV or linuxbridge?) :)
14:39:24 <njohnston> I don't eve know how you'd do DSCP for SR-IOV
14:39:46 <njohnston> If anyone can show me that black magic, I will buy them the frosty beverage of their choice in Barcelona :-)
14:39:59 <ajo_> may be I wrong I think I saw something in ip link
14:40:14 <ajo_> may be moshele or ralonsoh can get some info on that :)
14:40:22 <ralonsoh> ajo_: i'm on it
14:40:37 <ralonsoh> and davidsha
14:40:50 <njohnston> nice
14:40:58 <davidsha> looking it up atm
14:41:58 <njohnston> #topic Open Discussion
14:42:00 <davidsha> there is a type of service field I think.
14:42:15 <njohnston> Anything else anyone wants to talk about?
14:42:26 <njohnston> davidsha: That brings joy to my heart
14:43:19 <ajo_> also, I want to iterate on the L2 extensibility
14:43:24 <ajo_> with the flow pipeline
14:43:51 <ajo_> so I hope that davidsha and I can keep iterating on the framework and move the flow based extensions into it
14:43:54 <davidsha> ajo_: The current spec is pretty much the final version right?
14:44:03 <ajo_> yes,
14:44:18 <ajo_> we may need to change the target to ocata, and keep coding / reviewing
14:44:30 <ajo_> I want to help on coding if there's room :D
14:45:06 <davidsha> ack, I'll update the patch and start into unit tests. I think it might be ok, most of the functionality was covered in the WIP patch unless I'm mistaken.
14:45:07 <ajo_> njohnston: basically this all means that min bw & dscp will have their own openflow tables for ovs
14:45:18 <njohnston> excellent
14:45:26 <ajo_> and will have to declare themselves as functions for openflow
14:45:49 <ajo_> davidsha, let's e-meet may be this week or next to look at the code & spec together
14:46:14 <ajo_> to make sure we don't make you waste time too much on unit tests that may change later.
14:46:22 <davidsha> ajo_: sure!
14:46:27 <ajo_> I guess it's ok if you make them very high level first instead of very function specific
14:47:14 <ajo_> nothing more on my side :D
14:48:02 <njohnston> Anyone else?
14:48:10 <ralonsoh> no
14:48:38 <njohnston> OK, then I give you back 10 minutes.  Thanks all!
14:48:41 <njohnston> #endmeeting