18:01:11 <SumitNaiksatam> #startmeeting networking_policy
18:01:12 <openstack> Meeting started Thu Jan 29 18:01:11 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:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:16 <openstack> The meeting name has been set to 'networking_policy'
18:01:57 <SumitNaiksatam> we will discuss kilo plan and milestone as an agenda items, but prior to that I dont have any milestone related announcements
18:02:11 <SumitNaiksatam> anything anyone wants to share in terms info/announcements to the team?
18:02:27 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#Jan_29th.2C_2015
18:02:46 <SumitNaiksatam> #topic Bugs
18:03:01 <SumitNaiksatam> we went through some of the major bugs last week
18:03:20 <SumitNaiksatam> a couple of more have been added to that, and mageshgv has fixed another
18:03:25 <SumitNaiksatam> yapeng: hi
18:03:58 <yapeng> hi
18:04:01 <SumitNaiksatam> but the meta-comment i had was that to request you to look at the assigned bugs
18:04:11 <SumitNaiksatam> most bugs have a milestone date
18:04:36 <SumitNaiksatam> if a bug is assigned to you and is targeted for k1, please confirm that you can fix it
18:04:46 <SumitNaiksatam> else move it to a later milestone
18:05:17 <SumitNaiksatam> for bugs which are more open ended we have a “next” milestone
18:05:23 <SumitNaiksatam> so use you judgements
18:05:26 <SumitNaiksatam> *judgement
18:05:35 <SumitNaiksatam> KrishnaK: hi
18:05:50 <KrishnaK> SumitNaiksatam: hi
18:06:08 <SumitNaiksatam> if we determine that the bug is high priority we cannot defer it to too long though
18:06:14 <SumitNaiksatam> currently we dont have any critical bug
18:06:18 <SumitNaiksatam> *bugs
18:07:14 <SumitNaiksatam> currently i think all of the k1 server side bugs are assigned to myself, rkukura, ivar-lazzaro, and mageshgv
18:07:15 <SumitNaiksatam> ivar-lazzaro: hi
18:07:20 <ivar-lazzaro> hi
18:08:15 <SumitNaiksatam> also please make a call whether a particular fix needs to be backported
18:08:40 <SumitNaiksatam> if so please assign the “juno-backport-potential” tag
18:08:58 <SumitNaiksatam> once the fix merges, please cherry-pick the fix to the stable/juno branch
18:09:15 <SumitNaiksatam> questions/comments?
18:09:59 <SumitNaiksatam> okay moving on
18:10:05 <SumitNaiksatam> #topic Packaging Update
18:10:21 <SumitNaiksatam> rkukura: you have some good news to report, right? ;-)
18:10:32 <rkukura> yes
18:10:56 <rkukura> At least I think this is since last meeting
18:11:06 <SumitNaiksatam> rkukura: yes
18:11:11 <rkukura> The GBP packages are now in the official RDO yum repositories
18:11:21 <SumitNaiksatam> yay!
18:11:33 <ivar-lazzaro> nice!
18:11:52 <rkukura> This means running “yum install \*gbp\*” will install all of them on top of an existing RDO setup.
18:12:10 <SumitNaiksatam> rkukura: sweet! thats much easier
18:12:12 <banix> cool!
18:12:23 <rkukura> I plan to do some testing and then update the RDO wiki page as soon as I get a chance.
18:12:32 <Yi> very cool
18:12:46 <KrishnaK> rkukura: great! Also thanks for your help this AM. Iam continuing my setup testing (centos ) ...
18:12:59 <rkukura> This should support Fedora 20 and 21, as well as RHEL 7 and CentOS 7.
18:13:58 <SumitNaiksatam> KrishnaK: thanks for your perseverance on this, you are the only person at this time that i know off who has dared to start testing on CentOS, so the team needs to really thank you here! :-)
18:14:09 <SumitNaiksatam> rkukura: cool
18:14:32 <rkukura> Next steps are to start supporting GBP in the puppet scripts and Red Hat’s packstack and foreman installers.
18:14:47 <SumitNaiksatam> rkukura: so the issues which KrishnaK has ran into (gbpautomation), that is CentOS-specific, or its his setup specific?
18:15:37 <rkukura> KrishnaK: Correct me if I’m wrong, but I think the issue was that the default packstack configuration did not install heat, so restarting it with GBP failed because it wasn’t configured.
18:16:07 <KrishnaK> rkukura: yes. thx.
18:16:09 <rkukura> I’ll add a note about this to the RDO GBP wiki as well.
18:16:42 <rkukura> That it for RDO.
18:16:47 <SumitNaiksatam> rkukura: good point about the installer
18:16:54 <SumitNaiksatam> *installers
18:17:08 <SumitNaiksatam> rkukura: is that a long process too, to get a patch in?
18:17:32 <rkukura> I’ve never directly worked on upstreaming puppet patches, but that may take some time
18:17:57 <SumitNaiksatam> rkukura: okay, is it an ongoing thing, or they have milestones and freezes too?
18:18:28 <rkukura> Would be good to get someone with puppet experience involved, and I think SumitNaiksatam may have someone in mind.
18:18:51 <SumitNaiksatam> rkukura: I am not volunteering myself :-)
18:18:59 <SumitNaiksatam> rkukura: but yeah we need to discuss offline
18:19:00 <rkukura> I don’t think upstream puppet is tied to OpenStack release cadence.
18:19:05 <SumitNaiksatam> rkukura: okay
18:19:18 <SumitNaiksatam> rkukura: anyone else wanting to jump in on this and help out is welcome
18:19:19 <rkukura> If anyone on the team wants to take this on, please speak up!
18:19:25 <SumitNaiksatam> rkukura: +1
18:20:02 <SumitNaiksatam> rkukura: if someone wants to jump in on this, you will be able to connect them to the right set of folks and pointers in terms of the process to follow?
18:20:31 <rkukura> I’m happy to advice and help, but I’m focusing on upstream neutron work right now, plus some GBP bug fixing, etc.
18:21:10 <SumitNaiksatam> rkukura: yeah, my question was more whether we know the process
18:21:12 <s3wong> sorry, late
18:21:17 <SumitNaiksatam> rkukura: seems like you know it
18:21:21 <SumitNaiksatam> s3wong: hi, np
18:21:33 <SumitNaiksatam> noticed songole joined earlier too, hi!
18:21:47 <rkukura> SumitNaiksatam: I’ve observed it through team meetings etc., back at Red Hat, but never involved directly with puppet or packstack.
18:21:48 <songole> Hi SumitNaiksatam
18:22:05 <SumitNaiksatam> rkukura: okay, i think that should be good to get us started
18:22:12 <SumitNaiksatam> okay any other questions for rkukura on the fedora and RDO?
18:23:05 <SumitNaiksatam> rkukura: BIG thanks on behalf of the entire team for working on this and getting this into RDO!
18:23:26 <SumitNaiksatam> on the ubuntu packaging
18:23:57 <SumitNaiksatam> mageshgv ran into an issue when installing the group-based-policy-automation package in his setup
18:24:10 <SumitNaiksatam> he investigated and found out why it happens
18:24:16 <SumitNaiksatam> mageshgv: thanks for that
18:24:26 <SumitNaiksatam> we are still working on what the right solution for this
18:24:45 <SumitNaiksatam> depending on which ubuntu packages you have installed, you may or may not run into that issue
18:25:05 <SumitNaiksatam> please ping mageshgv or me if you run into it and need a solution (while we are trying to fix this correctly)
18:25:12 <SumitNaiksatam> mageshgv: anything you wanted to add on that?
18:25:49 <SumitNaiksatam> ok next topic
18:25:49 <mageshgv> Basically we will run into this problem if we have pbr version <0.10.7
18:26:04 <SumitNaiksatam> mageshgv: ah okay
18:26:23 <SumitNaiksatam> #topic Proposed Kilo Plan and Milestones
18:26:29 <SumitNaiksatam> #link https://etherpad.openstack.org/p/kilo-gbp-plan
18:26:53 <SumitNaiksatam> so we have been gathering feedback after the release, and to some extent discusssing in this meeting as well
18:27:21 <SumitNaiksatam> the plan above is based on pretty much everyone’s input (and the issues we have logged in launchpad)
18:27:58 <SumitNaiksatam> this is a kind of a guiding plan
18:28:13 <SumitNaiksatam> we will adapt as we go along
18:28:24 <SumitNaiksatam> so please provide your feedback
18:29:14 <rkukura> I think we need to explicitly list tempest tests and CI
18:29:24 <SumitNaiksatam> rkukura: okay
18:29:31 <rkukura> I see GBP Test Plan and CI now, so OK
18:29:50 <rkukura> was looking for the word “tempest”
18:29:52 <SumitNaiksatam> yeah but we could add “tempest tests” as a separate item
18:30:02 <SumitNaiksatam> yeah we could add that explicitly
18:30:03 <SumitNaiksatam> i agree
18:30:27 <SumitNaiksatam> i think that is one are where we would need to work collectively as a team
18:30:53 <SumitNaiksatam> add coverage in tempest for the entire project cannot be done by one or two people
18:31:04 <SumitNaiksatam> *adding
18:31:29 <SumitNaiksatam> so we will start by identifying one or two people, and they can guide the rest of the team here
18:31:48 <SumitNaiksatam> if you are interested in participating in this, please ping me
18:32:32 <SumitNaiksatam> given that we planning to add more features, i think this is the most critical area of the project that needs attention so that we dont introduce regressions
18:32:59 <SumitNaiksatam> well even before we add features, we will be doing a bunch of refactoring
18:33:31 <SumitNaiksatam> do people have questions on the specific line items mentioned in the plan?
18:34:51 <Yi> for the l4-7 classifiers -- do you have more details?
18:34:51 <yapeng> I have question about DB change and REST API changes.
18:35:04 <SumitNaiksatam> i will take Yi’s question first
18:35:29 <SumitNaiksatam> Yi: yes, LouisF has posted a spec on that
18:35:52 <SumitNaiksatam> #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy-specs+branch:master,n,z
18:36:03 <SumitNaiksatam> Yi: the above has all the specs currently in review
18:36:38 <Yi> ok
18:36:43 <LouisF> SumitNaiksatam: i's like to have those specs reviewed
18:36:52 <SumitNaiksatam> LouisF: :-)
18:37:27 <SumitNaiksatam> LouisF: so Yi should look at the “GBP Classifier Extensions” spec?
18:37:43 <Yi> sure
18:37:54 <LouisF> SumitNaiksatam, Yi : yes
18:38:12 <SumitNaiksatam> is nicolas here?
18:38:30 <SumitNaiksatam> he was planning to do some investigation on the ODL side to see how this could be implemented
18:38:42 <SumitNaiksatam> that is partly the reason that is holding this up
18:39:10 <SumitNaiksatam> we need to have some level of validation that we are able to realize it
18:39:22 <s3wong> SumitNaiksatam: don't think there is any DPI project on ODL as of yet
18:39:31 <SumitNaiksatam> s3wong: hmmm
18:40:03 <s3wong> SumitNaiksatam: but that tons of projects are being proposed, so I probably have missed it
18:40:17 <SumitNaiksatam> s3wong: yeah, we had this discussion a few months back, seems like you are saying that not much has changed since
18:40:40 <SumitNaiksatam> that is part of the reason i put this in the second milestone so that we can some more time to investigate
18:40:50 <s3wong> SumitNaiksatam: not that I am aware of, but then again, I have NOT being attending or catching up with the TSC meetings
18:40:54 <SumitNaiksatam> LouisF: any chance that you can touch base with nicolas on this?
18:41:02 <SumitNaiksatam> s3wong: np
18:41:14 <yapeng> is the ODL the only option to implement this?
18:41:23 <LouisF> SumitNaiksatam: i will contact him reagrds the odl support for dpi
18:41:25 <SumitNaiksatam> yapeng: no, not saying that
18:41:43 <SumitNaiksatam> yapeng: i brought it up because that was the option that nicolas mentioned he was going to explore
18:41:49 <s3wong> yapeng: no, but we need a reference implementation
18:41:52 <SumitNaiksatam> other than that no one has proposed anything
18:42:00 <SumitNaiksatam> LouisF: thanks
18:42:10 <SumitNaiksatam> yapeng: back to your question
18:42:31 <SumitNaiksatam> yapeng: you were asking about DB and REST server?
18:43:34 <yapeng> my question is that: DB change seems have big impact on many things, how to resolve the dependencies of all the other feature developed in parallel?
18:43:45 <SumitNaiksatam> yapeng: yeah, good question
18:43:59 <SumitNaiksatam> in fact this is true for the entire refactor
18:44:47 <SumitNaiksatam> lets decide as as team as to whats the most non-disruptive path
18:44:53 <SumitNaiksatam> i have some ideas
18:45:07 <SumitNaiksatam> so specifically regarding the DB
18:45:28 <SumitNaiksatam> the critical change that we need to make is to remove the foreign key constraints
18:46:06 <SumitNaiksatam> foreing key constraints to the neutron tables that is
18:46:37 <s3wong> SumitNaiksatam: is upgrade from GBP Juno to GBP Kilo an item to consider also on this?
18:46:47 <SumitNaiksatam> s3wong: good point :-)
18:47:03 <SumitNaiksatam> s3wong: we will have to make some hard decisions there
18:47:43 <SumitNaiksatam> s3wong: one of the stated goals of the Juno release was that we are making it available to users to get their feedback, so changes should be expected
18:47:56 <s3wong> SumitNaiksatam: that
18:47:58 <rkukura> SumitNaiksatam: In place of the foriegn key constraints, is the idea to consume notifications from neutron and cleanup related GBP resources if something is deleted in neutron?
18:48:16 <s3wong> that's fair (sorry, accidentally hit "enter")
18:48:25 <SumitNaiksatam> that said, we will gauge who is using it, and how much impact it has, and based on that decide the most effective strategy
18:48:37 <SumitNaiksatam> we will definitely strive to minimize pain
18:49:36 <SumitNaiksatam> rkukura: good question, the point about concurrently using the Neutron API is tricky in itself (as we have discussed before)
18:50:30 <SumitNaiksatam> rkukura: the approach that you mention is certainly worth considering
18:51:04 <s3wong> SumitNaiksatam, rkukura: what approach?
18:51:32 <rkukura> s3wong: replacing the FK constraints with cleanup based on notifications from neutron
18:51:42 <SumitNaiksatam> s3wong: so if someone cleans up a port on the neutron side, clean up the PT of the GBP side
18:52:01 <s3wong> SumitNaiksatam, rkukura: OK
18:52:02 <SumitNaiksatam> and do this by consuming the port delete notification from Neutron
18:52:27 <SumitNaiksatam> this happens today based on the FK constraints
18:52:36 <s3wong> SumitNaiksatam, rkukura: does Neutron have all the notification on things we care about (port, subnet, router, SG, SG rules...)?
18:52:47 <SumitNaiksatam> and all that wil have to be implemented in the code when we decouple
18:53:01 <SumitNaiksatam> s3wong: yes, for all CRUD operations for all resources
18:53:24 <s3wong> SumitNaiksatam: good
18:53:44 <SumitNaiksatam> the issue obviously is that if the PT deletion fails for some reason, then we are left in an inconsistent state
18:53:52 <SumitNaiksatam> or if we lose the notification
18:54:14 <rkukura> Hopefully we’ll be able to work through these kinds of details in reviewing specs for kilo.
18:54:25 <SumitNaiksatam> rkukura: yeah
18:54:42 <rkukura> which means getting the spec written ;)
18:54:46 <SumitNaiksatam> :-)
18:55:13 <Yi> Sumit, rkukura: the notification is coming from API, or from mechanism driver?
18:55:14 <s3wong> SumitNaiksatam: so the notification comes as the API is invoked? Or as the operation is completed (i.e., the Neutron port is deleted)?
18:55:41 <rkukura> as I recall, there are start and end notifications
18:56:03 <SumitNaiksatam> Yi: s3wong the notification comes on an AMQP topic
18:56:33 <s3wong> rkukura: oh, OK
18:56:34 <ivar-lazzaro> Do they exist for any resource? Or just ports?
18:56:59 <banix> all resourcces
18:57:04 <SumitNaiksatam> ivar-lazzaro: my earlier point, it used to be for all resources, unless something has changed
18:57:27 <SumitNaiksatam> the API handling code had the notifications built it
18:57:56 <rkukura> ivar-lazzaro: Ports have additional notifications for specific state changes to be consumed by nova
18:58:09 <SumitNaiksatam> rkukura: good point
18:58:15 <SumitNaiksatam> okay we have a couple of mins
18:58:16 <rkukura> and/or by firewall (SG) driver/agent
18:58:24 <SumitNaiksatam> good dicussion
18:58:29 <yapeng> neutron has these kinds of notification existing today?
18:58:31 <s3wong> SumitNaiksatam, rkukura: with this, does it mean that our policy drivers no longer need to have the GBP ML2 driver?
18:58:37 <SumitNaiksatam> we need to have a lot more of that on these topics
18:58:38 <ivar-lazzaro> SumitNaiksatam, rkukura: I see. thanks for the clarification
18:59:07 <banix> yes, ceilometer for example uses them I believe (not to mention nova)
18:59:08 <SumitNaiksatam> ivar-lazzaro: i was trying to look up the code, but github is not responding
18:59:19 <SumitNaiksatam> s3wong: no, that is independent
18:59:31 <SumitNaiksatam> banix: perfect, thats where it started
18:59:39 <ivar-lazzaro> s3wong: I guess it depends on what your ML2 driver' role is. For instance, if you use it to bind a special ML2 network type you may still need one
19:00:45 <rkukura> s3wong: one potential risk is that the ml2 driver and policy driver will now be in separate processes, but may need some coordination, but that shouldn’t be too difficult, and is not that different from cases where neutron-server is replicated.
19:01:02 <s3wong> ivar-lazzaro, SumitNaiksatam: I see. The reason I asked is that one of the function of the GBP ML2 driver seems to be get notified for port state changes
19:01:20 <SumitNaiksatam> ivar-lazzaro: rkukura s3wong: good points
19:01:25 <SumitNaiksatam> we are min over time
19:01:32 <SumitNaiksatam> we can take this to #openstack-gbp
19:01:36 <SumitNaiksatam> thanks all for attending
19:01:44 <SumitNaiksatam> bye
19:01:45 <s3wong> SumitNaiksatam: obviously a great topic to discuss :-)
19:01:46 <banix> bye
19:01:47 <rkukura> thank
19:01:51 <mageshgv> bye
19:01:51 <s3wong> thanks!
19:01:56 <SumitNaiksatam> #endmeeting