18:03:20 #startmeeting networking_policy 18:03:21 Meeting started Thu Jun 25 18:03:20 2015 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:03:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:25 The meeting name has been set to 'networking_policy' 18:03:39 #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#June_25th_2015 18:04:00 hi 18:04:04 sorry I’m late 18:04:12 rkukura: hi, no just in time :-) 18:04:34 so first up, upadate on the release 18:05:15 our original plan was to cut a k4 somewhere in middle of june 18:05:25 and then do the release end of june 18:05:44 we obviously didnt do the k4, so we are behind on that 18:06:29 at this point of time the delay in cutting k4 is with regards to the readiness of node drivers 18:06:54 and also the plumbers that ivar and igordcard_ are working on 18:07:26 @SumitNaiksatam What plumbers are Ivar and Igor working on? 18:07:28 we will not be making it to the end of june now 18:07:29 I'm expecting the beginning of July to give me a boost on my availability regarding the plumber 18:07:37 igordcard_: ok, np 18:07:55 ransari: ivar is working on the stitching plumber 18:08:08 ransari: and igordcard_ is working on a traffic sterring plumber 18:08:22 ransari: igordcard_’s patch is up for review 18:08:44 SumitNaiksatam: sitcthing and steering for neutron rendering? 18:08:50 igordcard_: we have not given you enough review feedback either! 18:08:53 SumitNaiksatam:ok 18:09:37 so at this point i prefer not to put a specific date on the release, except that we should try to get to it at the earliest 18:09:53 SumitNaiksatam: is the stitching plumber the same as the chain_agnostic plumber? 18:09:57 but of course our first priority is to cut k4 milestone 18:10:14 rkukura: are you referring to the one that was already merged? 18:10:38 rkukura: if so, that is not the stitching plumber 18:10:43 SumitNaiksatam: yes. Not sure if its complete or if stitching is a new one 18:10:54 rkukura: the stitching plumber will allow insertion of transparent services 18:11:01 ok 18:11:12 rkukura: chain_agnostic plumber does not do any stitching 18:11:22 SumitNaiksatam: I do not yet have enough content to be reviewed either, I'm at fault there 18:11:31 OK, so 3 plumbers in kilo! 18:11:33 igordcard_: okay :-) 18:11:41 rkukura: yes, that is what we expect 18:12:05 rkukura: So when will we have the kilo rpms ready? 18:12:06 rkukura: the chain agnostic one just creates a PT in a PTG 18:12:21 ransari: you mean k3 rpms? 18:12:33 SumitNaiksatam: yes 18:12:34 or do you mean final kilo rpms? 18:13:04 #topic Packaging 18:13:06 SumitNaiksatam: K3 and also final. 18:13:30 ransari: okay, so final will obviously depend on when we do the release 18:13:34 SumitNaiksatam: Also the backports to stable/Juno will require new Juno rpms? 18:13:47 ransari: i would expect the k4 rpms to be available before that 18:14:16 i will address backport, lets first hear from rkukura if he has update on k3 rpms 18:14:20 SumitNaiksatam: we have customers asking for kilo rpms 18:14:24 * rkukura wonders if we should stop calling these stable branches 18:15:21 ransari: you mean asking now for k3 rpms? 18:15:21 I’ve been wrestling with the nova node driver and a bit of neutron stuff, so haven’t made any progress on packaging the last week 18:16:06 rkukura: okay 18:16:22 SumitNaiksatam: yes k3 rpms for UI, but soon the backported Juno rpm 18:17:01 as for backports, i release 2014.2.2 for group-based-policy-service 18:17:30 planning to release for ui and automation as soon as we are done with the backports 18:18:00 ransari: between juno and kilo which rpms are more urgent? 18:19:10 SumitNaiksatam: Kilo UI rpms first and then Juno GBP service rpm 18:19:32 ransari: okay, lets follow up after this meeting to see how we can make progress on that 18:20:01 SumitNaiksatam: do we have a date for this: 2014.2.2 for group-based-policy-service 18:20:19 SumitNaiksatam: ok 18:20:56 ransari: 2014.2.2 is already cut, but rpm will have to be created (it has backports and floating ip support) 18:21:44 SumitNaiksatam: ok. thnaks 18:21:45 #topic Integration tests and gate 18:22:14 some of the current patches in review are failing the integration test suite (gbpfunc) 18:22:26 however the logs are not getting archived 18:22:35 this patch fixes that: 18:22:41 https://review.openstack.org/#/c/195394 18:23:17 once that patch is merged we will be able to get the logs on the failing patches and debug better 18:23:37 also last week release of the new oslo libs caused some issues on our branches 18:23:48 mainly due to i18n not being pinned at our end 18:24:20 we expected this to come from the global requirements, however it was required to pin this particular lib on stable/juno 18:24:40 anyway, we are currently unblocked on the stable/juno for backports after that fix 18:25:17 I’ll be back in 5 minutes 18:25:19 i also tried running Ajay’s rally test suite but ran into some problems 18:25:26 i will report next week on that 18:25:29 rkukura: okay 18:26:39 #topic Features 18:26:57 #link https://review.openstack.org/166424 18:27:11 Admin tenant owns service chain instances ^^^ 18:27:24 ivar is not here 18:27:34 ransari: did you get a chance to look at the latest rev? 18:28:02 i believe it has the default behaviour you need with regards to the provider owning the chain resources 18:28:27 SumitNaiksatam: yes, i did and +1 it 18:28:35 ransari: ah ok, good 18:28:55 #link https://review.openstack.org/189640 18:29:04 “Reference driver for Node composition plugin” ^^^ 18:29:22 ransari: i dont think magesh is here, any update on the above? 18:29:54 SumitNaiksatam: he is working on it 18:30:17 ransari: okay, any blockers that you know of? 18:30:47 SumitNaiksatam: none that I am aware of 18:30:54 ransari: ok good 18:31:22 #link https://review.openstack.org/179327 18:31:29 “Shared PRS" 18:31:56 ransari: i believe there was a suggestion from you to split the patch? 18:32:37 SumitNaiksatam: Will get abck with the testing with along with https://review.openstack.org/#/c/177159/ 18:32:52 * rkukura is back 18:32:54 and wanted feedback from Ivar as to whtehr there are specific testcases to cover 18:33:14 ransari: ok great, perhaps you can note on the review 18:33:17 SumitNaiksatam: the split suggestion was if it helps accelerate the merge 18:33:41 SumitNaiksatam: perhaps we can consider split to have 2 parts (1) Shared PRS (2) SG Manager 18:33:46 ransari: i believe we need to check that the update works at all 18:33:46 rkukura: duly noted 18:34:07 ransari: perhaps you want in the reverse order 18:34:14 SumitNaiksatam: ok 18:34:39 SumitNaiksatam: yes, that was not mean to be order, just the 2 parts 18:34:49 ransari: that said if the current patch is ready, you might not need the split 18:34:54 SumitNaiksatam: yes 18:35:07 rkukura: you were comfortable with: #link https://review.openstack.org/179327 18:35:15 “shared prs” ^^^ 18:35:46 I haven’t looked at the latest patch set yet, but was comfortable with #16. 18:36:00 I can re-review today 18:36:09 rkukura: great, thanks 18:36:17 So no need to split? 18:36:26 rkukura: i dont think so 18:36:51 if we are able to verify that this works (along with the neutron patch: #link https://review.openstack.org/#/c/177159/) 18:37:05 ransari is planning to do the verification 18:37:22 rkukura: meanwhile if you are fine with the code, please feel free to reflect that 18:37:36 OK 18:37:46 we will have a second +2 only after verification from ransari 18:38:19 I may hold my +2 until the verification as well ;) 18:38:24 rkukura: :-) 18:38:43 i dont have an update on the implementation of the quota support 18:38:52 but if anyone wants to jump in on this, please let me know 18:39:00 we need this to release kilo 18:39:24 #topic GBP Heat 18:39:55 in kilo we changed the namespace for the GBP resources 18:40:13 the plan is to backport this to juno as well 18:40:37 this will break existing templates that use the namespace used in jun 18:40:39 juno 18:41:21 also, if there are any heat stacks running (in Juno) they will have to be deleted, before doing the update 18:41:46 SumitNaiksatam: If they aren’t deleted before, can they be deleted after, or is the DB corrupt? 18:42:17 rkukura: so thats an interesting questions 18:42:21 *question 18:42:53 so when we are talking about DB here, we are talking about the internal DB 18:43:28 by internal i mean, the DB that tracks the state of resources in a stack 18:43:41 there is no DB schema for each heat resource 18:43:55 so, i am thinking that what you are asking might actually work 18:44:01 however, i havent tried it 18:45:06 Just my usual concerns about what happens when someone who has a juno-based fedora or RDO deployment runs “yum update”. 18:45:20 rkukura: right 18:45:45 in the worst case scenario that the delete doesnt work after update, the above backport is obviously disruptive 18:46:35 however, with little knowledge of any long standing deployment of GBP templates, we are leaning towards going forward with this backport 18:47:08 That’s the thing wih open source - we can’t know if/how anyone is using it 18:47:15 rkukura: agreed 18:47:57 rkukura: however, unlike the gbp service, the likelihood of a heat template being in deployment in much much lesser 18:48:13 Assuming we ever get around to updating the juno fedora/RDO packages, I’m wondering what we can do to prevent people from trashing an existing deployment without being aware of it 18:48:17 so far we are aware of it being only used in demos, and testing scenarios 18:48:57 rkukura: would proper documentation in release notes help? 18:49:01 rkukura: "Assuming we ever get around to updating the juno fedora/RDO packages" - is there a risk this won't be done? 18:49:25 rkukura: good suggestion w.r.t release notes. 18:49:34 ransari: Just comenting because its been on my plate for a long time 18:49:49 rkukura: ok 18:50:03 rkukura: another advantage of backporting is that it will make it easier for customers who are planning to use Juno to transition to Kilo 18:50:04 Problem is an admin isn’t likely to read release notes before running “yum update” 18:50:31 rkukura: note that these customers have not started using the Juno release yet but they plan to soon 18:50:40 Maybe there would be a way to have the update fail before doing anything if there is an existing GBP DB, or something like that. 18:50:41 rkukura: these are the real users/customers that we know of 18:50:53 This isn’t the first item that is a concern for these updates 18:52:03 rkukura: so IMHO we should be aligning for users that we know that are definitely going to use this, versus those we think might be currently (but we have not data on) 18:52:15 *not -> no 18:52:55 I’m not arguing to not do the update, just trying to make sure we have a way to prevent people from trashing a working deployment 18:53:08 rkukura: right 18:53:18 rkukura: regarding the update failing, i believe the update can be crafted that way 18:53:22 s/update/backport/ 18:53:41 rkukura: or at least the hooks exist to do that 18:53:44 Lets move forward and leave this as a problem to be solved in the packaging 18:53:56 rkukura: okay, good suggestion 18:54:03 rkukura: ransari thanks for your input on this 18:54:13 so we will move forward with this backport 18:54:39 those using the Juno templates will have to update them after we do this update 18:54:43 #topic CLI 18:54:59 rkukura’s patch on service profile: #link https://review.openstack.org/#/c/192447 18:55:21 ransari: if magesh is able to verify this, please request him to comment on the review 18:55:46 Ivar had some comments that I responded to, and I double-checked that the attributes all work, so hopefully he can re-review soon 18:55:54 rkukura: great, thanks 18:56:02 we have 5 mins 18:56:13 so a few quick questions, wanted to poll here - 18:56:25 earlier we had a “member CRUD” CLI 18:56:28 and we removed it 18:56:39 users are asking that we put this back 18:56:52 since it corresponds to the behavior in the UO 18:56:54 *UI 18:57:05 what is “member CRUD”? 18:57:23 also its kind of painful to deal with getting the port from the PT etc 18:57:37 rkukura: create/delete Member in a PTG 18:57:54 So PT CRUD? 18:57:56 rather than having to create a PT, extract the port, then launch the VM using the Port 18:58:02 Or is this the nova part? 18:58:07 rkukura: the nova part 18:58:35 just the way we have the option in the UI 18:59:53 let me know your thoughts offline if you think this is a bad idea 19:00:10 so we have hit the hour 19:00:37 dont forget the etherpad for choosing a new name: #link https://etherpad.openstack.org/p/gbp-rename-proposals 19:00:52 we will continue in the IRC next week 19:01:08 and on #openstack-gbp in the meanwhile 19:01:10 thanks all! 19:01:13 bye 19:01:17 thanks SumitNaiksatam! 19:01:27 #endmeeting