14:01:23 <ajo> #startmeeting neutron_qos
14:01:24 <openstack> Meeting started Wed Jun  3 14:01:23 2015 UTC and is due to finish in 60 minutes.  The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:28 <openstack> The meeting name has been set to 'neutron_qos'
14:01:50 <ajo> #topic Where are we
14:01:56 <irenab> hi
14:02:02 <ajo> hi :)
14:02:10 <ajo> #link https://etherpad.openstack.org/p/neutron-qos-jun-3-2015
14:02:28 <ajo> with the help of irenab , we have put an interactive agenda in etherpad
14:02:34 <ajo> with some design details
14:02:37 <ajo> and some points for today :)
14:03:04 <ajo> please name yourself in the top right icon of the etherpad before commenting :)
14:03:28 <sadasu> ajo: are you referring to this etherpad/ https://etherpad.openstack.org/p/neutron-qos-api-preview
14:03:49 <ihrachyshka> sadasu, https://etherpad.openstack.org/p/neutron-qos-jun-3-2015
14:04:08 <ajo> thanks ihrachyshka
14:04:10 <sadasu> ihrachyshka: thanks!
14:04:17 <ajo> ok
14:04:34 <ajo> so, we got the API / service plugin spec approved
14:04:40 <ajo> https://review.openstack.org/#/c/88599
14:04:53 <ajo> and we have a follow up addressing some final comments: https://review.openstack.org/#/c/187513/
14:05:04 <vikram> great
14:05:09 <vhoward> ajo, anthony and i will be working on finishing up initial drafts for specs tomorrow around dscp and will link them for everyones review
14:05:26 <ajo> we also have specs for ML2/OVS: https://review.openstack.org/#/c/182349/  and ML2/SR-IOV  https://review.openstack.org/#/c/187895/
14:05:36 <ajo> vhoward, great,
14:05:52 <vikram> do we need to raise RFE for new specs
14:05:54 <ajo> please note the new RFE mechanism in place
14:05:54 <ihrachyshka> beside specs, is there any code?
14:06:24 <ajo> RFEs are basically to prevent you from writing a spec for nogthing
14:06:27 <ajo> nothing
14:06:34 <ajo> but still, I believe the spec is valuable in our context
14:06:45 <ajo> in some cases (like this) you could not be required even to write a spec
14:07:04 <ajo> and just a simple devref explanation of what do you want to do
14:07:10 <ajo> ihrachyshka: no code yet, we will get to organize that by the end of this meeting
14:07:25 <ajo> ihrachyshka, or was it a question to vhoward ?
14:07:34 <ajo> I believe they have some code they can reuse
14:07:38 <ihrachyshka> ajo, no, your response is what I looked for
14:07:47 <ajo> ihrachyshka ack, thanks
14:07:57 <ajo> .
14:08:18 <ajo> yesterday on neutron's meeting, we raised the openstack/neutron vs openstack/neutron-qos question
14:08:27 <ajo> hi armax ;)
14:08:50 <ajo> mestery suggested a feature branch, and we need to analyze work that out during this week
14:08:54 <sc68cal> ihrachyshka: there is code for dscp marking
14:08:55 <ajo> #link http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-06-02-14.01.log.html#l-293
14:09:53 <sc68cal> one thing that may complicate the OVS work - the new reference implementation split - https://review.openstack.org/#/c/176501/
14:10:22 <irenab> sc68cal: I guess it will impact SR-IOV as well
14:10:24 <ajo> a feature branch, is basically a branch of /neutron where we do all the work related  to QoS, and when stable, that's finally merged to /neutron, or ... spun out (I'd definitely avoid feature branches if that's the final outcome and jump straight into separate repo)
14:10:43 <vikram> ajo
14:10:49 <ajo> because a later spin out may introduce all the CI overhead later in the cycle
14:10:56 <vikram> ajo: is it in stackforge
14:11:08 <ajo> vikram, starckforge first, then under neutron umbrella
14:11:17 <ajo> which means openstack/..... as far as I understood
14:11:23 <ajo> ihrachyshka, am I right?
14:11:46 <ajo> vikram, talking about out of tree plugin, right?
14:12:01 <vikram> ajo: yes
14:12:02 <ajo> sc68cal: yes
14:12:14 <ajo> sc68cal, that's true, OVS spin out may complicate things, but, we just need to track that
14:12:17 <ihrachyshka> ajo, I guess so
14:12:45 <ajo> ok, any question or concern about this?
14:12:47 * sc68cal gets out his butterfly net to chase all these pieces of neturon that are flying out of the main tree
14:12:58 <ajo> sc68cal lol
14:13:24 <ihrachyshka> sc68cal, puzzle with 1000+ pieces, yea
14:13:50 <vikram> ajo: so the patch i submitted for neureon-qos project will be approved?
14:13:54 <ajo> sc68cal, if finally we spin out ref implementation, I have proposed myself to help a bit with it, so we have better track ourselves
14:14:04 <ajo> vikram, no
14:14:34 <ajo> unless there is any change in the end...
14:14:38 <ajo> but no, so far..
14:14:47 <sc68cal> ajo: nice :)
14:15:14 <ajo> #topic QoS design points
14:15:36 <ajo> irenab, do you want to talk about this one? :) I can interleave...
14:15:46 <irenab> ajo: sure
14:15:55 <irenab> so Lets start from server side
14:16:22 <irenab> we will have QoS server plugin to manage  QoS policy/rules
14:16:53 <irenab> we have QoS policy to port/ent mapping API
14:16:59 <sadasu> ajo: just to summarize from the previous discussion: qos api changes in a seperate feature branch (maybe) and the changes to OVS/SR-IOV refernce ML2 plugins will be in their respective stackforge repos
14:17:18 <ajo> sadasu, correct, as they will be spun out...
14:17:38 <irenab> back  to design?
14:17:41 <ajo> yes :)
14:17:59 <sadasu> yes irenab!
14:18:03 <irenab> so for qos policy mapping lokks like there are 2 options
14:18:16 <irenab> 1. support in qos service plugin
14:18:25 <irenab> 2. ML2 extension
14:18:45 <irenab> with option 1, it looks like more consistent way
14:19:00 <irenab> with option 2, more easy way
14:19:19 <sadasu> irenab: what do you mean by more consistent way
14:19:20 <ajo> with 1 we pave the way for other plugins
14:19:34 <ajo> and it's more consistent with the API proposal
14:19:41 <irenab> all policy UUID resolution into real attribute should be handled by the qos plugin anyway
14:19:52 <ajo> that means,
14:20:05 <moshele> irenab: if we got  with 1 can the service rpc  with L2 agent  or we need to implement new agent?
14:20:06 <ajo> we may extend the port information just with the qos-profile-id but no more details
14:20:34 <ajo> then the plugin is responsible of talking with the qos service plugin api to fetch the policy and rule details
14:20:42 <irenab> ajo: right, and the question if we want to do it via Ml2 qos mapping extension driver OR qos plugin
14:21:37 <ajo> I'd go for 1
14:21:47 <ajo> and then every plugin can do what it needs to do...
14:22:11 <irenab> for me 1 lokks more consistent as well, but maybe we need to prototype the workflow to see how to achive it
14:22:19 <vikram> so we will have separate plugins for OVS/LB/SR-IOV?
14:22:19 <ajo> irenab: I agree
14:22:44 <ajo> vikram, no,
14:22:49 <ajo> all those are drivers within ML2
14:23:22 <irenab> we may need some differentiation in the QoS pplugin, since capabilities may differ
14:23:37 <ajo> yes,
14:23:45 <ajo> that's one of the points we need to resolve
14:23:59 <irenab> my keyboard in a bad mood today :-)
14:24:14 <ajo> plugin-wise it's very simple to add a mechanism for "plugins" (ML2, a, b c...) to register their available rules...
14:24:37 <ajo> and then when those rules are created, we can just deny the ones not supported...
14:24:41 <ajo> but
14:24:47 <ajo> with ML2, we have one plugin
14:24:55 <ajo> and many drivers, that can be running concurrently
14:25:14 <ajo> local, ovs, lb, sr-iov...
14:25:26 <ajo> not local, sorry
14:25:37 <ajo> if you see the table in the etherpad
14:25:40 <ihrachyshka> ajo, maybe ml2 could find common set to report as supported
14:25:42 <irenab> What I am stil questioning is how port-create will deal with port extension supported by service plugin
14:25:45 <ajo> not all of them have the same capabilities..
14:25:55 <ajo> ihrachyshka, yes, that makes sense, and resolves some part
14:26:14 <ajo> but still
14:26:24 <ajo> we may have issues:
14:26:48 <ajo> 1) at port binding, if the port is bound to a sr-iov port (can we know that in advance?)
14:26:49 <irenab> once port-create is invoked with —qos-profile=UUID, port creation will be handled by ML2 plugin
14:27:27 <ajo> 2) at policy modification, for example, if your policy is applied to lots of ports (sr-iov, ovs..)
14:27:48 <ajo> but you introduce a rule which is not compatible with all ports
14:28:15 <irenab> ajo: I think your quesion is much more advanced then mine
14:28:35 <ajo> once ports are bound... may be during port update, ML2 could refuse to accept the new policy...
14:28:50 <ihrachyshka> ajo, you know which drivers are enabled, so the list of rules supported by all of them is predetermined. You can just check whether the new rule is among those.
14:29:05 <ajo> Iok,
14:29:09 <ajo> may be we're trying to dig too much in advance
14:29:10 <irenab> is it possible in current neutron code to support port extensions in different plugins and not in L2 plugin only?
14:29:24 <ajo> and it's something we could resolve during develpment
14:29:49 <ajo> irenab, what do you mean?
14:30:49 <irenab> if we support qos-mapping port extension in qos service plugin, I am not sure if current API framework will handle it gracefully.
14:31:15 <irenab> port is managed by L2 plugin (ML2)
14:31:17 <pcarver> In order to support SR-IOV we would need that support in hardware, right? There's no OvS/LinuxBridge way of applying QoS to an SR-IOV VM VF
14:31:34 <ajo> pcarver, correct
14:32:02 <ajo> irenab, I don't see the issue, but, I guess we can solve this by jumping into a code POC
14:32:06 <pcarver> So the ML2 plugin's vendor specific hardware driver is involved
14:32:10 <irenab> so for now any port extension if supported by this plugin, and then there are mixins to take care of validations and persistency
14:32:44 <ajo> irenab, plugins may need to signup for the "qos extension" yet
14:32:50 <ajo> even if we don't have a mixin
14:32:53 <ajo> and we do that via callback
14:33:04 <ajo> that=extension
14:33:11 <ihrachyshka> irenab, doesn't self.mechanism_manager.create_port_postcommit in ml2 pass all the needed info to driver?
14:33:35 <irenab> ajo: so from the ‘supported_extension’ perspective, qos-mapping will go into ML2?
14:34:15 <ajo> irenab, we need to provide a generic mechanism for plugins, and then in ML2 we could do it as we wanted
14:34:58 <ajo> may be I'm missing something, can we POC and resolve this into code to see how things fit?
14:35:18 <irenab> the point I wanted to raise, that it seems that currently all ‘net’, ‘port’ extensions are supposed to be declared as supported by L2 plugin. We just need to see how to make it work.
14:35:34 <irenab> with qos service plugin
14:35:50 <ajo> yes
14:35:53 <irenab> with other L2 plugins, it is the same
14:36:19 <ihrachyshka> irenab, but qos will be still supported by ml2, it's just that specific rules available may depend on drivers. (or I completely misunderstand the concern)
14:36:58 <ajo> we need to resolve the specific rules per driver... either we fail/warning on port bind when we discover where/to which driver the port is bound
14:37:27 <moshele> ajo: also on port update
14:37:34 <ajo> or... we fail on QoS rules update if there is a port not supporting such rule (we may need to find a reasonable way to do such thing without specific ML2 knowledge)
14:37:37 <ajo> moshele: correct
14:38:34 <ajo> if we had more port states, some kind of warning could be sent back to neutron server about the ports with unsupported rules
14:38:55 <irenab> ihrachyshka: it should work for ML2 with ref implementation, but be possible to leverage by other L2 plugins
14:38:56 <ajo> I remember somebody was looking into that already
14:39:14 <ajo> irenab: it should work for all plugins,
14:39:23 <ajo> ML2 included
14:39:32 <irenab> ajo: right
14:40:00 <ihrachyshka> irenab, sure. I don't see why it won't work.
14:40:01 <irenab> but looks like with ML2 there are additional concerns, due to mixed drivers capabilities
14:40:18 <ihrachyshka> yes, if we solve ml2, other plugins are even easier
14:40:25 <ajo> correct
14:40:45 <ajo> as we're resolving ML2 first, the mechanism should be there for all in the end
14:40:46 <irenab> so for the next design concern
14:41:04 <ajo> Agent side?
14:41:31 <irenab> there are two tipes of plugins/mech drivers: agent and agent-less
14:41:39 <irenab> ^types
14:41:58 <irenab> so we should take care of both
14:42:41 <ajo> examples of agent-less ML2 drivers?
14:42:50 <irenab> agent-based will require QoS “extension driver” to deal with qos settings and reporting
14:42:56 <moshele> ODL
14:43:04 <irenab> ajo: cisco sr-iov?
14:43:10 <ajo> thanks :)
14:43:10 <vikram> opencontrail
14:43:17 <irenab> ovn
14:44:02 <irenab> looks like there are more agent-less than agent-based :-)
14:44:07 <ajo> yep :)
14:44:28 <ajo> so, the idea of the extension driver, is that you can extend the agents in a modular way
14:44:35 <ajo> reusing all the RPC communication, etc.
14:44:45 <irenab> ajo: correct
14:45:04 <ajo> irenab: I added some notes to the etherpad, but may be is too long for this meeting
14:45:11 <ihrachyshka> for agent-less, we don't do anything specifically, right?
14:45:13 <ajo> I had an idea on how to have a generic RPC mechanism for all extension drivers
14:45:28 <irenab> I think both OVS and SR-IOV specs are mentioning some qos driver api that they will implement
14:45:44 <ajo> and even (later in time) make security groups an extension driver too
14:45:50 <vhoward> +1
14:45:54 <irenab> there will be a common layer above to make the information available
14:46:05 <irenab> ajo: can you share your idea?
14:46:17 <ajo> irenab: yes, line 61 of etherpad
14:46:18 <ajo> basically
14:46:54 <ajo> we could use query + subscription to fanout queues to retrieve and register for "SG RULES" "sg-id" info
14:47:04 <ajo> or "QOS PROFILE" "qos-profile-id" info
14:47:22 <ajo> then the extension mechanism would receive the messages, and route them to the right extension
14:47:24 <ajo> which subscribed
14:47:27 <ajo> also
14:47:51 <ajo> on the rpc side, the service plugins, or extensions, could register to this common rpc mechanism, saying
14:48:06 <ajo> "I  provide info for SG RULES", "I provide info for QOS profiles" , ....
14:48:29 <irenab> ajo: PUB/SUB
14:48:34 <ajo> so when somebody subscribes, it's notified, when somebody de-suscribes, it's notified... and it sends the information as changes hapen
14:48:35 <ajo> happen
14:48:36 <ajo> yes
14:49:09 <ajo> so, we would have common bits at ML2 level for the RPC messages
14:49:28 <ajo> but then, the service plugin would subscribe to that API saying: "I provide QOS PROFILE info"
14:50:08 <ajo> even, if we use oslo versioned objects at some point, those could be seralized over the messages...
14:50:15 <ajo> from rpc server to agents...
14:50:34 <ajo> does it sound too crazy? or even slightly reasonable? :)
14:50:41 <gsagie> sorry for being late
14:50:49 <gsagie> long meeting :(
14:50:57 <ajo> hi gsagie  :) np, we have minutes :D
14:51:23 <irenab> looks like nice infrastructure, need to reread though …
14:52:03 <vikram> it's basically a consumer / provider model ...right?
14:52:05 <ajo> I think it melds well with the idea of providing rpc responses from the service plugin, the extension manager, and having a common mechanism to communicate extensions info..
14:52:14 <pcarver> ajo: I like it. But I don't think I've fully absorbed it yet. Definitely seems like a good path.
14:52:27 <ajo> vikram , yes, with rpc in the middle and fanouts to optimize RPC traffic..
14:52:46 <ajo> pcarver, yes, I need to write a devref with more detail
14:52:51 <vikram> ok
14:53:04 <ajo> ok,
14:53:20 <ajo> let's talk about the last point, and lets mature the idea to see if it really makes sense
14:53:34 <ajo> #topic organizing work
14:53:47 <ajo> if you go to line 94: https://etherpad.openstack.org/p/neutron-qos-jun-3-2015
14:53:56 <sadasu> ajo: agree with the model the way you have explained it, but not sure if we are missing anything here..your devref would help
14:54:19 <ajo> sadasu, probably we're missing some detail, unexpected complexities everywhere :)
14:54:44 <ajo> #action ajo to put the common RPC mechanism to a devref
14:54:52 <sadasu> ajo: +1
14:55:06 <ajo> can you put your names next to the work points where you feel you could collaborate?
14:55:08 <ajo> in the etherpad
14:55:22 <ajo> probably the first step is the DB models
14:56:02 <ajo> I haven't draw a dependency tree...
14:56:13 <ajo> but time for liberty is tight
14:56:17 <vikram> that would be nice
14:56:28 <vikram> ;)
14:56:34 <ajo> by the end of august, liberty-3 is closed, and feature freeze comes ;)
14:56:36 <ajo> winter is coming...
14:56:38 <ajo> ;)
14:57:09 <irenab> ajo: will add later, my browser is stuck….
14:57:25 <irenab> need bulet for extension too
14:57:37 <irenab> its different from DB model
14:57:39 <ajo> ok, just signup or add any work piece I could have missed
14:57:59 <vikram> how about horizon?
14:58:09 <vikram> we need to do now?
14:58:16 <gsagie> i think thats a low priority
14:58:34 <ajo> horizon, right
14:58:37 <ajo> it's low, but it's important
14:58:38 <vikram> yes.. but need to deliver right?
14:58:41 <ajo> let's add the bullet
14:59:04 <ajo> correct, but some tracking with horizon when we manage to get the API in place will be good
14:59:37 <ajo> my browser is getting a bit crazy :D
14:59:46 <ajo> ok, we're at the top of the hour... :)
14:59:59 <vikram> ok
15:00:07 <ajo> if you want to talk a few minutes more about work distribution I'll be happy #openstack-neutron
15:00:12 <irenab> ajo: cli?
15:00:24 <ajo> irenab: that's the command line client point :)
15:00:34 <ajo> #endmeeting