18:02:00 <SumitNaiksatam> #startmeeting networking_policy 18:02:01 <openstack> Meeting started Thu May 7 18:02:00 2015 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:04 <openstack> The meeting name has been set to 'networking_policy' 18:02:18 <s3wong> hi 18:02:22 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#May_7th.2C_2015 18:02:44 <SumitNaiksatam> anyone have announcemnts to share with the team? 18:03:03 <hemanthravi> hi 18:03:08 <SumitNaiksatam> #topic Bugs 18:03:39 <SumitNaiksatam> ivar-lazzaro: is the backport for this done: #link https://bugs.launchpad.net/group-based-policy/+bug/1432779 ? 18:03:39 <openstack> Launchpad bug 1432779 in Group Based Policy "redirect actions don't work with external policies" [Critical,In progress] - Assigned to Ivar Lazzaro (mmaleckk) 18:04:20 <ivar-lazzaro> SumitNaiksatam: checking 18:04:29 <SumitNaiksatam> ivar-lazzaro: i think it is 18:04:36 <SumitNaiksatam> #link https://review.openstack.org/170972 18:04:42 <SumitNaiksatam> so we can close the bug 18:04:57 <ivar-lazzaro> SumitNaiksatam: yup 18:05:09 <SumitNaiksatam> i sent unicast emails to a few folks to check the status of the pending critcial and high priority bugs 18:05:20 <SumitNaiksatam> kindly take note and update the state on launchpad 18:05:29 <SumitNaiksatam> ivar-lazzaro: thanks for your quick reponse to the email 18:06:07 <SumitNaiksatam> apart from the afore mentioned, we dont have any critical (show stoppers) identified 18:06:18 <SumitNaiksatam> any other bugs/fixes we need to discuss today? 18:06:56 <SumitNaiksatam> Yi_: hi 18:07:13 <Yi_> SumitNaiksatam: Hi 18:07:14 <SumitNaiksatam> perhaps not, moving on 18:07:33 <SumitNaiksatam> #topic Functional/Integration tests in gate job 18:07:41 <SumitNaiksatam> not much of an update here 18:08:18 <SumitNaiksatam> one thing to note here is that the testsuite “gbpfunc” which is being run in the functional gate job is residing out of the tree 18:08:46 <SumitNaiksatam> so if you make a change that affects the current behavior of the API or how things are mapped to Neutron, the tests will break 18:08:47 <ivar-lazzaro> SumitNaiksatam: what's the workflow for gate breaking changes in this case? 18:08:52 <SumitNaiksatam> and will have to be fixed 18:09:03 <SumitNaiksatam> this happened in the case of ivar-lazzaro’s patch 18:09:14 <SumitNaiksatam> this is obviously not the desired way to go about things 18:09:19 <SumitNaiksatam> ivar-lazzaro: yeah 18:09:33 <SumitNaiksatam> ideally that test suite should be integrated in tree 18:09:57 <SumitNaiksatam> but for expediency reasons (and to avoid further regressions) we are linking it in the gate job 18:10:45 <SumitNaiksatam> in the case of ivar-lazzaro’s patch we contacted jishnu who wrote the test suite and requested him to update the tests in consultation with ivar-lazzaro who was introducing the changes to the behavior 18:11:43 <SumitNaiksatam> ivar-lazzaro: to answer your question, so until at least the summit, the workflow will be to contact me in case of such breaking changes, and i will coodinate to get a quick fix 18:12:02 <SumitNaiksatam> ivar-lazzaro: in your case you have access to jishnu, so you can directly reach him as well 18:12:26 <SumitNaiksatam> lets discuss this aspect of the gate job and the test suite in general during the design summit session 18:12:40 <rkukura> Hopefully we aren’t breaking existing APIs too often. 18:12:43 <SumitNaiksatam> please feel free to chime in here if you have thoughts 18:12:48 <SumitNaiksatam> rkukura: :-) 18:13:16 <SumitNaiksatam> but i could have gone like :-( too! 18:13:45 <SumitNaiksatam> ivar-lazzaro: sorry, i dont have immediately have a better solution to that 18:14:08 <ivar-lazzaro> rkukura: the tests also check the southbound APIs, that is that all the Neutron objects are created as expected 18:14:23 <SumitNaiksatam> ivar-lazzaro: good point 18:14:26 <ivar-lazzaro> rkukura: and it breaks when those expectation change :) 18:15:01 <rkukura> ivar-lazzaro, SumitNaiksatam: Even those sorts of changes will be really problematic during upgrades of existing deployments. 18:15:10 <SumitNaiksatam> rkukura: agreed 18:16:09 <SumitNaiksatam> rkukura: but there are things we learn over time (based on usage feedback) that we need to fix 18:16:21 <SumitNaiksatam> so most of what is being done now, is along those lines 18:17:10 <SumitNaiksatam> as adoption increases, we need to be increasingly more careful 18:17:20 <SumitNaiksatam> #topic Packaging Update 18:17:32 <SumitNaiksatam> i had an action item to follow up with rkukura on the k-3 release 18:17:33 <rkukura> I’m OK with breaking things for trunk-chasers on master, but we need some discipline on the stable/juno branch 18:17:42 <SumitNaiksatam> rkukura: agreed 18:18:14 <SumitNaiksatam> unfortunately there quite a few things in flux for k-3 so we did not tag k-3 18:18:37 <rkukura> What really needs to merge for k-3? 18:18:41 <SumitNaiksatam> i am hoping that we can wrap up on those changes a few days before the summit (say a week from now) 18:19:05 <SumitNaiksatam> rkukura: #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:master,n,z 18:20:30 <SumitNaiksatam> so there i guess there is no packaging update for today 18:20:32 <rkukura> According to https://launchpad.net/group-based-policy/+milestone/kilo-gbp-3, a lot needs to merge. 18:20:55 <rkukura> What about stable branch - will we have updates for those soon? 18:21:03 <SumitNaiksatam> rkukura: a lot of the bugs are already fixed for k-3 18:21:33 <SumitNaiksatam> rkukura: yes, stable branch backports was in fact an agenda items 18:21:36 <SumitNaiksatam> *item 18:21:41 <SumitNaiksatam> but since you brought it up 18:21:57 <SumitNaiksatam> there have been quite a few patches recently merged, and will need to be backported 18:22:24 <SumitNaiksatam> per our earlier plan to keep stable/juno relatively in sync with respect to features (per user requirements) 18:22:32 <rkukura> Are these really critical fixes for existing juno users? Can we start focusing on kilo-based deployments for new features? 18:22:54 <SumitNaiksatam> rkukura: there are critical requirements for users 18:23:46 <rkukura> But we really cannot package stable branch updates if doing a “yum update” is going to completely break an exisiting deployment. 18:23:59 <SumitNaiksatam> rkukura: this is predicated on the user feedback that they intend to use juno for the foreseeable future (since kilo packages are not going to be available for a while) 18:25:03 <SumitNaiksatam> rkukura: i believe in a earlier meeting we arrived at a consensus that it would be okay to do so 18:25:40 <SumitNaiksatam> if there are bigger concerns (or the approach is not feasible) we can revisit, but might need some offline discussion 18:25:51 <hemanthravi> SumitNaiksatam:+1, we are working with a customer who will be deploying juno and might need some of these fixes backported 18:26:35 <rkukura> SumitNaiksatam: None of this is a problem for new juno-based deployments. But what does someone do if they have a deployment and it breaks after an update? Do we just tell them to remove and reinstall? 18:27:26 <SumitNaiksatam> rkukura: agreed that is a problem, and I believe we assessed the risk of that happening and concluded that we are willing to take it (or at least that was what I took away from the discussion) 18:29:03 <rkukura> Is it a risk or a certainty? 18:29:13 <SumitNaiksatam> rkukura: in my understanding its a risk 18:30:01 <SumitNaiksatam> i have heard feedback that an existing user of GBP is in a situation where he would prefer to not reinstall 18:30:12 <SumitNaiksatam> sorry i meant, i have *not* 18:30:17 <rkukura> SumitNaiksatam: That sounds to me like we are trying to ensure that upgrades will work. I’m not so sure we really have been doing that. I know we’ve added some DB migrations, but do these actually fix existing DB records? 18:31:10 <SumitNaiksatam> rkukura: we have not attempted to migrate data 18:31:28 <rkukura> If we don’t migrate data, we break the deployment. 18:31:46 <SumitNaiksatam> but i believe this not always the practice in existing projects either 18:31:56 <SumitNaiksatam> at least in the early stage 18:32:05 <SumitNaiksatam> not saying that it not shoud be 18:32:10 <ivar-lazzaro> I thought we were in experimental mode until the server split happens 18:32:30 <ivar-lazzaro> (which will likely break things anyway... won't it?) 18:32:36 <SumitNaiksatam> at this point the effort to instrument the data migration, would far out weight its benefits 18:32:50 <rkukura> I think its reasonable to break master trunk-chasers, and for a new major release to require re-deployment. I don’t think breaking stable branch deployments is reasonable. 18:33:20 <SumitNaiksatam> i am not advocating that we should adopt this as a philosophy, and we should definitely have a process in place going forward 18:33:34 <ivar-lazzaro> rkukura: just to clarify, do you mean breaking Juno to Kilo is OK but Juno to Juno is not? 18:33:38 <rkukura> Maybe we can add a pre-install script in the package that refuses to install if the DB has data in it? 18:33:59 <rkukura> juno-to-juno 18:34:12 <SumitNaiksatam> rkukura: that is a very good happy medium 18:34:53 <SumitNaiksatam> rkukura: rather than refusing to install it can prompt user for confirmation before proceeding? 18:35:01 <rkukura> Not sure if that is possible 18:35:32 <SumitNaiksatam> rkukura: okay 18:35:52 <SumitNaiksatam> so lets have a follow up conversation on this, post this meeting 18:36:07 <SumitNaiksatam> rkukura: ivar-lazzaro thanks for the feedback on this 18:36:13 <SumitNaiksatam> hemanthravi: as well 18:36:20 <SumitNaiksatam> #topic Liberty/Vancouver Summit 18:36:36 <SumitNaiksatam> as aderstized earlier: #link https://etherpad.openstack.org/p/gbp-liberty-design-summit 18:36:46 <SumitNaiksatam> i have put some strawman proposals 18:37:00 <SumitNaiksatam> please feel free to post your suggestions 18:37:08 <SumitNaiksatam> we have a couple of weeks to firm up 18:37:29 <SumitNaiksatam> the design sessions are on tuesday (later in the day) and on wednesday (morning) 18:37:33 <rkukura> SumitNaiksatam: Looks good so far 18:37:53 <SumitNaiksatam> rkukura: okay great 18:38:07 <SumitNaiksatam> i was trying to find the link to the sessions, but not handy 18:38:41 <SumitNaiksatam> #link https://libertydesignsummit.sched.org/type/design+summit/group+based+policy#.VUuxK9pVikp 18:38:47 <SumitNaiksatam> found it ^^^ 18:38:48 <megm_> Hi, Matt! We missed you but ended up chatting for the full time. 18:39:19 <megm_> Someone new was there and I am drawing a total blank. 18:39:25 <s3wong> ? 18:39:48 <SumitNaiksatam> we dont have a Matt here, but megm_ you are welcome to join the team 18:39:53 <megm_> Apolgies -- wrong room 18:40:03 <ivar-lazzaro> :) 18:40:10 <SumitNaiksatam> Hands-on lab - 18:40:15 <SumitNaiksatam> ivar-lazzaro: and rkukura over to you 18:40:36 <SumitNaiksatam> ivar-lazzaro: thanks for sending the write up yesterday, sorry, i havent had a chance to respond 18:41:07 <ivar-lazzaro> SumitNaiksatam: thanks 18:41:47 <ivar-lazzaro> We are trying to come up with a script at the moment 18:42:13 <ivar-lazzaro> being this the first GBP hands on, we want to keep is simple, without showing too advanced workflows 18:42:30 <ivar-lazzaro> unless we have time of course 18:42:34 <SumitNaiksatam> ivar-lazzaro: +1 18:42:47 <ivar-lazzaro> The idea is to focus especially on Groups (you won't say!) 18:42:50 <ivar-lazzaro> and PRS 18:43:03 <ivar-lazzaro> (so also simple serve chain examples) 18:43:14 <ivar-lazzaro> leaving aside L3/L2 and external configurations 18:43:32 <ivar-lazzaro> This will also be a nice showcase for the implicit driver 18:43:38 <SumitNaiksatam> ivar-lazzaro: that sounds like a good plan 18:43:42 <Yi_> ivar-lazzaro: +1 on simplicity 18:44:00 <hemanthravi> should add a scenario with service chain 18:44:01 <ivar-lazzaro> that will take care of all those things so that the user doesn't worry 18:44:10 <SumitNaiksatam> hemanthravi: there will be one 18:44:11 <ivar-lazzaro> hemanthravi: there is one 18:44:33 <ivar-lazzaro> I'm trying to draft roughly 2 different scripts 18:44:42 <SumitNaiksatam> team here, please plan on making yourself available to organize this session 18:44:45 <Yi_> ivar-lazzaro: I assume it will be focusing on single-node? 18:44:52 <ivar-lazzaro> the difference will be on the fact that we merge the patches about sharing or not 18:45:08 <ivar-lazzaro> Yi_: one single node and one full chain 18:45:33 <SumitNaiksatam> lets have a final sync up session on wednesday (after the design summit) in person to firm up on how we are going to conduct the session 18:45:42 <SumitNaiksatam> ivar-lazzaro: rkukura thanks for the update 18:45:50 <ivar-lazzaro> SumitNaiksatam: just a sec 18:46:00 <ivar-lazzaro> SumitNaiksatam: there are a couple of patches we need to check 18:46:02 <SumitNaiksatam> i believe we will be sending out more targeted updates on this topic during the coming days 18:46:13 <ivar-lazzaro> SumitNaiksatam: in order to make this happen with sharing capabilities 18:46:26 <ivar-lazzaro> #link https://review.openstack.org/#/c/179327/ 18:46:38 <ivar-lazzaro> #link https://review.openstack.org/#/c/164907/ 18:47:02 <SumitNaiksatam> ivar-lazzaro: is the latter ready to be reviewed? 18:47:25 <ivar-lazzaro> I'll try to make the first one less painful if I can (with a pluggable sg_manager) 18:47:35 <rkukura> ivar-lazzaro: I’ve started reviewing the 1st of these. 18:47:36 <SumitNaiksatam> ivar-lazzaro: i believe we had decided that we would be targeting : #link https://review.openstack.org/#/c/164907/ after the other service chain refactoring patches were merged 18:47:51 <SumitNaiksatam> rkukura: great 18:48:00 <ivar-lazzaro> SumitNaiksatam: it's ready, I've refactored it so that it's easier to merge with the NCP 18:48:10 <SumitNaiksatam> ivar-lazzaro: okay 18:48:12 <rkukura> question - are these intented for kilo only, or for backport to juno? 18:48:17 <ivar-lazzaro> SumitNaiksatam: so feel free to go for it 18:48:22 <SumitNaiksatam> ivar-lazzaro: okay 18:48:35 <ivar-lazzaro> rkukura: sharing service chain constructs is 18:48:41 <SumitNaiksatam> rkukura: at least the latter is intended to be backported to juno as well 18:48:42 <ivar-lazzaro> rkukura: but that's backward compatible 18:48:43 <hemanthravi> need these for the backport too 18:49:08 <ivar-lazzaro> rkukura: as for the first one, we probably want it to stay in Kilo 18:49:12 <rkukura> ivar-lazzaro: If we add new primary key fields, the DB migration scripts need to populate these. 18:49:40 <ivar-lazzaro> rkukura: "shared" is the only column I add. And it's not a primary key 18:50:00 <ivar-lazzaro> rkukura: as long as its value is preset to False (which is coherent) we should be fine 18:50:10 <ivar-lazzaro> rkukura: this is true for the second patch of course! 18:50:26 <ivar-lazzaro> rkukura: the first one as a whole bunch of non backward-compatible changes 18:50:39 <rkukura> ivar-lazzaro: What about adding tenant_id as a primary key? 18:50:47 <ivar-lazzaro> rkukura: unless we have time to go with the pluggable approach... In which case everything will be fine 18:50:59 <ivar-lazzaro> rkukura: is that on the second patch? 18:51:05 <rkukura> no, the 1st 18:51:20 <ivar-lazzaro> rkukura: yeah the first is not backward compatible today, I agree 18:51:25 <ivar-lazzaro> rkukura: I was advocating the 2nd 18:51:39 <SumitNaiksatam> we have 9 mins, so lets take the discussion on the 1st patch offline 18:51:47 <ivar-lazzaro> rkukura: we should we fine if we have pluggable managers though, right? 18:52:04 <rkukura> ivar-lazzaro: probably 18:52:24 <SumitNaiksatam> ivar-lazzaro: pluggable managers will be very helpful and we should have had those from the beginning, so +1 18:52:39 <rkukura> Changing all existing SGs during an upgrade would be difficult. Lets move on. 18:52:43 <ivar-lazzaro> SumitNaiksatam: hopefully I have the time to do it :) 18:52:50 <SumitNaiksatam> ivar-lazzaro: :-) 18:53:03 <SumitNaiksatam> #topic Kilo features 18:53:18 <SumitNaiksatam> please note that sync with OpenStack kilo is complete 18:53:44 <SumitNaiksatam> please also note that the GBP heat resources are in their own namespace now 18:53:52 <SumitNaiksatam> #link https://review.openstack.org/#/c/155172 18:53:57 <SumitNaiksatam> was merged yesterday 18:54:30 <SumitNaiksatam> what it means is that if you have existing heat templates that reference the GBP heat resources with the earlier Neutron namespace, those will break 18:54:42 <SumitNaiksatam> this is applicable only for GBP kilo 18:54:49 <SumitNaiksatam> so please adjust accordingly 18:55:40 <SumitNaiksatam> Floating IP support (spec #link https://review.openstack.org/#/c/167174, impl: #link https://review.openstack.org/#/c/167174/) i believe is ready to move ahead 18:56:05 <SumitNaiksatam> we have gone through several iterations and i believe the outstanding comments have been addressed at leat for this iteration of support 18:56:20 <SumitNaiksatam> unless there are any objections, lets move forward on this 18:57:07 <SumitNaiksatam> Service chain driver refactor: 18:57:20 <SumitNaiksatam> spec was reviewed and merged: #link https://review.openstack.org/#/c/174118 18:57:31 <SumitNaiksatam> if there is further feedback, we can always update it 18:57:43 <SumitNaiksatam> but we had to draw a line somewhere to proceed with the implementation 18:57:59 <SumitNaiksatam> ivar-lazzaro has a host of impl patches: #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:master+topic:bp/node-centric-chain-plugin,n,z 18:58:35 <SumitNaiksatam> not enough time to go into the details right now, but we can go to #openstack-gbp for follow up discussion if needed 18:58:38 <igordcard_> okay, anything new that you may have discussed regarding the plumbing plugins? 18:58:43 <igordcard_> SumitNaiksatam: okay 18:59:02 <SumitNaiksatam> igordcard_: currently this will be very simple 18:59:23 <SumitNaiksatam> igordcard_: i dont anticipate that we will have the time to implement any of the sophisticated insertion cases 18:59:28 <ivar-lazzaro> igordcard_: I'm looking at your traffic streering patch to see how it could fit 18:59:34 <SumitNaiksatam> igordcard_: think of this as a place holder framework 18:59:39 <ivar-lazzaro> igordcard_: I may have questions for you in the upcoming days 18:59:43 <SumitNaiksatam> igordcard_: that you should be able to extend 18:59:56 <SumitNaiksatam> igordcard_: thanks for the reviews 19:00:04 <SumitNaiksatam> #topic Open Discussion 19:00:12 <SumitNaiksatam> we are almost out of time 19:00:28 <SumitNaiksatam> i was going to propse that we skip the IRC meeting for the next three weeks 19:00:45 <SumitNaiksatam> since next week we wil be busy with the summit preparations (or travelling) 19:00:51 <SumitNaiksatam> then we will be at the summit 19:01:00 <SumitNaiksatam> and then we would need a week to recover ;-) 19:01:09 <SumitNaiksatam> any objections? 19:01:29 <SumitNaiksatam> of course, if required we can change meet in #openstack-gbp 19:01:38 <rkukura> Fine with me, but don’t hestitate to re-instate next week if we need it to prepare for the summit. 19:01:38 <igordcard_> SumitNaiksatam: about the openstackclient, I didn't go too deep in it but yes, it calls existing functionality on the other clients 19:01:45 <SumitNaiksatam> rkukura: absolutely 19:01:54 <SumitNaiksatam> igordcard_: awesome good to know 19:02:11 <SumitNaiksatam> igordcard_: perhaps we can enable remote participation with you on this topic during the design summit 19:02:31 <igordcard_> SumitNaiksatam: it's just a matter of adding a new module for gbp and creating the wrapper calls accordingly 19:02:32 <yapeng> ODL GBP driver change will be submitted to reflect ODL GBP Lithium API changes. 19:02:33 <SumitNaiksatam> igordcard_: and for the other topics as well based on your availability and interest 19:02:38 <igordcard_> SumitNaiksatam: yes 19:02:42 <SumitNaiksatam> igordcard_: good 19:02:56 <yapeng> I will submit for review after I test against with kilo stable branch. 19:02:59 <SumitNaiksatam> yapeng: thanks for following on that, keep me in the loop on what you are planning 19:03:12 <SumitNaiksatam> yapeng: so that we can ensure that it makes the kilo cut 19:03:22 <SumitNaiksatam> alright, thanks all! 19:03:23 <yapeng> SumitNaiksatam, sure. when will cut happen? 19:03:37 <SumitNaiksatam> yapeng: you have at least a week for kilo-3 19:04:02 <SumitNaiksatam> bye! 19:04:05 <yapeng> SumitNaiksatam, sure. I think i can make it. 19:04:08 <yapeng> bye 19:04:11 <SumitNaiksatam> yapeng: thanks 19:04:19 <igordcard_> cya all 19:04:26 <SumitNaiksatam> #endmeeting