18:31:08 <SridarK> #startmeeting Networking FWaaS
18:31:09 <openstack> Meeting started Wed May  4 18:31:08 2016 UTC and is due to finish in 60 minutes.  The chair is SridarK. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:31:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:31:12 <openstack> The meeting name has been set to 'networking_fwaas'
18:31:28 <SridarK> #chair xgerman
18:31:30 <openstack> Current chairs: SridarK xgerman
18:31:44 <mickeys> Hi
18:32:15 <xgerman> Hi
18:32:16 <njohnston> #info According to the ical file from eavesdrop, we are actually in an even week, so today's meeting should be at 8pm, FYI.
18:32:33 <njohnston> I suggest we make normalizing the meeting schedule a topic for the meeting. :-)
18:32:39 <shwetaap> Hi
18:32:47 <SridarK> njohnston: sigh ok - since we are in an odd week
18:32:49 <SridarK> my bad
18:32:50 <xgerman> njohnston +1
18:33:00 <SridarK> hence i sent the email out
18:33:12 <njohnston> I didn't look at my calendar until the last second.
18:33:19 <mfranc213> yes, that was very helpful for me Sridar.
18:33:21 <SridarK> njohnston: ok lets do that as a topic
18:33:34 <SridarK> njohnston: apologies
18:33:49 <njohnston> No, I think it's good, I would be at a family function at 8pm :-)
18:34:02 <SridarK> serendipity :-)
18:34:26 <SridarK> #topic Summit, v2 priorities
18:34:55 <SridarK> Firstly for the record - thanks all for the great discussion on Fri
18:35:00 <njohnston> +1
18:35:04 <chandanc> +1
18:35:15 <mfranc213> +1
18:35:22 <padkrish> +1
18:35:39 <SridarK> we can continue to use the etherpad
18:35:44 <SridarK> #link https://etherpad.openstack.org/p/neutron-fwaas-austin
18:36:42 <SridarK> Are there any blocking issues that we need to discuss and work to resolution
18:37:03 <njohnston> There is the issue I emailed out, the issue with oslo.service
18:37:09 <SridarK> i spent some time with chandanc and Sarath o the gerrit workflow
18:37:28 <mfranc213> yes, i looked at the oslo.service thing but not long enough to figure it out unfortunately.
18:37:40 <chandanc> Thanks for the help with gerrit
18:38:00 <SridarK> yes clearly there is an issue - i was able to see that as well - we can try to do some digging in parallel to see what is going on
18:38:39 <njohnston> And if I hack in a fix for that, by adding an argument, then I get to a further issue where it looks like a multiple inheritance issue supplying parameters to an __init__() method
18:38:52 <mfranc213> fwiw, the symptomology is simliar to this: http://freshfoo.com/blog/object__init__takes_no_parameters
18:39:45 <mfranc213> and actually it appears that the initial bug, the one that nate put a hack into fix, is the same problem as what appears after the hack :)
18:39:53 <mfranc213> that's how it appears to me, anyway.
18:40:16 <mfranc213> this issue is deep in the weeds, as far as i can tell.  an interesting problem.
18:40:16 <njohnston> Here's what I am seeing on the __init__ issue: http://paste.openstack.org/show/496130/
18:40:50 <mfranc213> (what nate has just posted is what is seen after the hack is put in place)
18:41:17 <njohnston> Yes, the first line tries to explain that
18:41:36 <mfranc213> ahh, yes, sorry nate
18:41:41 <njohnston> I'm not sure who to reach out to in order to see if we're using oslo.service incorrectly.  Perhaps dims?
18:42:04 <SridarK> yes i am puzzled - i will dig more too
18:42:13 <xgerman> josh harlow - he is the oslo PTL
18:42:39 <xgerman> harlowja
18:42:44 <njohnston> Excellent.  I will put together a better presentation of the issue and contact him.  Thanks xgerman!
18:42:58 <xgerman> yeah, tell him I send you :-)
18:43:03 <SridarK> :-)
18:43:06 <njohnston> :-)
18:43:18 <mfranc213> one thing i wanted to do was to see how other callers handle that __init__ in oslo_service.  will try to get to that today.  think that reaching out to others is good, too.
18:43:26 <SridarK> ok lets continue on this
18:43:42 <SridarK> mfranc213: my thought too - i am sure this is a common pattern
18:43:50 <mfranc213> yeah, should be
18:44:13 <njohnston> Other than that I have gotten a start on accounting for all the db objects in the db patch, and trying to make sure that (other than the aforementioned problem) it passes tox.
18:45:06 <xgerman> sorry, guys gotta run today early… should be better next week when I am back home...
18:45:07 <SridarK> other than some methods related to rules, u will need to add for the other resources
18:45:14 <SridarK> xgerman: no worries
18:45:29 <njohnston> Sure, feel free to leave feedback on the PS
18:46:09 <njohnston> that's probably the best way to keep me honest on it :-)
18:46:10 <mfranc213> there are orm questions that nate and i will be discussing also.
18:46:40 <SridarK> we can target some very basic sketchy plumbing with the extensions - db - plugin patches in abt 2 weeks
18:46:48 <mfranc213> perfect
18:46:53 <SridarK> does that seem reasonable ?
18:46:58 <mfranc213> it does to me, yes
18:47:08 <mfranc213> sorry, just speaking regarding the db piece
18:47:23 <SridarK> mfranc213: yes no worries
18:47:51 <SridarK> just drawing a line in the sand
18:48:04 <njohnston> sounds good
18:48:10 <mfranc213> Sridark: one thing that would be very helpful for me at this stage is TODO item 1 on https://etherpad.openstack.org/p/neutron-fwaas-austin ??
18:48:26 <mfranc213> not sure why i have ?? there.  pretend they're not there.
18:48:44 <SridarK> ok i will do that
18:48:57 <mfranc213> thank you SridarK!
18:49:37 <SridarK> Perhaps shwetaap can use the same model and resubmit a patchset for the extension
18:50:02 <SridarK> same approach as njohnston and mfranc213 for db patch
18:50:19 <mfranc213> SridarK: i'm sorry, can you say more about what you mean here?
18:50:28 <SridarK> i think the ext patch does have most have the pieces in place
18:50:32 <mfranc213> ah
18:51:14 <shwetaap> sounds good .. i will do that
18:51:36 <SridarK> shwetaap: can u pls run thru the patch to see what could be missing and then either submit another patch or restart the old one
18:52:24 <SridarK> mfranc213: sorry - all i meant is if we want to resurrect the old patch or submit a new one as u guys did for db
18:52:27 <shwetaap> sure will do
18:52:39 <SridarK> either is fine - leave it to the new owners
18:52:44 <mfranc213> SridarK: ahh, i see.
18:53:31 <njohnston> shwetaap: When you do testing, just ignore py27 and py34, they will always fail until we get the oslo.service issue fixed.
18:54:09 <SridarK> On the agent piece - yushiro is back next week - perhaps then padkrish - u guys can sync as well
18:54:18 <mfranc213> once the oslo issue is fixed, we will want the team to know about it.  what is the best way to do that?  apologies if i've asked this already.  is it by email?
18:54:29 <shwetaap> njohnston: thanks will keep that in mind
18:54:36 <padkrish> #sridark# sure, i will also sync up with german regarding the existing patch
18:54:44 <SridarK> mfranc213: sure that will be easy
18:54:53 <mfranc213> SridarK: ack
18:55:20 <SridarK> mickeys: things u want to bring up on the iptables front ?
18:55:47 <mickeys> I have not made any progress. I need to start on the patch to add a common unwrapped chain.
18:56:26 <chandanc> I have been setting up the dev env , downloaded the current patch
18:56:30 <SridarK> mickeys: ok
18:56:44 <SridarK> chandanc: ok
18:56:49 <chandanc> will ping mickey with questions
18:57:11 <SridarK> chandanc: if u need to sync with mickeys while in the same time zone
18:58:00 <SridarK> other things regarding v2 that anyone wants to bring up ?
18:58:00 <chandanc> sure sridark, may be by tomorrow i will have a better view
18:58:13 <SridarK> chandanc: ok perfect
18:58:38 <njohnston> nothing else to bring up, but I feel like we have gotten a decent start.
18:58:43 <mfranc213> +1
18:58:46 <SridarK> +1
18:59:06 <njohnston> once we have the oslo.service issue figured out we should probably put that fix out in a separate patch so we can fast-track merging it
18:59:15 <mfranc213> +1
18:59:41 <SridarK> njohnston: yes - pls add xgerman and me to the review - in case we miss it
18:59:43 <njohnston> I've also started looking at all the neutron-lib deprecations, that looks like it will probably not be difficult to fix.
18:59:50 <njohnston> SridarK: Will do.
19:00:16 <mickeys> Regarding 264488, I still feel that position does not belong in rule. We wanted to be able to reference a rule from multiple different policies. IMO this should be abandoned.
19:01:05 <SridarK> njohnston: yes we can prioritize as we see fit once we get some traction on the v2 patches
19:02:15 <SridarK> mickeys: yes agreed
19:02:27 <njohnston> mickeys: From a DB schema perspective, 'position' is a field in the firewall_policy_rule_associations table, so it is an attribute per association, not globally for the rule.
19:02:58 <njohnston> At least, that is what the spec laid out, so that's what I am working towards for the DB
19:03:25 <SridarK> njohnston: having it in the association table enables the reuse
19:03:31 <SridarK> so yes
19:03:42 <mickeys> njohnston: The proposed change is in the REST API section. It should remain in the DB association table.
19:03:43 <chandanc> yes
19:05:29 <SridarK> ok lets move on
19:05:57 <njohnston> But according to that change 'position' only indicates the position within the associated policy, making it a policy-specific bit of data for that rule.
19:05:57 <SridarK> #topic other reviews
19:06:00 <njohnston> OK, leaving that for later
19:06:23 <chandanc> should the rule position not be part of the policy API ?
19:06:39 <chandanc> sure, lets move on
19:06:48 <SridarK> ok lets pick it up in open discussion
19:07:06 <SridarK> we have the observer hierarchy patch out
19:07:20 <SridarK> #link https://review.openstack.org/#/c/278863/
19:07:38 <SridarK> this is also plagued by the UT issue
19:08:10 <SridarK> i think the patch does what is intended - i am trying to test this as well
19:08:34 <SridarK> i have been talking to the submitter - he going thru some testing and possibly add some more on the UT
19:08:51 <SridarK> request folks to get some eyes on this as well
19:09:21 <mfranc213> i will take a look
19:09:23 <SridarK> with this in - will enable us to remove some fwaas stuff from L3Agent
19:09:31 <SridarK> thx
19:09:46 <njohnston> +1 for removing fwaas stuff from L3Agent
19:09:58 <SridarK> any other reviews that folks want to bring up ?
19:10:46 <SridarK> badveli: could u pls also take a look
19:11:34 <SridarK> ok lets move on
19:12:00 <SridarK> #topic FWaaS weekly meeting time
19:12:26 <badveli> yes
19:12:40 <badveli> i will take a look sridhark
19:12:41 <njohnston> I think there was consensus for a single meeting time
19:12:58 <mfranc213> +1
19:13:11 <SridarK> i realize with some new contributors from the India and Japan we will struggle to find a time that works fantastically for all
19:13:48 <SridarK> i am fine with the single time too - will certainly avoid a snafu like today :-)
19:14:35 <SridarK> possible lets throw some times out over email - so we ensure that active contributors are able to find some common ground
19:14:45 <chandanc> +1
19:15:16 <njohnston> The best guess I can come up with is 9:00am EST == 10:00pm in Japan, 6:30pm in New Delhi
19:15:43 <njohnston> But I shall be as flexible as I can. :-)
19:15:57 <chandanc> We can consider the discussion we had during summit
19:16:15 <mfranc213> = 6 am PST
19:16:22 <SridarK> i start my day early - so i can make that work - but 6am Pacific could abe a challenge for some
19:16:57 <SridarK> yushiro is out this week - so lets start the discussion first thing next week
19:17:02 <njohnston> Sounds good.
19:17:04 <mfranc213> so the delta between earliest and latest is, ignoring daylight savings, 8 hours.
19:17:05 <mickeys> That is two hours earlier than I normally wake up
19:17:14 <chandanc> sure, better to propose in mail thread, 6:30 pm India is mostly way back from Office. Can we push by 30 mins
19:17:27 <mfranc213> if we push pacific time up, japan suffers...
19:17:45 <mickeys> I thought night time US, morning India and Japan might work better
19:18:08 <SridarK> lets see what is upper boundary for yushiro
19:18:34 <SridarK> and if we do evening what is the upper boundary for Eastern time zone
19:18:42 <SridarK> so we can do this over email
19:18:53 <mickeys> When DST ends, it becomes one hour earlier
19:18:56 <mickeys> in the US
19:18:57 <chandanc> sure
19:18:58 <mfranc213> i think 11-ish ?
19:19:20 <njohnston> midnight EST == 1:00pm tokyo == 9:30am new delhi == 9:00pm san jose
19:19:23 <mfranc213> speaking just for myself.
19:19:32 <njohnston> I would be fine with midnight
19:20:20 <SridarK> ok may be we have a formula there which we can tweak so it is not too late for Eastern and make it work for all
19:20:40 <njohnston> I am also happy to have the opportunity to provide for our esteemed colleagues in Asia the flexibility they have so often given us.
19:21:32 <mfranc213> yes, perhaps something like 10:30 pm EST == 11:30am tokyo == 8am new delhi == 7:30pm san jose
19:21:49 <mfranc213> i will be flexible too.  +1 for what njohnston just said
19:22:01 <SridarK> ok good - lets take it to email then first thing next week
19:22:05 <njohnston> +1
19:22:12 <chandanc> +1
19:22:22 <SridarK> #topic Open Discussion
19:22:43 <mickeys> Regarding 264488, the API rules table is not in the context of a policy. The DB association table is in the context of a policy, so position there makes sense and is a good thing. In the API, the position is specified through the ordered list of rules in the policy table.
19:23:22 <njohnston> Looking forward: I am somewhat unfamiliar with how all this code works in practice; is there anything that is a pre-requisite for our testing fwaas in the lab to make sure the code hangs together, once we get to that point?
19:24:20 <SridarK> njohnston: something as basic as a single node devstack env is good
19:24:44 <mfranc213> mickeys: would you be able to add your suggestions and concerns as comments to https://review.openstack.org/#/c/264488/ itself?
19:25:03 <njohnston> SridarK: Very good.  I know we had to be much more involved when working on QoS DSCP because we weren't satisfied until we had tcpdumps showing the traffic was behaving as configured.
19:25:06 <SridarK> i have been using that to test out what ever we have albeit with some hacks
19:25:57 <mfranc213> SridarK: do you generally pull from master for all other OS components?
19:25:59 <SridarK> i usually have a rule with an obscure port number - so i can quickly grep for that on the iptables to see if it made it all the way
19:26:07 <SridarK> mfranc213: yes
19:26:12 <mfranc213> ack
19:26:15 <chandanc> mickey: agree, with the ordered list of rule in policy we should already have the position. right ?
19:26:42 <njohnston> SridarK: Is the devstack directives necessary to set up fwaas documented?  Could you share your local.conf with us?
19:26:59 <SridarK> njohnston: ok surely will do that
19:27:13 <SridarK> q-fwaas - will set up the service plugin
19:27:24 <mickeys> mfranc213: I have put comments in 264488 in the past, for example Jan 15 8:19am comment
19:27:35 <mfranc213> mickeys: thank you.
19:27:46 <padkrish> just q-fwaas and ofcourse l3-agent in local.conf is all that's needed, i guess
19:27:54 <mfranc213> mickeys: do you feel your comments in the PS are exhaustive?
19:27:59 <SridarK> padkrish: yes
19:28:29 <mickeys> mfranc213: Do you think I should add another comment expanding on this, along the lines of the comments I made above?
19:28:32 <njohnston> padkrish and SridarK: does it matter at all what ML2 driver is in use?
19:28:37 <SridarK> 2 min warning
19:28:41 <mfranc213> mickeys: i think that would help me, yes.
19:29:03 <SridarK> njohnston: it should not
19:29:16 <padkrish> njohnston# good question, my default settings are always ovs as ML2 driver
19:29:22 <njohnston> SridarK: Excellent.  That is what I thought, but I am checking my assumptions.
19:29:24 <SridarK> njohnston: do u use linux bridge ?
19:29:51 <njohnston> SridarK: I typically use OVS but I have had trouble in func tests where both OVS and LB were tested scenarios.
19:29:54 <SridarK> +1 to padkrish - i use ovs usually too
19:30:09 <SridarK> njohnston: ok
19:30:16 <SridarK> ok folks times up
19:30:20 <mfranc213> two things: 1) i've been adding TODOs to https://etherpad.openstack.org/p/neutron-fwaas-austin
19:30:21 <SridarK> thanks all
19:30:22 <mfranc213> , and 2) is there anyone else here who is having difficulty editing https://wiki.openstack.org/wiki/Neutron/FWaaS/NewtonPlan (as i am)?
19:30:27 <njohnston> thanks all!  good meeting!
19:30:34 <mickeys> There is a bit of additional code in iptables when using OVS, but it should not make a significant difference. I never did figure out how conntrack zones are assigned in case of LB, should probably get back to that.
19:30:35 <padkrish> thanks
19:30:38 <SridarK> mfranc213: lets pick it up later
19:30:44 <mfranc213> thank you
19:30:56 <mfranc213> bye all
19:30:59 <SridarK> #endmeeting