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