18:03:06 <SumitNaiksatam> #startmeeting networking_policy
18:03:06 <openstack> Meeting started Thu Jan 22 18:03:06 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:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:03:09 <openstack> The meeting name has been set to 'networking_policy'
18:03:28 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#Jan_22nd.2C_2015
18:04:09 <SumitNaiksatam> i dont have any “announcements” for today
18:04:16 <SumitNaiksatam> anyone have anything to share?
18:04:37 <SumitNaiksatam> songole: hi
18:04:42 <songole> Hi SumitNaiksatam
18:04:50 <SumitNaiksatam> ok moving on to pending bugs
18:04:53 <SumitNaiksatam> #topic Bugs
18:05:50 <SumitNaiksatam> all the pending critical, high, and medium bugs are currently assigned to either rkukura, ivar, myself or magesh-gv
18:07:20 <SumitNaiksatam> rkukura: for the medium priority bugs any update at your end?
18:07:39 <rkukura> SumitNaiksatam: no
18:07:50 <SumitNaiksatam> #link https://bugs.launchpad.net/group-based-policy/+bug/1382154
18:08:01 <SumitNaiksatam> #link https://bugs.launchpad.net/group-based-policy/+bug/1382147
18:08:08 <SumitNaiksatam> #link https://bugs.launchpad.net/group-based-policy/+bug/1407321
18:08:38 <SumitNaiksatam> rkukura: may be whenever you get a chance, can you update LP since these are currently targeted for kilo-1
18:08:45 <SumitNaiksatam> yapeng: hi
18:09:03 <yapeng> SumitNaiksatam: hi
18:09:19 <rkukura> rkukura: Didn’t realize that - will look/update
18:09:26 <rkukura> That ws for SumitNaiksatam
18:09:30 <SumitNaiksatam> rkukura: thanks
18:09:41 <SumitNaiksatam> #topic Packaging Update
18:10:20 <SumitNaiksatam> there was an issue which magesh-gv noted when installing the Heat package on Ubuntu
18:11:24 <SumitNaiksatam> it seems that the package name: group-based-policy-automation is not matching the name mentioned in the init file which is gbpautomation
18:11:37 <SumitNaiksatam> rkukura: did you run into this at all?
18:11:53 <SumitNaiksatam> i recall you mentioning something along similar lines
18:12:03 <SumitNaiksatam> but seems like you worked around it
18:12:14 <rkukura> I don’t think this was an issue for the RPM packaging
18:12:42 <rkukura> what’s the “init file”?
18:12:48 <SumitNaiksatam> #link https://github.com/stackforge/group-based-policy-automation/blob/master/gbpautomation/__init__.py#L17
18:13:26 <rkukura> The RPM packaging has a patch that replaces the contents of that file
18:13:51 <rkukura> The RPMs are not supposed to depend on PBR at runtime, so most openstack packages need this sort of patch
18:14:49 <SumitNaiksatam> rkukura: okay
18:15:00 <rkukura> so that explains why I didn’t hit the issue
18:15:22 <SumitNaiksatam> so i guess we need to check with mandeep, he is using this as is
18:15:47 <SumitNaiksatam> rkukura: so you override gbpautomation with “group-based-policy-automation”?
18:16:39 <rkukura> No, I set __version__ to a contant that has the version number from the spec file, in order to avoid the import/call of pbr.version
18:17:34 <SumitNaiksatam> rkukura: so what is the package name that you are using, it will perhaps make sense to have consistence across the distros
18:17:41 <SumitNaiksatam> *consistency
18:18:05 <rkukura> Normally, __init.py__ files don’t need to know the package name.
18:18:27 <rkukura> But the python top-level package name is gbpautomation. I certainly don’t do anything to change this.
18:19:23 <SumitNaiksatam> rkukura: ok, does this match the rpm name as well, or thats not relevant?
18:19:44 <rkukura> I don’t think we should be changing the package names at this point. These don’t need to match the RPM names.
18:20:02 <SumitNaiksatam> rkukura: okay
18:20:59 <SumitNaiksatam> rkukura: any update on the RDO packages?
18:21:25 <rkukura> Note that the egg_info is group_based_policy_autonmation*.egg-info, which seems to be based on the git repo name rather than the package name
18:21:46 <SumitNaiksatam> rkukura: yes thats how it shows up on the ubuntu side as well
18:21:50 <rkukura> And I’m pretty sure this is similar for the other projects as well
18:22:25 <rkukura> Maybe the string being passed to pbr.version.VersionInfo() just needs to change.
18:23:13 <SumitNaiksatam> rkukura: yeah, that was magesh-gv’s suggestion, but i wanted to make sure that it did not have any unitended side effects
18:23:21 <rkukura> I suspect PBR gets the egg-info name from the git repo name.
18:23:53 <rkukura> Changing just the contents of that shouldn’t be a problem for the RPM packaging, except I’ll need to change the patch to match the code being removed
18:24:32 <SumitNaiksatam> rkukura: right, we would backport this change so it will be a new rev
18:25:13 <SumitNaiksatam> rkukura: any update on the RDO packages?
18:25:56 <rkukura> The GBP RDO packaging is being tracked at https://trello.com/c/uoullOKB/26-group-based-policy-neutron-addons-an-example-of-public-participation
18:26:35 <rkukura> It looks to me that our packages are staged for the next update of the RDO yum repo
18:26:54 <SumitNaiksatam> rkukura: fantastic!
18:27:20 <rkukura> Once that is done, I’ll update the wiki page instructions to just do “yum install openstack-neutron-gbp”, etc.
18:27:21 <SumitNaiksatam> latest update from Alan Pevec - “RDO update is staged and ready to publish when stage CI passes (was blocked on internal infra issues)”
18:27:38 <SumitNaiksatam> rkukura: thanks for that update!
18:28:00 <rkukura> I’d definitely be interested in feedback from anyone trying to use the RDO packages
18:28:05 <SumitNaiksatam> any questions for rkukura on the RH packaging, or for me on the Ubuntu packaging?
18:29:07 <SumitNaiksatam> is krishna here?
18:29:26 <SumitNaiksatam> rkukura: was his issue from last week resolved?
18:30:19 <SumitNaiksatam> his question was “Is the rpm name for centos 7 different ?”
18:30:36 <rkukura> I see that now
18:30:52 <SumitNaiksatam> apparently he was able to install the gbp horizon package
18:30:53 <rkukura> I’ll follow up
18:31:01 <SumitNaiksatam> rkukura: thanks!
18:31:49 <SumitNaiksatam> #topic Kilo-1 Planning
18:32:27 <SumitNaiksatam> we are still in the process of gathering feedback on the Juno release
18:32:54 <SumitNaiksatam> in the meanwhile, there were a bunch of items which were left out of Juno
18:33:17 <SumitNaiksatam> the first thing that comes to mind is the pending bug fixes
18:34:06 <SumitNaiksatam> so as i mentioned in the bugs discussion, there is one critical and some high and medium priority bugs which we should target for kilo-1
18:34:08 <ivar-lazzaro> hi! sorry for being late!
18:34:30 <SumitNaiksatam> almost all of these are assigned to rkukura ivar-lazzaro SumitNaiksatam or magesh-gv
18:34:35 <SumitNaiksatam> ivar-lazzaro: hi
18:34:56 <SumitNaiksatam> KrishnaK: hi, we just wrapped up the discussion on your email
18:35:08 <SumitNaiksatam> KrishnaK: thanks for trying it, lets circle back to that in the open discussion
18:35:51 <SumitNaiksatam> so my proposal is that while we are gathering feedback on the Juno release, our first priority in kilo-1 is to clean up our plate on the bugs
18:36:15 <SumitNaiksatam> does that sound okay to everyone? (kind of obvious)
18:36:39 <s3wong> SumitNaiksatam: +1
18:36:39 <ivar-lazzaro> +1 :)
18:36:48 <yapeng> +1
18:37:05 <SumitNaiksatam> i believe there are also pending items on the vendor drivers - ODL, One Convergence and APIC - yapeng ivar-lazzaro songole?
18:37:06 <KrishnaK> SumitNaiksatam: Sorry I missed beginning part. Thanks will talk to you rkukura/ offline
18:37:17 <rkukura> KrishnaK: I just emailed you regarding your issue with the RPM.
18:37:57 <KrishnaK> rkukura: Thanks much. will try it out today.
18:38:01 <SumitNaiksatam> for issues which are discovered new and critically affect the Juno release, we will backport the fixes
18:38:47 <yapeng> SumitNaiksatam: Yi and I will submit UT patches for reviewing.
18:39:21 <SumitNaiksatam> yapeng: yes, yi has one patch already posted, but i have been behind for the review
18:39:35 <s3wong> yapeng: yes, I saw that Yi has posted a patch on UT
18:39:46 <SumitNaiksatam> #link https://review.openstack.org/145879
18:40:35 <SumitNaiksatam> yapeng: thanks
18:43:41 <SumitNaiksatam> the second item that we need to target for Kilo-1 is actually two related items -
18:44:05 <SumitNaiksatam> we need to move to using public APIs for Neutron
18:44:21 <SumitNaiksatam> as opposed to the current internal calls
18:44:42 <ivar-lazzaro> 1+++
18:44:43 <SumitNaiksatam> this will be the first step in moving to a separate serever which will be the second step
18:44:54 <SumitNaiksatam> thoughts?
18:44:58 <rkukura> SumitNaiksatam: I believe we are only making public API calls, but doing them directly to the plugin rather than via REST
18:45:17 <SumitNaiksatam> rkukura: yes
18:45:29 <SumitNaiksatam> REST calls to be more precise
18:45:34 <rkukura> If we are using plugin methods that are not part of the API, fixing that would be the very firsy step
18:45:36 <songole> SumitNaiksatam: +1
18:46:01 <SumitNaiksatam> rkukura: good point, i hope not
18:46:34 <rkukura> I’m not too comfortable with making REST API calls from within the server to the same server, as this can cause crazy chains of blocked threads, across replicas of the server through load balancers etc.
18:46:50 <SumitNaiksatam> rkukura: i agree, but this is an intermediate step
18:47:02 <SumitNaiksatam> rkukura: and hopefully a quick transition
18:47:28 <rkukura> We could at least do the client API as a patch that gets merged just before the patch to become a separate server
18:47:40 <rkukura> Or we could make it configurable whether to use direct or REST calls
18:47:57 <SumitNaiksatam> rkukura: the later is what i was thinking, sort a non-breaking change
18:48:05 <ivar-lazzaro> also a chain of patches could be an option
18:48:17 <rkukura> either is workable
18:48:51 <SumitNaiksatam> we can probably borrow from the client approach that nova currently has
18:49:09 <SumitNaiksatam> any other thoughts/opinions/concerns on this?
18:49:21 <SumitNaiksatam> as a priority that is
18:49:23 <rkukura> Are we also planning to remove foriegn key constraints and/or move to a separate DB?
18:49:48 <SumitNaiksatam> rkukura: that i would consider a third step
18:49:54 <rkukura> SumitNaiksatam: OK
18:50:02 <SumitNaiksatam> rkukura: my opinion is we should
18:50:09 <SumitNaiksatam> but i dont know what others think
18:50:15 <SumitNaiksatam> rkukura: you have thoughts on this?
18:50:40 <ivar-lazzaro> having a separate server it's probably a good idea. we will have to rely on notifications at that point
18:50:40 <SumitNaiksatam> good point to bring up though
18:50:45 <rkukura> Seems we should do it. Are the advanced services doing this too?
18:51:10 <SumitNaiksatam> rkukura: adv services have a separate DB chain for now (the last i checked)
18:51:16 <SumitNaiksatam> similar to what we have
18:51:24 <rkukura> SumitNaiksatam: Separate migration chain in same DB?
18:51:28 <SumitNaiksatam> but the plan was to move to a separate DB there as well
18:51:32 <SumitNaiksatam> rkukura: yes
18:51:32 <rkukura> OK
18:51:57 <SumitNaiksatam> but i am not sure that the final call has been made on that, we can only tell when it actually happens! ;-)
18:52:28 <SumitNaiksatam> and most likely not in kilo since i didnt see that as targeted in the specs for kilo
18:52:29 <SumitNaiksatam> anyway
18:53:09 <SumitNaiksatam> from a feature perspective the immediate high priority item i had on the list was floating IP support
18:53:34 <SumitNaiksatam> this was a feature that was targeted for Juno but we could not accomplish it
18:53:52 <ivar-lazzaro> +1
18:53:53 <SumitNaiksatam> songole along with hemanthravi and magesh-gv were working on this
18:55:14 <SumitNaiksatam> i think we need to get this in at the earliest
18:55:16 <songole> SumitNaiksatam: magesh-gv was working on it.
18:55:29 <songole> He is on vacation this week.
18:55:50 <SumitNaiksatam> songole: yes, he informed about that
18:57:00 <SumitNaiksatam> besides that we have blueprints in review
18:57:16 <SumitNaiksatam> LouisF’s have been pending for a long time
18:57:46 <SumitNaiksatam> so we should definitely go ahead and review them such that we can make progress on these at least past kilo-1
18:58:39 <SumitNaiksatam> if there is something that you would like to work on in kilo-1 and have time please come forward
18:59:23 <SumitNaiksatam> what i mentioned above are some of the pending items, and based on the people who are already lined up to work on those
18:59:39 <rkukura> SumitNaiksatam: What is our kilo-1 milestone, or are we skipping it and going right to kilo-2?
18:59:58 <SumitNaiksatam> rkukura: we will have the kilo-1 milestone, a short one i guess
19:00:16 <SumitNaiksatam> open to discussion though
19:00:37 <SumitNaiksatam> okay we have hit the hour, please let me know your thoughts on the above
19:00:51 <SumitNaiksatam> we can also continue the discussion on #openstack-gbp
19:00:56 <rkukura> Does our current master branch run with the neutron and other projects’ master branches? Maybe kilo-1 should focus on getting the Juno functionality working if needed.
19:01:08 <SumitNaiksatam> rkukura: correct
19:01:18 <SumitNaiksatam> ok thanks all for joining
19:01:22 <SumitNaiksatam> bye!
19:01:23 <s3wong> Thanks!
19:01:27 <rkukura> thanks SumitNaiksatam!
19:01:33 <SumitNaiksatam> #endmeeting