14:00:34 <ajo> #startmeeting neutron_qos
14:00:35 <openstack> Meeting started Wed Jun 24 14:00:34 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:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:39 <openstack> The meeting name has been set to 'neutron_qos'
14:00:42 <moshele> hi
14:00:45 <ajo> hi :)
14:00:45 <vhoward> o/
14:00:50 <vikram> hi
14:00:53 <mohankumar> Hi
14:00:56 <gcossu> hi all
14:01:07 <Ramanjaneya> hello everyone
14:01:10 <sc68cal> o/
14:01:12 <sfinucan> hey
14:01:36 <ajo> ok, let's give a couple of minutes for anyone missing to join... :)
14:01:39 <nmj3e> hi
14:01:44 <ihrachyshka> o/
14:01:56 <ajo> today it's irena's birthday so she won't be around, Irena, Happy Birthday when you read this! ;)
14:02:25 <vikram> Happy Birthday Irena
14:02:38 <gcossu> happy bday!
14:02:48 <vhoward> happy cake day!
14:02:56 <ajo> ok I guess we can start, I didn't put an agenda for today, I just wanted to revise the current status of work, and prepare for the QoS sprint next week :)
14:03:00 <Ramanjaneya> Happy Birthday !
14:03:28 <mohankumar> Happy Birthday Irena : )
14:03:40 <ajo> I've seen a lot of progress in DB models, and neutron client, thanks Ramanjaneya , vikram and huawei india folks! ;)
14:03:45 <ajo> any comments about this?
14:03:52 <ajo> #topic status update
14:04:05 <vikram> thanks ajo
14:04:11 <Ramanjaneya> thank you ajo
14:04:42 <vhoward> added the rfe for the dscp markings…https://bugs.launchpad.net/neutron/+bug/1468353 …if we doing status updates
14:04:43 <openstack> Launchpad bug 1468353 in neutron "QoS DSCP marking rule support" [Undecided,In progress] - Assigned to Victor Howard (victor-r-howard)
14:04:52 <vhoward> er yeah
14:04:52 <moshele> ajo: can you share the data model commit
14:05:00 <ajo> thanks vhoward :-)
14:05:02 <ajo> moshele, yes:
14:05:05 <vhoward> np
14:05:10 <ajo> https://review.openstack.org/195050
14:05:16 <ajo> #link https://review.openstack.org/195050  datamodel
14:05:26 <ajo> not sure if link accepts extra comments ;)
14:05:40 <ajo> in general:
14:05:43 <ajo> #link https://review.openstack.org/#/q/topic:neutron-qos,n,z
14:06:18 <ajo> #link https://bugs.launchpad.net/neutron/+bug/1468353
14:06:19 <openstack> Launchpad bug 1468353 in neutron "QoS DSCP marking rule support" [Undecided,In progress] - Assigned to Victor Howard (victor-r-howard)
14:07:11 <ajo> I did a split of the monolitic patch with the API extension, svc plugin and the AFTER_READ callbacks
14:07:29 <ajo> so we can split work now/during sprint
14:07:56 <vikram> How to join remotely
14:08:12 <ajo> and ihrachyshka  has been working on the design to let the plugins/ml2 declare the supported rules
14:08:37 <ajo> vikram, let's talk about it when we move topics, is that ok? :)
14:08:43 <vikram> ok
14:08:43 <ajo> I wanted to rise that specific discussion :)
14:09:01 <vikram> ;)
14:09:27 <ajo> moshele, is also WIP on the agent extension, and he's breaking up in smaller patches too: https://review.openstack.org/#/c/189723/
14:09:52 <ajo> moshele, any comment about it? :)
14:09:53 <moshele> yes it will be  3 commits: agent extension mgr , QosAgent , SR-IOV Agent driver
14:10:10 <ihrachyshka> ajo, I wanted to add something for that in qos plugin but it seems that I cannot do it without rebasing your patches, so postponed service plugin side
14:10:36 <ihrachyshka> moshele, cool, looking fwd to see it split, then I'll be of more help reviewing it
14:10:39 <ajo> ihrachyshka feel free to rebase/fiddle around the patches, or we can just sync in the sprint :)
14:10:59 <ajo> ihrachyshka & moshele , thank you to for working on this
14:11:02 <ajo> to->too
14:11:07 <ajo> ':D
14:11:07 <ihrachyshka> ajo, nah, I don't think rebasing helps too much. also, on relevant note, we need to rebase branch anyway. otherwise gate fails.
14:11:21 <ajo> ihrachyshka, correct, I have checked with infra how to do it:
14:11:50 <ajo> #link http://docs.openstack.org/infra/manual/drivers.html#feature-branches
14:12:10 <ajo> So I'd try it soon (tomorrow I guess)
14:12:30 <ajo> I've been investigating on the generic RPC part, and I've almost have a new patchset.
14:12:46 <ajo> I've been playing with messaging, fanout queues, and oslo versioned objects
14:13:13 <moshele> ajo: is there some POC code you can share?
14:13:15 <ihrachyshka> ajo, for that new RPC approach, I kindly suggest to raise it in wider community
14:13:17 <ajo> I believe we really can do it as I was proposing, and thanks for the good amount of comments / suggestions.
14:13:43 <ihrachyshka> ajo, it's too much of a change in paradigm to do it in qos tenet
14:13:48 <ajo> ihrachyshka, ack, I will raise it on the list for higher audience
14:14:00 <ajo> ihrachyshka, or move the devref to master
14:14:19 <ajo> ihrachyshka, does that sound ok? :)
14:14:19 <ihrachyshka> ajo, both to my taste ;)
14:14:25 <ajo> ack :)
14:14:40 <ihrachyshka> I want people from oslo and nova to chime in on upgrade scenarios
14:14:48 <ajo> I'm trying to loop in the people with experience in that stuff, but I guess ML will work better :)
14:15:26 <ajo> ihrachyshka, as for versioned objects, I don't want an oslo/multiproject to happen first, we could try the approach ourselves, and then export if that works for all
14:15:38 <ajo> may be oslo_versionedobjects_pubsub :P
14:15:44 <ihrachyshka> ajo, we'll need to look into o.vo in L anyway.
14:16:06 <ajo> ihrachyshka, yes, I'm looking into it already, and we can support a mixed environent
14:16:11 <ihrachyshka> ajo, yeah, that's why I want oslo guys there. it seems like a generic approach that may fit oslo_messaging or whatelse
14:16:19 <ajo> what you want published... you need to add a VO layer (with this specific approach)
14:16:33 <ajo> oslo_remotecallbacks :P
14:16:42 <ajo> I'm too bad for names
14:16:50 <ihrachyshka> oslo_remotee
14:16:51 <ihrachyshka> :)
14:17:12 <ajo> but again, in my own experience, when you try to do something from-oslo first, needs more time, than if you do it in-project first, and then export
14:17:36 <ajo> we cannot risk waiting another cycle to get QoS for those details, we could export, refine, and readopt later
14:17:45 <ajo> but their feedback would be very valuable
14:17:47 <ihrachyshka> ajo, I agree. we can start in neutron, but design wise, we need more eyes
14:17:54 <ihrachyshka> ajo, o.vo started like nova thingy
14:18:18 <ajo> ihrachyshka, if they had tried to discuss that U/S with all, they'd still be bike shedding
14:18:19 <ajo> :-)
14:18:45 <ihrachyshka> I don't feel like making final call on upgrade and rpc versioning
14:18:51 <ajo> but insted, they show it was a good approach by making it work
14:18:58 <ajo> ihrachyshka, wait for my next PS ;)
14:19:18 <ajo> I know, more -1's ... but I believe we're heading into a good direction
14:19:46 <ajo> let's keep the discussion on the review :)
14:20:06 <ajo> #link https://review.openstack.org/190635
14:20:07 <ajo> ok
14:20:20 <ajo> #topic mid cycle sprint
14:20:43 <ajo> I plan to send a ML message to raise awareness and decide how to do remote participation
14:20:58 <ajo> last meeting we were talking about doing video conference at the end of each day, and keeping an etherpad/log
14:21:09 <ajo> I've been advised that probably IRC meetings work best
14:21:22 <ajo> so we could held them in #openstack-neutron or a separate channel if that becomes too noisy
14:21:51 <ajo> vikram: what time of day (UTC) do you start/end working in your timezone?
14:21:55 <ajo> vhoward, and you?
14:22:02 <ajo> sc68cal ? :)
14:22:12 <vikram> We are 5:30 ahead of UTC
14:22:32 <sc68cal> I'm keeping US EST hours
14:22:56 <sc68cal> so UTC -4
14:23:02 <vhoward> i'm on EST as well
14:23:14 <ajo> :D we are all around the globe
14:23:21 <vikram> start=5:00hrs and end=19:00hrs
14:23:44 <ajo> one plan was to have an afternoon meeting every afternoon (14:00 UTC)
14:23:54 <ajo> Tue/Wed/Thu
14:23:57 <vikram> works good for me
14:24:18 <sc68cal> that sounds reasonable
14:24:20 <ajo> vikram, if that's not too late for you, and sc68cal /vhoward can live with it for a few days too, that'd be good, I guess
14:24:30 <vhoward> sounds good
14:24:33 <vikram> I am okay ajo
14:24:41 <ajo> we could use #openstack-neutron with fallback to #openstack-neutron-qos
14:24:52 <ajo> thanks vikram , sc68cal , vhoward  :)
14:25:37 <ajo> I will put the details in a message to the mailing list.
14:25:44 <ajo> and arrange an etherpad where we could keep a log of work
14:25:52 <vikram> +1
14:26:07 <ihrachyshka> ajo, thanks for driving all bureaucracy. it's tough.
14:26:22 <ajo> ihrachyshka: it's just the boring part :)
14:26:36 <vikram> but most importatnt:)
14:26:45 <vhoward> yes thank you
14:26:45 <ajo> said that, with coordination, please know I'm ok with anybody taking over any of my patches to handle comments, etc...
14:27:05 <ajo> we may sync via patch comments / irc when doing such things :)
14:27:08 <vikram> I think we can take up the extension patches
14:27:48 <ajo> vikram, there's interesting stuff to discover in there about how to configure the URIs of the resources as we want
14:27:56 <vhoward> we will have to coordinate on where you need help/the june3rd etherpad seems almost full
14:27:59 <ajo> the default helpers don't allow that, so I guess we need to construct controllers, etc manually
14:28:18 <vhoward> i like the idea of just fixing commented patchsets
14:28:44 <vikram> ajo: we can resolve open issues together :)
14:28:49 <ajo> may be we can use an etherpad as a locking mechanism to say when somebody is editing a patch.
14:28:57 <vhoward> +1
14:28:59 <vhoward> i like that
14:29:16 <ajo> like.. keeping a list of patches, and who's editing... when you submit your patchset, and finish editing, you can send it back...
14:29:17 <vikram> +1
14:29:19 <ajo> to "free"
14:29:27 <ajo> or if you have to stop working on it...
14:29:31 <ajo> the idea is not to block others
14:29:36 <nmj3e> nice
14:29:48 <ajo> this is very collaborative, so I guess it's ok for very obvious things, big changes in design would need discussion
14:30:10 <ajo> with the author/other people, we can use the daily meetings for that :)
14:30:27 <vikram> over IRC?
14:30:47 <ajo> vikram, irc meetings should be good for discussion...
14:31:06 <ajo> or the etherpad or review comments themselves...
14:31:10 <vikram> how abt daily meetings
14:31:24 <ajo> vikram, what do you mean?
14:31:41 <vikram> <ajo> with the author/other people, we can use the daily meetings for that :)
14:31:44 <vikram> i didn't get it fully
14:32:23 <ajo> vikram, I mean, that taking over others patch is ok when we're following a colletive plan, but for introducing big design changes we need to ask via review comments, or in the daily 14:00 UTC meeting
14:32:43 <vikram> ok got it .. bingo
14:32:57 <ajo> ':D sorry, I'm not very good at explaining myself sometimes
14:33:08 <ajo> ok, any questions about the sprint?
14:33:23 <vikram> i am slow to understand either :)
14:33:33 <ajo> nah :)
14:33:51 <vikram> When you will share the etherpad?
14:34:08 <ajo> I'll send a message to ML with you all on CC
14:34:12 <ajo> probably during tomorrow morning
14:34:21 <vikram> ok great
14:34:37 <ajo> #topic other stuff
14:34:46 <ajo> sc68cal: ping, we may need your help to setup the experimental job
14:34:57 <Ramanjaneya> \quit
14:35:30 <ajo> sc68cal, if you couldn't do it before the sprint, any pointers would be welcome.
14:36:13 <sc68cal> ajo: Are there patches landed in the qos branch yet?
14:36:31 <sc68cal> making an experimental job with no code to exercise is probably not wise
14:36:33 <ajo> sc68cal, nope, but we could use the experimental job to test those patches at least
14:37:03 <ajo> sc68cal, can't you trigger the test over an specific patch?
14:37:08 <ajo> may be I'm trying to go too fast? :)
14:37:38 <ihrachyshka> ajo, you mean, a job that hardcodes some HEAD that is not master?
14:37:38 <sc68cal> I'll chat with people at the midcycle and see if they have any suggestions
14:38:00 <ihrachyshka> s/master/feature branch HEAD
14:38:07 <ajo> ihrachyshka, we just need something that triggers the neutron full test with the service configured in /etc/neutron/neutron.conf
14:38:37 <ajo> sc68cal, I guess that's all we need, right ^ ?
14:38:59 <ajo> hmm, and same for api tests
14:39:09 <ihrachyshka> ajo, yeah, but service is not committed, so you need another HEDA
14:39:11 <ihrachyshka> *HEAD
14:39:26 <ajo> "head" isn't the specific patch you're testing?
14:39:55 <ajo> you go to  patch in the chain... and trigger the job... the job installs the service, and runs it..
14:40:03 <sc68cal> I'll look into what we can do to test the qos feature branch - I know there is a BRANCH_OVERRIDE that devstack-gate has
14:40:33 <ajo> thanks sc68cal
14:41:05 <ajo> so far we will be having unit tests, functional tests,
14:41:08 <sc68cal> it's more likely that we'll get something going after the qos sprint next week, when we have code in the branch
14:41:22 <ajo> but we will need some arrangement for api-tests, I guess
14:41:37 <ajo> ok
14:41:44 <vhoward> so quick question, how are you implementing bandwidth api mods, we'd like to model that for dscp…if its part of the main qos patch we can help add it, sorry if its a dumb question
14:41:52 <ajo> let's run those locally during the sprint then, and sc68cal , ask if you can, at least to provide some pointers if we need to do it
14:41:54 <vhoward> can take that outside meeting btw
14:42:10 <ajo> vhoward, no dumb question, wait
14:42:44 <ajo> #link http://specs.openstack.org/openstack/neutron-specs/specs/liberty/qos-api-extension.html
14:42:48 <ajo> look for "Create Rule Request"
14:42:50 <ajo> is that what you mean?
14:43:00 <ajo> or do you mean the actual code supporting that?
14:43:17 <ajo> the former doesn't exist yet in full...
14:43:21 <ajo> it works, but on a different URI
14:44:29 <vhoward> was just trying to see if i had to include the api portion within my spec, i'll read up more but looks like we just include our json then the client calls to implement?  have to dig a bit i think
14:44:29 * sc68cal has to hop in car to go to the midcycle
14:45:06 <ajo> vhoward, may be an exaple of API calls creating dscp rules would be good, not sure if that's needed for the new RFE anyway
14:45:10 <ajo> sc68cal, enjoy!! ;D
14:45:36 <ajo> vikram remainded me that we need to gather feedback on this for the future: https://etherpad.openstack.org/p/flow-classifier
14:45:47 <ajo> https://review.openstack.org/#/c/190463/
14:45:56 <ajo> please review if you have spare time
14:46:01 <vhoward> k, thanks ajo
14:46:18 <vikram> thanks ajo
14:46:34 <vikram> we have the discussion about this over SFC IRC
14:46:41 <ajo> :-)
14:46:44 <ajo> fun ahead! ;)
14:46:45 <vikram> if someone interested please join :)
14:47:09 <ajo> vikram, what's the time of that meeting and what's the expanded version of "SFC" ?
14:47:25 <ajo> I tried to join once, but I couldn't make it btw
14:47:45 <vikram> SFC: Service Function chaining
14:47:50 <ajo> true, that's it ;D
14:48:14 <vikram> http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting
14:48:41 <ajo> :)
14:48:49 <ajo> ok, any question or any topic that I missed?
14:48:56 <ajo> or shall we #endmeeting ?
14:49:56 <ajo> ok, thanks everybody for joining once again :)
14:50:02 <vikram> bye
14:50:02 <ajo> keep up the good work! ;)
14:50:08 <vikram> you too :)
14:50:29 <gcossu> bye
14:50:30 <ajo> #endmeeting