17:00:49 <mestery> #startmeeting networking_policy
17:00:50 <openstack> Meeting started Thu Feb 13 17:00:49 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:54 <openstack> The meeting name has been set to 'networking_policy'
17:00:54 <s3wong> Hello, guys!
17:01:04 <mestery> OK first order of business: Meeting times :)
17:01:05 <SumitNaiksatam> hi all!
17:01:15 <mestery> banix, myself, marun, alagalah, and a few others forgot this time.
17:01:21 <mestery> So we met an hour earlier before we realized that.
17:01:29 <mestery> Second is that this slot won't work for marun going forward.
17:01:40 <mestery> So, long story short, will 1900 UTC Thursday work for everyone going forward?
17:01:50 <s3wong> mestery: really? You initiated the time change :-)
17:02:05 <SumitNaiksatam> mestery: to confirm, that is 11 AM PST?
17:02:05 <shivharis> hi
17:02:10 <mestery> I know I know. :)
17:02:16 <SumitNaiksatam> mestery: sorry, timezone challenged :-)
17:02:20 <mestery> My calendar invite for myself still said 1600 UTC :(
17:02:30 * mestery clearly didn't have enough coffee this mornig.
17:02:40 <banix> yes 11am pst
17:02:47 <mestery> So, 1900UTC Thursday going forward starting next weke, is that good for folks?
17:02:48 <banix> 2pm est
17:02:57 <SumitNaiksatam> banix: thanks
17:03:17 <mestery> #link http://www.scc-ares-races.org/generalinfo/utcchart.html Timezone conversion page
17:03:18 <SumitNaiksatam> banix: just wanted to make sure we have the same understanding :-P
17:03:33 <banix> This will change when we do daylight saving
17:04:14 <s3wong> mestery: banix: since you guys already had the meeting, we have nothing to talk about? :-)
17:04:16 <mestery> Yes, indeed.
17:04:18 <banix> SumitNaiksatam: I know :)
17:04:23 <mestery> s3wong: :P
17:04:34 <mestery> So we're good on the meeting time change?
17:04:41 <mestery> Going once ... going twice ...
17:04:45 <prasadv> yes
17:04:53 <banix> +1
17:04:58 <mestery> #action mestery to change this meeting to be at 1900UTC Thursdays on #openstack-meeting-alt going forward
17:05:00 <shivharis> oops this meeting is over? my bad.
17:05:07 <mestery> shivharis: Nope.
17:05:15 <mestery> We'll have it now today, but going forward starting next week we'll move it.
17:05:18 <shivharis> relief
17:05:24 <mestery> There was a conflict for some folks at this time due to the QA meeting.
17:05:26 <shivharis> k
17:05:34 <mestery> OK.
17:05:43 <mestery> #topic Shared repository for work
17:05:54 <mestery> The next topic is the shared repository
17:06:07 <mestery> SumitNaiksatam has setup a shared github, but there was talk of using stackforge instead.
17:06:32 <mestery> Unfourtanetly marun was the one who suggested this, and he can't be here right now (unless I just got his attention and he pops over for a minute).
17:06:34 <mandeep> Can we use stack forge for a neutron repo?
17:06:44 <mestery> mandeep: That was what marun was indicating, yes.
17:06:52 <marun> (hoping, anyway)
17:07:09 <SumitNaiksatam> mestery: my understanding was that stack forge is generally used for a new project or one which is being incubated
17:07:34 <mestery> SumitNaiksatam: Yes, that was my understanding as well, I think you're right.
17:07:47 <mandeep> I did look into that yesterday, but I did not see any repo on stack forge for a core project, and I am sure that they all have enough projects that would need colaboration
17:07:49 <SumitNaiksatam> mestery: in this case my anticipation was that this current activity of merging branches would be short-lived
17:08:03 <SumitNaiksatam> mandeep: yeah, i agree that would amount to a fork of neutron
17:08:27 <SumitNaiksatam> in general, my thinking was that we want to get to gerrit at the earliest
17:08:28 <mestery> So given this is likely to be 3-4 patches which we can link together, maybe stackforge is overkill?
17:08:42 <mandeep> Yes, I would think so.
17:08:50 <SumitNaiksatam> mestery: i think so, and not only that, i would prefer to do this on gerrit
17:09:07 <SumitNaiksatam> mestery: so we can have dependency of patches already in review
17:09:17 <SumitNaiksatam> mestery: we can mark them WIP to being with
17:09:25 <mestery> Makes sense.
17:09:29 <mandeep> Sumit: Yes that would be very convenient
17:09:35 <SumitNaiksatam> that would put all of this firmly on the roadmap
17:09:46 <mestery> Agreed. banix, thoughts on this? s3wong?
17:09:56 <SumitNaiksatam> and we can also run our own tempests test from our CI on it
17:10:00 <SumitNaiksatam> while we are developing it
17:10:02 <marun> so we're not far away from simply submitting patches directly to neutron?
17:10:16 <mestery> marun: For the APIs, yes, we are close I believe.
17:10:26 <SumitNaiksatam> marun: my thinking was we can get to that pretty soon
17:10:44 <shivharis> WIP on github +1
17:10:47 <banix> So the patches won't get in anytime soon. will they?
17:10:49 <marun> mestery: i guess I'm not sure why we'd need WIP on github then
17:10:53 <s3wong> mestery: so business as usual, no stack forge?
17:10:55 <hemanthravi> +1 github
17:11:03 <marun> we could pretty easily submit directly to neutron and mark as WIP
17:11:19 <marun> gerrit maintains persistent git branches, after all
17:11:38 <mestery> marun: OK, that makes sense then.
17:11:40 <SumitNaiksatam> marun: we wanted to merge work from a few people, so more of a convenience thing, rather than having to exchange diffs in emails
17:11:51 <mandeep> Yes, but we need a branch for collaboration, and the repo set up by Sumit would be the right place to do that
17:12:08 <mandeep> (just repeated what Sumit said ;-)
17:12:28 <marun> you can do the same thing with gerrit, though, and have all the tools available.
17:12:40 <marun> anyway, whatever works for you guys.
17:12:55 <s3wong> So what is the conclusion?
17:13:17 <mestery> Sounds like potential short-term github if needed, but moving very fast to WIP upstream patches.
17:13:20 <mandeep> Personally I prefer a github repo, so I would recommend to use the repo setup by sumit
17:13:21 <banix> So let me understand this. We use the github for now and move to gerrit
17:13:31 <mandeep> Yes
17:13:47 <mandeep> (that is my underdstanding)
17:14:06 <s3wong> OK
17:14:44 <banix> Sounds good; Let's do it this way.
17:15:13 <mestery> #action SumitNaiksatam to update meeting page with temporary shared github address
17:15:27 <mestery> #note Use shared github for short-term collaboration, moving quickly to upstream WIP patches.
17:15:40 <SumitNaiksatam> mestery: ok, will sync with you
17:15:50 <mestery> Thanks SumitNaiksatam!
17:16:02 <mestery> #topic PoC Code
17:16:25 <mestery> So, there is movement on the API front between SumitNaiksatam and s3wong.
17:16:41 <SumitNaiksatam> mestery s3wong: working on it
17:17:05 <s3wong> Yes, I will pull a personal branch, check it into that, and do a pull request to the main branch - that is the procedure now, right?
17:17:28 <SumitNaiksatam> s3wong: no pull request required
17:17:42 <SumitNaiksatam> s3wong: lets keep the master to mirror upstream
17:18:03 <SumitNaiksatam> s3wong: we can merge other branches
17:18:07 <mandeep> we can send a pull request to a colaboration branch
17:18:14 <s3wong> SumitNaiksatam: OK
17:18:22 <SumitNaiksatam> mandeep: yeah, thats what i meant
17:18:48 <banix> mandeep: can you write a couple of lines as to what to do and post it to the wiki so we are on the same page
17:18:50 <mandeep> And that allows us to use github comments to do any discussion
17:18:58 <mandeep> banix: will do
17:19:15 <banix> mandeep: thanks
17:19:19 <s3wong> banix: don't know if you looked at my diff so far - one thing to note. You and I had been back and forth on action as Neutron object; so far, since each action type has different structure, I put action as Neutron object for now
17:19:20 <mestery> #action mandeep to update wiki with collaboration instructions
17:20:14 <banix> s3wong: yes that's how I am doing it on the model side as well; will look more closely
17:20:34 <s3wong> banix: cool
17:21:04 <mestery> OK, anything else to talk about regarding PoC this week?
17:21:22 <s3wong> mestery: well - how are you doing on the agent side? :-)
17:21:51 <mestery> s3wong: Not good, lets put it that way. :)
17:22:03 <mestery> I will have more to update next week as well. :)
17:23:15 <mestery> #topic OpenDaylight Policy Proposal
17:23:37 <mestery> I know s3wong and banix and others are aware, but there is an equivalent proposal in OpenDaylight moving forward now.
17:23:46 <mestery> #link https://wiki.opendaylight.org/view/Project_Proposals:Application_Policy_Plugin OpenDaylight Policy Proposal
17:23:51 <s3wong> mestery: Oh, we are going to talk about the ODL project here too?
17:23:53 <mestery> Just wanted to note it here for people.
17:24:13 <mestery> s3wong: Given how the two tie together, and how the ODL ML2 MechanismDriver is getting close to merging, it makes sense a bit.
17:24:18 <mestery> Mostly just wanted to bring this up here.
17:24:21 <mestery> To keep people aware.
17:24:48 <mestery> We'll want to tie this into the ODL MechanismDriver as well once we get to that point and the APIs are implemented on the ODL side.
17:24:57 <s3wong> mestery: the ODL ML2 mechanisum driver will definitely make it to Icehouse, I suppose?
17:25:18 <mestery> s3wong: We just need third party testing, which the Linux Foundation assures me will be ready next week. Fingers crossed.
17:25:26 <mestery> The code has seen multiple reviews, so it's looking good.
17:25:36 <mestery> For reference:
17:25:43 <mestery> #link https://review.openstack.org/#/c/69775/ OpenDaylight ML2 review
17:25:59 <mestery> #topic Integration with Network Services
17:26:03 <mestery> banix this is your item correct?
17:26:06 <mestery> You added this one?
17:26:52 <banix> Yes, I see as we get the basic stuff worked out there are a couple of broad directions that we need to look at
17:27:04 <prasadv> also network aware scheduling.. What is it?
17:27:25 <banix> One being how our framework integrates with network services, advanced services, service chaining work
17:27:32 <mestery> prasadv: That was added by debo dutta, but he's not here, so I thought we'd punt that for today.
17:27:32 <s3wong> banix: if we feel ambitious, we should add 'redirect' action before the J-Summit
17:27:49 <mestery> s3wong: +1 to that
17:27:53 <banix> the other being integration with other types of policy work such as scheduling related work
17:28:19 <banix> s3wong: that should be our goal
17:28:21 <s3wong> banix: I noticed that as well - a Nova project, right?
17:28:43 <banix> and as we start looking at that we need to see how we can reuse service if posseble
17:28:51 <mestery> banix: makes sense
17:29:34 <songole> banix: service reuse - are you talking about multi-tenancy?
17:29:47 <banix> s3wong: correct; and some work on the Heat side
17:29:57 <s3wong> Also, after the basic PoC working, I would need to contact Sean to get the 'qos' action set defined
17:30:18 <mestery> s3wong: That makes sense as well!
17:31:08 <banix> songole: Not really; just as we try to implement redirect, we need to somehow specify/refer to a middle box like a LB or a FW. Right?
17:31:18 <s3wong> banix: nice - would be great to see us (network policy) working with Nova team to have Heat driving the whole infra, eventually
17:31:34 <songole> banix: got it
17:32:13 <banix> s3wong:  yes I think mystery will have more to say on that front
17:32:21 <banix> mastery that is
17:32:30 <banix> mestery!
17:32:39 <s3wong> it is indeed a mystery :-)
17:32:54 <songole> sumit: could you also setup a heat repo as well? thanks
17:33:03 <hemanthravi> we are starting on adding heat support for the apis from s3wong
17:33:29 <banix> hemanthravi: great. thx.
17:33:35 <s3wong> I agree, songole and hemanthravi need a collaboration repo for their code as well
17:34:33 <mestery> SumitNaiksatam: Can you add heat repositories?
17:34:41 <SumitNaiksatam> mestery: sure
17:34:56 <prasadv> should we start talking about redirect action since we have the first action into PoC
17:35:39 <songole> SumitNaiksatam: thanks
17:35:44 <mestery> prasadv: I think that's what s3wong was implying.
17:35:57 <SumitNaiksatam> songole: sorry, missed your earlier comment
17:35:59 <s3wong> prasadv: I don't mind, we still have 25 minutes
17:36:20 <mandeep> Is there a related blueprint in Heat as well?
17:37:01 <prasadv> we probably have to define the service Ids for redirect action and the management of the list
17:37:46 <s3wong> prasadv: currently the 'redirect' list isn't mandated to be ordered, so to implement a chain, we need that
17:38:26 <banix> So shall we consider a use case for redirect that we work through and see what we need to do to get there?
17:38:32 <prasadv> instead of having a list should it be UUID and the actual list is defined outside?
17:38:44 <songole> mandeep: there is no BP yet for heat updates.
17:39:34 <s3wong> prasadv: that's one way. If the service chain is itself a Neutron object, we simply set {'redirect': list: {'uuid'}}
17:40:28 <s3wong> but if you want tenants to define the chain via policy API, you can also set 'deny', then 'redirect' to a ordered list of UUIDs specifying the desired services
17:40:45 <prasadv> s3wong:redirect to list, does it mean it gets redirected to all the items in the list?
17:40:53 <SumitNaiksatam> s3wong: i would like to better understand the requirements from the neutron service chain
17:41:03 <s3wong> prasadv: yes
17:41:32 <SumitNaiksatam> i have been involved in incubating that feature for a while (along with mandeep and mestery) here
17:42:02 <SumitNaiksatam> we were initially planning to get it into I3, but that seems a stretch
17:42:07 <s3wong> SumitNaiksatam: yes, actually I would like your opinion on this as well - since you have been driving the Neutron service chaining project
17:42:08 <mestery> We should maybe sketch out a user case for the service redirect in the document to start with.
17:42:10 <banix> SumitNaiksatam: Could you tell us a bit about the status of that work
17:42:19 <SumitNaiksatam> i can carry over feedback from this discussion into that
17:42:22 <prasadv> s3wong: I assume the UUID in the list is a neutron object right?
17:42:32 <s3wong> prasadv: Yes
17:42:49 <SumitNaiksatam> s3wong banix: sure
17:42:55 <SumitNaiksatam> mestery: is this the right time to discuss this?
17:43:00 <banix> mestery: agree
17:43:04 <prasadv> mestery: I agree
17:43:16 <mestery> Maybe we should move this to a use case discussion in the document SumitNaiksatam?
17:43:19 <s3wong> SumitNaiksatam: if you can do it in 17 minutes :-) !!!
17:43:25 <SumitNaiksatam> mestery: sure
17:43:58 <SumitNaiksatam> s3wong banix mestery: why don't we go offline on this, and have this as an agenda item on the next meeting?
17:44:06 <banix> Let me start an email on the ML
17:44:08 <mestery> Makes sense.
17:44:10 <mestery> Perfect
17:44:13 <s3wong> SumitNaiksatam: Sure
17:44:14 <banix> yes agree
17:44:19 <mestery> #topic Open Discussion
17:44:23 <mestery> Anything else for this week?
17:44:40 <banix> mestery: you wanted to talk about scheduling policies?
17:45:13 <mestery> banix: No, that was someone else.
17:45:17 <mestery> We'll do that next week perhaps.
17:45:23 <banix> ok
17:45:45 <s3wong> mestery: make sure we invite him to the right time next time :-)
17:45:54 <banix> let's meet at 1900 UTC again
17:45:58 <banix> just kidding :)
17:45:59 <mestery> hahahahahahah
17:46:04 <mestery> OK, 1900 UTC next week!
17:46:07 <mestery> Thanks everyone!
17:46:11 <mestery> #endmeeting