18:00:58 <SumitNaiksatam> #startmeeting networking_policy
18:00:58 <openstack> Meeting started Thu Apr  9 18:00:58 2015 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:02 <openstack> The meeting name has been set to 'networking_policy'
18:01:24 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#April_9th.2C_2015
18:01:39 <Yi_> hi
18:02:00 <SumitNaiksatam> starting with the standing items
18:02:15 <SumitNaiksatam> #topic Bugs
18:02:48 <SumitNaiksatam> we fixed one of the two critical bugs
18:03:11 <SumitNaiksatam> (waiting for backport on https://bugs.launchpad.net/group-based-policy/+bug/1432779 to merge)
18:03:12 <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:18 <SumitNaiksatam> rkukura: i believe you have a suggestion on doing an upgrade for: #link https://review.openstack.org/#/c/170972/
18:04:50 <SumitNaiksatam> upgrade in the DB migration
18:04:51 <rkukura> yes, we really need to start doing proper DB migrations on both the master and stable branches
18:05:29 <rkukura> normally these wouldn’t be allowed on the stable branch, but as long as we can keep the master and stable branches equivalent, I think we’ll be able to get away with it
18:05:55 <SumitNaiksatam> rkukura: so in this case your suggestion is to explicitly drop the foreign key constraint?
18:06:24 <SumitNaiksatam> in a separate migration script
18:06:39 <rkukura> since we are not trying to support trunk-chasers on master, I think it would be OK to insert migrations that will be back-ported before those that won’t on master
18:06:57 <SumitNaiksatam> rkukura: okay
18:07:09 <rkukura> I was trying to track down an example of a migration script that uses alembic introspection to remove existing unnamed constraints
18:07:14 <rkukura> but got interrupted
18:07:24 <SumitNaiksatam> rkukura: was just asking that
18:07:28 <rkukura> I’ll add the link to the review when I find it
18:07:36 <SumitNaiksatam> rkukura: ok thanks
18:07:46 <SumitNaiksatam> ivar-lazzaro: does that sound reasonable?
18:08:08 <ivar-lazzaro> rkukura: SumitNaiksatam: I think we should remove unnamed constraints with brute force in both master and juno if we realistically can
18:08:21 <rkukura> ivar-lazzaro: why?
18:08:29 <ivar-lazzaro> of course it's a no go if we are planning on supporting backward compatibility
18:08:39 <ivar-lazzaro> because unnamed constraints are DB specific
18:08:54 <ivar-lazzaro> and they are harder to remove with proper migration afterwards
18:09:06 <rkukura> ivar-lazzaro: there is a reasonable db-indepent way to deal with them in migrations
18:09:53 <ivar-lazzaro> rkukura: I think Magesh had proposed one some time ago in a patch, but then we decided to just remove the constraint from the original migration script
18:10:04 <rkukura> My belief is we cannot ever modify existing migrations - we need to start doing proper migrations, so we’d need new migrations to remove names from the old ones
18:10:27 <ivar-lazzaro> rkukura: so if we are going that way lets make sure we fix that too, or the compatibility will be broken regardless
18:10:35 <rkukura> now that there can be users of packages out there, we cannot have deployments break when someone does a “yum update”
18:11:13 <SumitNaiksatam> ivar-lazzaro: on that particular one we can perhaps take a pass since we didnt hear back from anyone ;-)
18:11:39 <rkukura> we haven’t updated any packages yet
18:11:44 <ivar-lazzaro> rkukura: I agree in general, I was just making the consideration based on our claim based on whether we want to support Juno backward compatibility or not
18:12:02 <ivar-lazzaro> rkukura: if so, then your solution is probably the one that makes more sense
18:12:32 <ivar-lazzaro> SumitNaiksatam: yeah but that's something we may need to revert if we decide on doing proper migrations
18:12:36 <rkukura> I’m OK with adding features on stable/juno if needed, and adding DB migrations, but we need to make sure we don’t break deployments that update
18:12:47 <SumitNaiksatam> rkukura: agree
18:12:57 <rkukura> So we are not promising strict backward compatibility
18:13:05 <SumitNaiksatam> ivar-lazzaro: agreed we can correct that as well, we consider it necessary
18:13:30 <SumitNaiksatam> ivar-lazzaro: we have to see the time line as to when we generated the packages and if that fix went in before or after that
18:13:37 <rkukura> also, reordering migrations, if needed, is a lot easier now that we don’t need to support downgrades
18:14:02 <SumitNaiksatam> rkukura: okay
18:14:21 <SumitNaiksatam> the other critical bug is regarding kilo sync
18:14:35 <SumitNaiksatam> #link https://bugs.launchpad.net/group-based-policy/+bug/1433530
18:14:37 <openstack> Launchpad bug 1433530 in Group Based Policy "GBP Kilo release should be in sync with Neutron Kilo" [Critical,In progress] - Assigned to Magesh GV (magesh-gv)
18:14:50 <SumitNaiksatam> #link https://review.openstack.org/165377
18:14:56 <SumitNaiksatam> i know magesh has been hard at work on this
18:14:57 <ivar-lazzaro> OK, if there's a db independent way of dealing with unnamed constraints I'm all for it then
18:15:24 <SumitNaiksatam> mageshgv: you want to provide an update?
18:16:01 <mageshgv> SumitNaiksatam: The code changes are complete and UTs and devstack work fine now
18:16:35 <mageshgv> The only issue open now is with the experimental gate job
18:16:42 <SumitNaiksatam> mageshgv: yeah
18:16:55 <SumitNaiksatam> we are seeing this” /opt/stack/new/group-based-policy/gbpservice/tests/contrib/post_test_hook.sh: line 14: .tox/dsvm-functional/bin/subunit-1to2: No such file or directory"
18:17:08 <rkukura> ivar-lazzaro: see https://review.openstack.org/#/c/116122/23/neutron/db/migration/alembic_migrations/versions/2d2a8a565438_hierarchical_binding.py
18:17:26 <SumitNaiksatam> and we are able to reproduce this in our local environments
18:17:47 <mageshgv> #link http://logs.openstack.org/77/165377/20/experimental/check-group-based-policy-dsvm-functional/386cfc4/console.html
18:17:49 <ivar-lazzaro> rkukura: thx!
18:18:03 <SumitNaiksatam> the expectation is that python-subunit should install the subunit-1to2 binary
18:18:10 <SumitNaiksatam> however its not there
18:18:45 <SumitNaiksatam> mageshgv: any more insight after we last chatted?
18:19:12 <mageshgv> SumitNaiksatam: Unfortunately I couldnt get any clue after this
18:19:18 <SumitNaiksatam> mageshgv: okay
18:19:45 <SumitNaiksatam> if anyone else has ideas please let us know, at this point we seem to have a bit of a wall on this one
18:20:09 <SumitNaiksatam> the same job used to work fine earlier
18:20:48 <SumitNaiksatam> any other bugs that we need to discuss?
18:21:45 <SumitNaiksatam> #topic Functional/integration tests
18:21:58 <SumitNaiksatam> not much update here from me
18:22:20 <SumitNaiksatam> i was trying to adapt jishnu’s package as functional tests in our repo
18:22:39 <SumitNaiksatam> however, its quite a bit of changes, so i am working on that, but currently its on the back burner
18:22:58 <SumitNaiksatam> #topic Packaging Update
18:23:15 <SumitNaiksatam> rkukura: anything to discuss?
18:23:41 <rkukura> Updating the fedora packages to the latest stable/juno release is still on my list
18:23:59 <rkukura> At this point, should I wait for a new stable release?
18:24:39 <rkukura> Also, I haven’t checked if there are any problematic DB schema changes in the most recent stable release - if there are, we may need to add proper migrations
18:25:07 <SumitNaiksatam> rkukura: i think, backport to stable is a separate agenda item, lets make a call on that during that discussion
18:25:14 <rkukura> ok
18:25:26 <SumitNaiksatam> may be lets just discuss that right now :-)
18:25:37 <SumitNaiksatam> #topic Backport changes to stable branch
18:25:47 <SumitNaiksatam> we had a bit of this discussion already
18:26:21 <SumitNaiksatam> but there is a biggere requirement now
18:26:48 <SumitNaiksatam> there is are users who want are deploying Juno but want to use some of the GBP kilo features
18:27:34 <SumitNaiksatam> so the proposal on the table is to backport changes we are making in kilo back to stable/juno beyond just the critical bug fixes
18:27:36 <SumitNaiksatam> thoughts?
18:28:25 <SumitNaiksatam> we will obviously not backport the kilo sync related functionality
18:28:40 <rkukura> So normally, API changes, config changes, and DB schema changes are not back-ported to OpenStack stable branches, but I’m OK with relaxing this since our goal at this point is to get this out there an iterate
18:28:56 <SumitNaiksatam> rkukura: okay, agree
18:29:45 <SumitNaiksatam> are there any concerns or objections from anyone else in the team on this?
18:30:31 <rkukura> If we decide to do this, we need to make sure users of juno fedora, RDO, ubuntu, whatever packages don’t become too annoyed
18:30:32 <rkukura> I think adding features or even changing features would be acceptable for early adopters, but we need to avoid blatently breaking deployments
18:30:47 <SumitNaiksatam> rkukura: agree
18:31:09 <SumitNaiksatam> and by avoid breaking, you mean do the proper migrations?
18:31:23 <SumitNaiksatam> DB migrations
18:31:34 <rkukura> proper migrations are required, and changes to config need careful thought
18:32:48 <SumitNaiksatam> rkukura: okay
18:32:50 <SumitNaiksatam> we need to discuss whether we want to back port the Neutron REST API refactor as well, or leave it in Juno
18:33:30 <rkukura> SumitNaiksatam: back-porting that would require some effort since new config info would be needed
18:33:42 <SumitNaiksatam> rkukura: correct
18:34:19 <Yi_> SumitNaiksatam: you meant to leave it in Kilo?
18:34:21 <SumitNaiksatam> however not backporting it might introduce significant complexity for merging future backports
18:34:36 <SumitNaiksatam> Yi_: sorry, yeah i meant leave in in Kilo
18:36:02 <SumitNaiksatam> there is another option, we can move the Neutron REST API refactor changes to a feature branch
18:36:44 <rkukura> Is there any way we could merge all kilo features and backport them before merging the switchover to REST?
18:37:14 <rkukura> We should be treating this relaxation of the stable rules as a very tempoary windoqw
18:37:16 <rkukura> window
18:37:38 <SumitNaiksatam> rkukura: we have already merged some of the refactor patches
18:37:42 <SumitNaiksatam> only one remains
18:38:07 <rkukura> I thought the ones we merged were additions rather than changing the existing code
18:38:16 <SumitNaiksatam> rkukura: that is also true
18:38:37 <rkukura> So we can just avoid back-porting the addtions
18:38:43 <SumitNaiksatam> i was thinking that if we create a separate feature branch, then we can merge the changes right away
18:38:58 <SumitNaiksatam> and then keep rebasing that branch with the changes in the master
18:39:03 <rkukura> A feature branch for the REST switchover?
18:39:07 <SumitNaiksatam> rkukura: yeah
18:39:27 <SumitNaiksatam> there might be some effort needed to keep the feature branch in sync with the master
18:39:35 <rkukura> That might be a good idea anyway, since there is some risk that REST calls within a single server could be problematic
18:40:10 <SumitNaiksatam> rkukura: yeah, and i was thinking we can them move these changes back to master, when we are creating the independent server (which we might not get to in the kilo time frame)
18:40:11 <rkukura> But how many kilo features do we want to back-port, and are these (almost) ready?
18:40:43 <yapeng> If we consider feature branch approach, would gbp wsgi server change and database change belong to this branch as well?
18:40:45 <SumitNaiksatam> rkukura: no they are not ready, since this is kind of user driven, so difficult to predict where we would draw the line on this
18:41:01 <SumitNaiksatam> rkukura: although i completely agree with you that we should be conservative
18:41:10 <SumitNaiksatam> and draw the line sooner than later
18:42:01 <SumitNaiksatam> anyone else has thoughts on this?
18:42:35 <SumitNaiksatam> perhaps needs more thought, so lets take this offline
18:42:40 <SumitNaiksatam> #topic Re-factor Group Based Policy with Neutron RESTful APIs
18:42:46 <SumitNaiksatam> #link https://review.openstack.org/#/c/156856
18:42:51 <SumitNaiksatam> Yi_: over to you
18:43:08 <Yi_> I just uploaded one update
18:43:11 <SumitNaiksatam> i noticed you discovered some related issues and were trying to fix those
18:43:29 <SumitNaiksatam> Yi_: ah nice
18:43:56 <Yi_> previous one breaking the test cases that were introduced in  bug/1432779
18:44:07 <Yi_> but Ivar helped me on this
18:44:25 <SumitNaiksatam> great
18:44:35 <Yi_> and I was able to verify the latest code fix the issue on my own machine
18:44:41 <SumitNaiksatam> nice
18:44:58 <Yi_> so it should be good for review now
18:45:02 <ivar-lazzaro> Having switched to Neutron REST APIs, we had to merge Neutron's policy.json with ours for UTs
18:45:13 <SumitNaiksatam> ivar-lazzaro: oh okay
18:45:18 <ivar-lazzaro> at least the important parts (get on shared resources)
18:45:56 <SumitNaiksatam> seems a little counter intuitve to me
18:46:01 <SumitNaiksatam> but i might be missing something
18:46:27 <ivar-lazzaro> External Segments creation was trying to retrieve the corresponding external subnet
18:46:44 <ivar-lazzaro> in some UTs, the latter was a shared subnet owned by a different tenant
18:47:16 <ivar-lazzaro> when using neutron plugin directly, this would work without a problem
18:47:57 <ivar-lazzaro> but with WSGI calls, the policy.json filter would block the call given that the requesting tenant was different from the resource owner, returning a 404
18:48:17 <SumitNaiksatam> ivar-lazzaro: so are these changes to the policy.json in sync with what is in neutron’s policy.json or do they change some of those definitions?
18:48:40 <ivar-lazzaro> the change is only in the test-policy.json we load for UTs
18:48:55 <SumitNaiksatam> ivar-lazzaro: okay, thats good
18:49:14 <SumitNaiksatam> we are short on time and i would really like to cover the next item
18:49:20 <SumitNaiksatam> Yi_: ivar-lazzaro: thanks for the update
18:49:32 <Yi_> my pleasure
18:49:38 <SumitNaiksatam> #topic Floating IP Support
18:49:44 <SumitNaiksatam> #link https://review.openstack.org/157298
18:50:12 <SumitNaiksatam> mageshgv: you had sent out an email earlier to some folks in the team regarding changes you need to make to support this on Juno
18:50:25 <SumitNaiksatam> mageshgv: did you hear back from anyone?
18:50:56 <mageshgv> SumitNaiksatam: I havent heard back from anyone, may be we can discuss it now ?
18:51:13 <SumitNaiksatam> mageshgv: yes please summarize the approach that you need to take
18:52:42 <mageshgv> In Juno, Neutron does not allow us to specify the floating IP Address that we wish to use for a particular floating IP resource.
18:52:45 <mageshgv> The address allocation is completely managed by Neutron in Juno.
18:54:16 <mageshgv> So, if we want to backport this Floating IP support to Juno, we cannot use Nat Pool to allocate a floating IP from (we cannot force a floating IP to be created from this particular allocation pool)
18:55:02 <mageshgv> So, the only option to support this in Juno is to have Floating IP allocation to be linked to the External Segment rather than a Nat Pool
18:55:23 <ivar-lazzaro> mageshgv: what if we forced the nat pool to be equal to the ES subnet?
18:55:43 <ivar-lazzaro> mageshgv: would that be easier to upgrade to the right model in Kilo?
18:56:08 <SumitNaiksatam> ivar-lazzaro: how do you envisioning enforcing this?
18:56:29 <SumitNaiksatam> a validation check when creating the nat pool?
18:56:36 <SumitNaiksatam> that can be removed later?
18:56:46 <ivar-lazzaro> mageshgv: whenever a NAT-Pool is linked to the external segment we validate that the pool coincides with the ES subnet
18:56:51 <mageshgv> ivar-lazzaro: that would work, but then we will be limiting our Nat Pool resource and it is going to be a duplicate of ES subnet ?
18:56:52 <ivar-lazzaro> SumitNaiksatam: ^^^
18:57:23 <ivar-lazzaro> mageshgv: yes, but it should be easier when you upgrade from Juno to Kilo
18:57:37 <ivar-lazzaro> mageshgv: and you can keep using your nat pools as they are, and eventually modify them
18:58:08 <SumitNaiksatam> ivar-lazzaro: do we know of a real use case which we need to support where the nat pools are different from the ES subnet?
18:58:22 <mageshgv> ivar-lazzaro: Sounds good from a workflow perspective
18:59:15 <ivar-lazzaro> SumitNaiksatam: the ES subnet may not be externally visible
18:59:23 <ivar-lazzaro> SumitNaiksatam: while FIPs usually are
18:59:44 <SumitNaiksatam> ivar-lazzaro: FIPs need not be externally visible too
18:59:50 <ivar-lazzaro> SumitNaiksatam: yeah true
18:59:58 <SumitNaiksatam> okay i need to bring up one more item before we end today
19:00:00 <SumitNaiksatam> sorry for rushing
19:00:07 <SumitNaiksatam> mageshgv: thanks for the update (lets close offline)
19:00:11 <SumitNaiksatam> #topic Open Discussion
19:00:41 <SumitNaiksatam> regarding the Vancouver summit, we have been asked if we would like to have design summit session slots
19:01:03 <SumitNaiksatam> the option is to have fishbowl sessions and/or workrooms
19:01:32 <SumitNaiksatam> see this #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054122.html for more details on the difference between the two
19:01:41 <SumitNaiksatam> the current thinking seems to be to ask for workrooms
19:01:50 <SumitNaiksatam> please let me know your thoughts at the earliest
19:02:01 <SumitNaiksatam> we need to decide what kind of rooms we want and how many
19:02:26 <SumitNaiksatam> btw, design summit sessions are only for OpenStack projects
19:02:48 <rkukura> the email says workrooms hold 20-40 people
19:02:54 <SumitNaiksatam> since our project proposal is in the pipeline, we have been offered this opportunity (to set things into context)
19:03:00 <SumitNaiksatam> rkukura: yeah
19:03:29 <ivar-lazzaro> rkukura: seems good
19:04:20 <SumitNaiksatam> anything else anyone want to bring up?
19:04:22 <igordcard> When is the service chain refactoring spec arriving to -specs?
19:04:35 <SumitNaiksatam> igordcard: good question :-)
19:04:41 <SumitNaiksatam> hemanthravi was taking the lead on this
19:05:01 <SumitNaiksatam> but he is on PTO, and is planning to put it in as soon as he gets back
19:05:14 <igordcard> okay
19:05:20 <SumitNaiksatam> meanwhile we can continue the discussion and if there is consenus start the implementation
19:05:28 <SumitNaiksatam> as a first iteration
19:05:37 <SumitNaiksatam> we are five minutes over
19:05:50 <SumitNaiksatam> thanks all for your time today!
19:05:52 <SumitNaiksatam> bye!
19:05:54 <igordcard> cya
19:05:55 <banix> bye
19:05:59 <mageshgv> bye
19:06:00 <yapeng> bye
19:06:04 <SumitNaiksatam> #endmeeting