04:00:40 <SridarK> #startmeeting fwaas
04:00:40 <mickeys> Hi
04:00:41 <openstack> Meeting started Wed Jun  1 04:00:40 2016 UTC and is due to finish in 60 minutes.  The chair is SridarK. Information about MeetBot at http://wiki.debian.org/MeetBot.
04:00:42 <xgerman> Hi
04:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
04:00:45 <openstack> The meeting name has been set to 'fwaas'
04:00:50 <hoangcx> Hi
04:00:50 <chandanc> hello All
04:00:54 <SridarK> #chair xgerman njohnston
04:00:54 <openstack> Current chairs: SridarK njohnston xgerman
04:01:18 <SridarK> #topic Announcements
04:01:20 <njohnston> Hi all!
04:01:33 <SridarK> We are closing in on N-1
04:01:38 <SridarK> as u are all well aware
04:02:13 <SridarK> i think we need to get some v2 things in before N-2 comes along
04:02:21 <njohnston> absolutely
04:02:26 <yushiro> yes
04:02:53 <SridarK> lets cover some of the things around patches first before we get to stadium requirements
04:02:56 <xgerman> +1
04:03:18 <SridarK> #topic L3 Agent Extension
04:03:31 <SridarK> njohnston: thanks for taking the lead on this
04:03:38 <xgerman> +1
04:03:45 <SridarK> and thanks folks for starting to comment on this
04:03:47 <njohnston> I am in the middle of an edit adding some example data, which I think will address the open comments on the spec
04:04:01 <SridarK> njohnston: great
04:04:06 <SridarK> #link https://review.openstack.org/#/c/315745/
04:04:34 <njohnston> It struck me, the concept of a notification scheme for agent extensions could be generalized into a general case, and applied to any versioned object/agent extension combination.  So I have been thinking about what it would take to take the QoS notification scheme and turn it into a generalized versioned object/agent extension mechanism.
04:05:01 <xgerman> I think they should have do
04:05:05 <xgerman> On
04:05:07 <njohnston> I think that would be the easiest route for creating the L3 agent extension, although I have doubts.
04:05:12 <xgerman> E that from the get go
04:05:23 <SridarK> yes i agree - we need to dive down in to this
04:05:28 <njohnston> Agreed, I think they wre rushing it.
04:05:44 <xgerman> And now they
04:05:59 <SridarK> njohnston: do u think if some of us interested folks got together and allocate a couple of hours to dive into this
04:05:59 <xgerman> Are in their 3rd cycle
04:06:22 <njohnston> SridarK:  I think that would be very useful, yes
04:06:43 <padkrish> +1
04:06:46 <SridarK> we can atleast attempt to come up with a skeleton of what this should look like
04:06:59 <SridarK> and with ur experience with QoS - we can find some common ground
04:07:06 <njohnston> I think we could produce a patch that generalizes the agent extension framework and makes the existing QoS use case work with the new arrangement
04:07:16 <SridarK> njohnston: +1
04:07:16 <njohnston> And then our patch to leverage would be a natural successor
04:07:48 <SridarK> ok great - lets figure out some time to get this discussion going
04:07:51 <xgerman> Awesome + if we can add that to neutron lib 🤗
04:08:08 <njohnston> xgerman: ++
04:08:14 <SridarK> xgerman: that would great if we can do that
04:08:34 <xgerman> We can always invite dougwig
04:09:00 <SridarK> ok sounds good
04:09:13 <SridarK> njohnston: lets sync quickly tomorrow on this and plan for something ?
04:09:16 <njohnston> one last question
04:09:52 <njohnston> In the spec comments, Yamamoto Takashi pointed out the similarity to https://review.openstack.org/#/c/91532/11/specs/juno/l3-agent-consolidation.rst
04:10:06 <SridarK> njohnston: yes was getting to that too
04:10:14 <njohnston> I will look through that to see what we can glean from it that would be useful to add to this spec, since they are very similar
04:10:25 <njohnston> SridarK: Sorry for jumping the gun :-)
04:10:33 <SridarK> i think we should leverage some of this and see if we can colloborate
04:10:41 <SridarK> njohnston: no worries at all :-)
04:11:03 <njohnston> SridarK: And yes, let's definitely sync tomorrow and make a plan :-)
04:11:29 <xgerman> With it already N-1 we need to look at the clock when trying to do things outside the team
04:11:51 <xgerman> But good to sync ;-)
04:12:10 <SridarK> this jogged some memories - there were some thoughts here and lets see the contributor is still on this
04:12:42 <SridarK> yushiro: could i pls request u to reach out Toshihiro
04:12:48 <SridarK> the submitter
04:12:57 <SridarK> in ur time zone
04:13:22 <SridarK> if we can leverage some ideas and also get some help - will help our cause too
04:13:47 <yushiro> SridarK, Toshihiro? OK. I'll try it.
04:13:55 <SridarK> yushiro: thx
04:14:09 <yushiro> SridarK, Would you tell me his full name?
04:14:16 <SridarK> i will reach out offline
04:14:26 <SridarK> yushiro: ^^^
04:14:34 <njohnston> yushiro: IWAMOTO Toshihiro
04:14:34 <SridarK> ok lets move on
04:14:49 <yushiro> njohnston, Ah, I see. Thank you.
04:14:54 <SridarK> #topic FWaaS v2
04:15:39 <njohnston> I would like it if we could start landing some of the v2 patches, at least the initial stuff that others depend on
04:15:46 <SridarK> in the order of dependencies, i pinged shwetaap today
04:15:53 <SridarK> njohnston: exactly
04:15:56 <SridarK> :-)
04:16:11 <SridarK> shwetaap: i know u started looking into the extensions patch
04:16:12 <xgerman> showing progress is good
04:16:35 <SridarK> anything specific u want to discuss or bring up
04:16:36 <xgerman> Database is also a low hanging fruit
04:16:39 <SridarK> xgerman: +1
04:16:50 <shwetaap> I am looking at the existing firewall UTs, and creating the UTs for the firewall_v2 extension
04:17:00 <SridarK> shwetaap: ok good
04:17:12 <shwetaap> I will upload it to the existing patch
04:17:20 <SridarK> njohnston: i think this will be the dependency for the db patch
04:17:28 <njohnston> indeed
04:17:38 <SridarK> i have tested this earlier and there is enough there for us to move along
04:18:04 <SridarK> njohnston: we can figure out what are basic things that need to be added to the db patch
04:18:17 <SridarK> that will get me moving on the plugin
04:18:51 <njohnston> Excellent, yes, I made an inventory of everything in the spec, and it looked like almost all of it was there, but some of the names were different from what the spec was looking for
04:19:04 <SridarK> njohnston: ok great
04:19:57 <SridarK> njohnston: lets try to sync along with mfranc213 so we can close out some of these things so u can focus on the critical pieces in the db patch
04:20:06 <njohnston> Sounds good
04:20:32 <SridarK> padkrish: & yushiro: - i think u have been looking into the versioned objects pieces
04:20:46 <mfranc213> i'm sorry i have had no time to work on this.
04:20:49 <SridarK> njohnston: , mfranc213: thx very much for all the detailed clarifications
04:20:58 <yushiro> SridarK, Yes.
04:21:04 <SridarK> mfranc213: i think ur responses were very helpful
04:21:06 <padkrish> SridarK# Yes, looked into it a bit....need to understand more
04:21:11 <yushiro> SridarK, Currently, I'm trying to update https://review.openstack.org/#/c/268316/.
04:21:11 <yushiro> But I couldn't yesterday.  So, I've posted 'recheck'.
04:21:26 <padkrish> +1
04:21:43 <yushiro> SridarK, I and Paddu discuss/summarize our works as follows: https://etherpad.openstack.org/p/fwaas-v2-l2-agent
04:21:49 <SridarK> yushiro: ok
04:22:49 * njohnston appreciates the summary
04:23:03 <SridarK> +1 this looks really useful
04:23:06 <xgerman> +1
04:23:17 <SridarK> and i think a lot of this is also relevant to L3
04:23:27 <SridarK> with some tweaks
04:23:27 <xgerman> Yes, I exo
04:23:36 <xgerman> Eat the driver to be similar
04:23:58 <SridarK> +1
04:24:05 <xgerman> At least the version end object part should be identical
04:24:15 <SridarK> yes exactly
04:24:54 <njohnston> +1
04:24:59 <xgerman> We need to get in the changes to the firewall driver ipchains early
04:25:08 <SridarK> so if we can hook the ext - db - plugin together - we can start looking more into the versioned obj pieces that the plugin will need to support
04:25:34 <xgerman> +1
04:25:35 <yushiro> xgerman, SridarK I think so.  We need to know driver/plugin's interface in order to implement handle_xxx behavior.
04:25:43 <SridarK> and we can start some integration with yushiro: & padkrish:
04:25:55 <SridarK> yushiro: yes agreed
04:25:55 <xgerman> Nice.
04:26:27 <xgerman> Mickeys you are still on ipchains?
04:26:30 <SridarK> i suspect any updates to FW objects (that have relevance to the backend) should push out notifications
04:26:48 <mickeys> There are some basic issues with agent design that we have not discussed. Security groups pulls information in a port-centric manner. One port can have many groups associated with it. By pulling things on a port basis, all the groups of interest are grabbed.
04:26:51 <xgerman> SridarK: +1
04:27:18 <mickeys> For example, a rule may be added with a certain remote group that there was previously no interest in. How do you get the membership for that remote group?
04:27:32 <mickeys> Do you pull it all in one shot? Or does the agent iterate?
04:27:46 <mickeys> If it is all in one shot, what does that mean as far as versioned objects? With nested structures?
04:28:09 <xgerman> You can have lists of versions objects
04:28:15 <xgerman> So nested
04:28:25 <SridarK> mickeys: good point, i have not thought thru this - but in the simplistic model - can we iterate ?
04:28:52 <mickeys> Not sure. I have not thought about it much. I am reasonably familiar with what security groups does, but have not thought much about alternatives.
04:29:07 <SridarK> i am still at the point where we need the basic things plumbed together
04:29:12 <mickeys> One issue is that the agent tends to be stateless, i.e. it does not know what it already has.
04:29:15 <mickeys> The driver knows.
04:29:30 <mickeys> Wonders if it is OK for the agent to ask the driver?
04:30:06 <njohnston> How would the agent know to ask, except on startup?
04:30:09 <xgerman> Can't the agent just pass the event on and the driver handles it
04:30:18 <xgerman> ?
04:30:18 <SridarK> mickeys: hmm that i am not so sure - as we cannot really know the state of the driver
04:30:26 <SridarK> if we had a restart or so
04:30:31 <mickeys> Actually I think the agent probably does check with the driver for some things today. All agents get notified of a change, but they then have to figure out which ports are affected.
04:30:50 <xgerman> Yep, and the. Pull
04:30:53 <xgerman> The info
04:31:05 <mickeys> I have to recheck, remember how the agent figures this out.
04:31:41 <xgerman> I think we should get the chain magic in so we can have our own chain fast and then iterate on the rest
04:31:47 <njohnston> +1
04:31:54 <SridarK> +1
04:31:58 <xgerman> Worried about review times in neutron
04:32:18 <mickeys> Security groups generates a list of affected ports, then passes that to the server which determines all the relevant security groups based on the ports
04:32:22 <xgerman> And they are quick with bumping us to O
04:32:50 <SridarK> xgerman: sigh yes
04:33:53 <SridarK> ok we have some discussion needed here
04:34:23 <SridarK> once we figure out the basic versioned obj pieces - we will need to craft this carefully
04:34:47 <xgerman> +1
04:35:05 <SridarK> mickeys: could i request u to track this along with chandanc: & SarathMekala:
04:35:32 <mickeys> This meaning the two changes we need to propose to neutron security groups?
04:35:38 <SridarK> yes
04:35:51 <xgerman> +1
04:36:13 <mickeys> SridarK: Let's talk tomorrow
04:36:22 <SridarK> mickeys: ok sounds good
04:36:55 <SridarK> i think we have hit most of the areas we need to cover
04:37:13 <SridarK> we have enough to worry abt b4 we get to CLI, Horizon etc
04:38:11 <SridarK> Would it be too unrealistic to target having a basic workflow going from API to iptables (with caveats) by the end of June ?
04:38:14 <xgerman> Indeed. I don't see horizon before p
04:38:52 <SridarK> If L2 has some things to be figured out, maybe L3 (with the existing L3 agent override)
04:38:52 * njohnston doesn't know if it is unrealistic or not
04:39:03 <xgerman> We should aim for that. Otherwise we will never make O1
04:39:11 <SridarK> xgerman: yes indeed
04:39:21 <njohnston> good point xgerman
04:39:42 <SridarK> i think if we make steady progress - we will be able to pull it off
04:39:51 <xgerman> +1
04:40:30 <SridarK> we just need to prioritize the important things and make sure dependencies are unblocked (with some caveats/assumptions)
04:40:48 <SridarK> ok sounds good
04:40:55 <SridarK> anything else to discuss on v2
04:40:58 <SridarK> ?
04:41:21 <njohnston> Not here.  I suggest we move on and talk about the release cycle change.
04:41:28 <SridarK> +1
04:41:53 <njohnston> #topic release cycle change
04:42:01 <njohnston> armax proposes we change from release:cycle-with-milestone to release:cycle-with-intermediary
04:42:13 <SridarK> i think this is reasonable
04:42:16 <njohnston> see: http://lists.openstack.org/pipermail/openstack-dev/2016-May/096281.html
04:42:37 <njohnston> I support this change as I think it reduces pressure on us, and lets us keep focused on the real target
04:42:52 <SridarK> we are still in some initial stages, once we have things in motion then we will have more things going in
04:43:02 <njohnston> For those unfamiliar, here is more information on release:cycle-with-intermediary, see: https://governance.openstack.org/reference/tags/release_cycle-with-intermediary.html
04:43:34 <xgerman> We did that in Octavia and weren't allowed to call our release Mitaka but instead "compatible with M"
04:43:46 <xgerman> There is more than meets the eye
04:44:01 <SridarK> xgerman: Hmm Ok
04:44:45 <SridarK> the reality is that we just recovered from a broken repo and i think we should get more activity in the coming weeks
04:45:02 <xgerman> Not a big deal just to be aware off that they trigger certain tags (we also need to watch those)
04:45:23 <xgerman> Otherwise I support that change
04:45:30 <SridarK> xgerman: ok - i think u have experience here from Octavia - so we are in good hands
04:45:42 <njohnston> Being release:cycle-with-intermediary doesn't seem to hurt ironic, magnum, or monasca
04:45:55 <njohnston> But I look forward to seeing how it plays out
04:46:16 <xgerman> I don't think it hurts :-)
04:46:28 <SridarK> ok
04:46:49 <SridarK> lets move on
04:46:53 <SridarK> #topic Neutron Stadium
04:47:33 <SridarK> njohnston: thanks for capturing the important pieces from the spec
04:47:51 <njohnston> I went through them on the agenda: https://etherpad.openstack.org/p/fwaas-meeting
04:48:35 <SridarK> i think we need to get v2 implemented, and make sure we are not ignoring any of these listed pieces
04:48:42 <xgerman> Nice list!
04:48:46 <SridarK> with that we should be good
04:48:47 <njohnston> The area that I am most unfamiliar with is the documentation, apart from the api guide
04:49:06 <xgerman> Documentation we can do in tree
04:49:13 <njohnston> but except for my blind spot on documentation I agree, if we deliver v2 all sorts of woes will be healed
04:49:28 <mickeys> Does anyone know what neutron-api is yet?
04:49:35 <njohnston> as long as his condition of "reachable from docs.openstack.org" is met
04:49:56 <njohnston> mickeys: Vaporware AFAICT but I assume it will be born RSN
04:50:31 <SridarK> :-)
04:50:43 <xgerman> Is it the rework of the API Kevin is doing?
04:51:18 <xgerman> Nowadays I lack the time to keep up :-(
04:52:19 <SridarK> ok i think we can move on
04:52:29 <SridarK> #topic Open Discussion
04:53:32 <njohnston> I don't have anything, thanks SridarK for driving the meeting.
04:53:39 <SridarK> if we can get some things detailed this week - we could plan for a virtual mid-cycle accordingly
04:53:42 <xgerman> +1
04:53:46 <njohnston> +1
04:54:20 <SridarK> ok sounds good
04:54:26 <SridarK> other things folks would like to discuss
04:55:16 <yushiro> SridarK, plese let me confirm 1 thing.  What should I ask Toshihiro?
04:55:22 <njohnston> I will talk with the QoS guys about the generalization of the agent extension/notification stuff QoS has in the morning QoS meeting
04:55:41 <xgerman> Nice!
04:55:43 <SridarK> yushiro: i will send u an email
04:55:51 <yushiro> SridarK, Thanks.
04:55:52 <SridarK> njohnston: thx that will be good
04:56:22 <SridarK> njohnston: mfranc213: shwetaap: thx for accomodating and staying up at this late hour
04:56:46 <xgerman> +1
04:56:49 * njohnston thinks we lost mfranc213 ;-)
04:56:52 <SridarK> ok if nothing else lets close, thanks all for a good discussion
04:57:07 <SridarK> :-)
04:57:14 <yushiro> njohnston, I'd like to share your understanding about QoS extension :) Because, I'm referring QoS extension now.
04:57:54 <yushiro> njohnston, let me send e-mail to you in order to sharing information.
04:58:04 <SridarK> yushiro: yes that will be good
04:58:07 <njohnston> yushiro: Excellent, I would like that
04:58:27 <SridarK> ok bye all, Thx
04:58:30 <SridarK> #endmeeting