14:00:17 <ajo> #startmeeting neutron_qos
14:00:18 <openstack> Meeting started Wed Jun 17 14:00:17 2015 UTC and is due to finish in 60 minutes.  The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:21 <openstack> The meeting name has been set to 'neutron_qos'
14:00:29 <moshele> hi
14:00:35 <ajo> hi ;) , let's leave a couple of minutes for people to join
14:00:37 <ajo> hi moshele  :)
14:00:40 <ajo> hi irenab  :)
14:00:43 <Ramanjaneya_> Hi ajo
14:00:49 <ajo> hi Ramanjaneya_  :)
14:01:01 <mohankumar> HI Ajo
14:02:11 <ajo> https://etherpad.openstack.org/p/neutron-qos-jun-17-2015
14:02:16 <ajo> #link https://etherpad.openstack.org/p/neutron-qos-jun-17-2015
14:02:36 <ajo> ok, we can probably start (ping sc68cal , ) :)
14:02:49 <irenab> hi
14:02:52 <ajo> We don't have an specific agenda for today, I just planned to track the ongoing work
14:03:01 <ajo> hi mohankumar
14:03:05 <ajo> #topic ongoing work status
14:03:15 <ihrachyshka> o/
14:03:23 <ajo> hi ihrachyshka  :)
14:04:04 <ajo> irenab was willing to take some tasks from the service plugin / api, and I have to split that work
14:04:31 <ajo> afterwards I will write some actual code for the generic rpc callbacks, to see how they fit
14:04:57 <ajo> #link https://review.openstack.org/190635
14:05:09 <ajo> Ramanjaneya_, any update on your side?
14:05:17 <vhoward> sorry for joining late everyone, i'll ping sc68cal
14:05:47 <vhoward> i have a spec that we are drafting and would def appreciate feedback on for dscp that is very similar to your bandwidth spec, let me find the link
14:05:56 <ajo> have you had time for looking into the DB models / etc? otherwise we need to look for help on that to not block the service plugin/api
14:06:04 <ajo> vhoward, nice!
14:06:28 <vhoward> https://review.openstack.org/#/c/190285/
14:06:36 <Ramanjaneya_> ajo, Qos neutron client changes completed..
14:06:37 <Ramanjaneya_> https://review.openstack.org/#/c/189655/
14:06:51 <ajo> vhoward, we're setting everything under the topic neutron-qos to find them all together: https://review.openstack.org/#/q/topic:neutron-qos,n,z could you update your topic? :)
14:06:55 <vhoward> i −1'd us until we are out of draft mode or get enough feedback to make it official
14:07:06 <ajo> vhoward thanks :)
14:07:28 <vhoward> also i still need to link as a dependency to the main qos api spec/blueprint
14:07:49 <ajo> ahh thanks Ramanjaneya_ , I see a new patchset, I will review
14:07:54 <vhoward> we hope to finalize monday but appreciate feedback until then
14:08:00 <vhoward> yes i can update my topic, thanks ajo
14:08:30 <ajo> #link https://review.openstack.org/#/c/190285/
14:08:37 <ajo> #link 	https://review.openstack.org/#/c/189655/
14:08:46 <ajo> #link https://review.openstack.org/#/q/topic:neutron-qos,n,z
14:09:15 <ajo> Ramanjaneya_, do you have time to look into the db models, or shall we look for help there? , not sure if you irenab could be available to speedup that part while I split
14:10:18 <ajo> also, if we use the generic rpc, we may put a versionedobject layer on top of the models
14:10:19 <Ramanjaneya_> Yes ajo..We will check DB model. vikram also might come this Friday
14:10:46 <ajo> Ramanjaneya_, ack, it's on the critical path, because it's needed by other parts, so we shall resolve that very fast
14:11:52 <ajo> Ramanjaneya_, looking at the client side, I'd look into how to make all the arguments that go after --type, dependent on the type we provide,
14:11:54 <ajo> if that's even possible
14:12:20 <ajo> for 1 type, it's ok
14:12:36 <ajo> but we don't want the help to show 200 arguments for all the available rule types
14:12:45 <ajo> being all optional then..
14:13:01 <ajo> but let's discuss that on the client code review
14:13:38 <ajo> we also need sc68cal to set the experimental job when he can, so we can run with the service plugin properly installed
14:14:20 <Ramanjaneya_> OK Ajo .. will take irenab help and  focus this on priority
14:14:27 <vhoward> k updated the topic ajo, thanks
14:14:41 <gsagie> hello
14:14:54 <ajo> hi gsagie  :)
14:15:19 <ajo> gsagie also offered help,
14:15:27 <ajo> gsagie, did you have time to look at moshele work?
14:15:36 <ajo> moshele, how's that progressing? I like how it looks
14:16:15 <moshele> ajo: I didn't progress match for the latest patchset I posted
14:16:23 <moshele> from
14:16:28 <ajo> vhoward, btw, since recently you need to submit an RFE and slimmed down spec (looking for the link from last neutron meeting)
14:16:30 <gsagie> not yet, i will only be available next week, but talked with moshele in the Israeli Openstack and offered to also help on that
14:16:42 <gsagie> the original plan was to start making the OVS agent implementation
14:17:23 <ajo> gsagie, ok, probably it makes sense to develop the library bits to handle QoS independenlty, and then we plug them in the agent logic design?
14:17:32 <gsagie> yep
14:17:35 <ajo> gsagie, (just thinking about isolating your work so you can make progress)
14:17:38 <gsagie> thats what i had in mind
14:17:43 <ajo> gsagie++
14:17:44 <ajo> :-)
14:17:59 <gsagie> i will have something ready for the sprint
14:18:11 <gsagie> so we can work on hooking things up
14:18:17 <ajo> vhoward, the new RFE process: https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst
14:18:19 <ajo> #link https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst
14:18:19 <vhoward> ajo: ah okay thanks for the info on RFE and slimmed down spec
14:18:26 <vhoward> we will get on that
14:19:02 <gsagie> ajo: you had a link with some of your experiments with OVS, could you resend it?
14:19:07 <ajo> vhoward, it's just cutting down the spec, and filling a bug,
14:19:30 <ajo> vhoward but feel free to proceed with the code when you see it's possible even if not approved, as we said, so it will be in shape to merge as soon as possible :)
14:19:31 <vhoward> works for me just wanna make sure we do it correctly
14:19:41 <ajo> vhoward, but I know general QoS work is blocking that :)
14:19:53 <ajo> vhoward, ack, I will read the current spec and comment
14:20:00 <ajo> gsagie, sure, 1 sec
14:20:16 <vhoward> hopefully we can help some with that also ;D
14:20:31 <ajo> gsagie: https://github.com/mangelajo/ovs-experiments/blob/master/qos/qos_traffic_shapping.sh
14:20:32 <ajo> #link https://github.com/mangelajo/ovs-experiments/blob/master/qos/qos_traffic_shapping.sh
14:20:35 <gsagie> thanks!
14:20:58 <moshele> ajo I think we need to close service plugin -> agent flow and ml2 plugin -> agent flow and see how it fit with the  Generic RPC mechanism
14:21:13 <ajo> gsagie, it's very simple, later we may want to upgrade it with enqueue openflow actions (when we tackle traffic/flow classifiers in the future)
14:21:40 <ajo> moshele, yes, we need to put all the pieces together ASAP
14:21:49 <ajo> if that's what you mean
14:21:59 <moshele> yes
14:22:06 <ajo> we need db to do the service plugin API
14:22:50 <moshele> also the validation part in ML2 and service plugin
14:23:11 <ajo> moshele, what do you mean by validation part? (validating rules/available rules?)
14:23:34 <ajo> ihrachyshka has been working on that
14:23:48 <moshele> yes it can come for ML2.  or service plugin when the port is bounded
14:23:55 <ajo> he has an initial design, but may need to be extended when we have dscp in place, for example
14:24:07 <ajo> as it only reports the common subset of rules supported by all ml2 drivers
14:24:30 <ihrachyshka> ajo, well, doesn't it depend on scheduler work?
14:24:49 <ajo> ihrachyshka, probably we can resolve that when we have a working prototype
14:24:57 <ajo> and look at the cases of different mechanism drivers,
14:24:58 <ihrachyshka> we should not assign a qos-enabled port to a node that is not capable to fulfill the needs
14:25:12 <ajo> I know that we will find a way to resolve it in a nice way
14:25:29 <ajo> ihrachyshka, sometimes a node could be exposing sr-iov ports, and normal OVS ones , right moshele?
14:25:43 <ajo> but if the port is going to be sr-iov ... no dscp rules,
14:25:52 <ajo> if the port is going to be ovs... dscp rules = yes
14:26:00 <moshele> right
14:26:04 <ajo> we may need to resolve the issue at plug time, for example, failing the plug
14:26:19 <ajo> then we also have updates...
14:26:21 <ajo> which are trickier
14:26:27 <ajo> the port could be already plugged...
14:26:28 <vhoward> correct
14:26:43 <ajo> and then what do we do? , do we stop the rule update because we can ask ml2 somehow ?
14:26:54 <ajo> or do we accept the rule, and then report the port as failed?
14:27:07 <ajo> when agent tries to configure it properly.. and it fails?
14:27:11 <ajo> the port could be working...
14:27:16 <ajo> but reported as failed...
14:27:19 <ajo> I guess that could work?
14:27:31 <ajo> that's where the port status thing comes...
14:28:23 <ajo> I believe we can find a reasonable way to solve it, and of course, improve it over time
14:28:49 <ajo> it doesn't have to be right now, I believe we can explore those cases when we're ready
14:28:52 <ajo> IMO, at least..
14:29:16 <ajo> probably I'm too dumb to think so far ahead :)
14:29:17 <ajo> :-)
14:30:14 <ajo> ok, ihrachyshka , moshele , vhoward , gsagie , Ramanjaneya_  mohankumar , irenab
14:30:26 <ajo> anything you think it's worth discussing now, or that I could be missing?
14:30:27 <ihrachyshka> ajo, a node is then should be represented as two separate entities with their own resources. anyway, moving forward.
14:30:51 <ajo> ihrachyshka, probably that'd be the different agents?
14:30:57 <ajo> ihrachyshka sriov agent, and ovs agent?
14:31:02 <ihrachyshka> yeah, that's my expectation
14:31:08 <ajo> makes sense
14:31:24 <ihrachyshka> OR agent will know how to plug the proper one, if it really serves multiple bridges
14:31:41 <ihrachyshka> sorry, bridges -> resource types
14:32:58 <ajo> ok
14:33:06 <ajo> the mid-cycle in israel is approaching
14:33:28 <ajo> for the remote participants across timezones, we could use an IRC channel, and possibly an etherpad
14:33:50 <ajo> we could try to use it as a log of what's happening, and who's doing what
14:33:56 <ajo> so we could coordinate,
14:34:02 <ajo> keep the stuff that needs review
14:34:24 <ajo> and prioritise such reviews
14:34:28 <vhoward> i like that idea, i think lots of folks are listing remote and cannot travel
14:34:46 <ajo> vhoward, yep, not sure if there are better ways to do it given the timezone differences
14:34:55 <ajo> may be we could setup a video meeting once a day
14:35:00 <ajo> in an overlapping time
14:35:24 <ajo> probably we'd kill anyone on the east coast by waking up to early each day ;D
14:35:29 <ajo> but it's only 3 days! ;D
14:35:34 <vhoward> +1 naw we will be fine
14:35:36 <vhoward> hehe
14:35:49 <ajo> thanks vhoward , we will try that,
14:36:08 <ajo> vhoward: try bluejeans for demo, that connects to the redhat conference rooms very easily
14:36:16 <gsagie> vhoward: you should make an effort to come.. after all it is the holy land
14:36:19 <ajo> let me link a demo site so you can setup the stuff on advance
14:38:02 <ajo> #link https://redhat.bluejeans.com/10305/3230/browser
14:38:06 <ajo> vhoward ^
14:38:24 <ajo> disclaimer, on OSX I only managed to make it work from Safari, chrome's plugin doesn't work
14:38:27 <vhoward> i'm scheduled to attend, but you all are scaring me now lol
14:38:30 <ajo> firefox could work, but didn't try
14:38:40 <vhoward> thank you i'll try it out
14:38:40 <ajo> vhoward: lol :)
14:40:20 <ajo> :-)
14:40:25 <vhoward> works!
14:40:29 <ajo> nice :)
14:41:03 <ajo> ok, if there's no other thing we could close the meeting
14:41:38 <ajo> Ramanjaneya_, let's try to prioritize DB models, let me know if you need any help from me, irenab, or if we need to ask for more volunteers
14:42:09 <ajo> feel free to ping me on IRC,
14:42:12 <Ramanjaneya_> sure..will look DB model as priority
14:42:30 <ajo> I will propritize splitting the service plugin & callbacks, and api patches, so irenab could take any of then and make separate progress
14:42:34 <Ramanjaneya_> will ping in IRC if any help further
14:44:22 <ajo> ok, thank you guys/gals
14:44:29 <ajo> #endmeeting