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