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