18:30:11 <sc68cal> #startmeeting networking_fwaas
18:30:11 <openstack> Meeting started Wed Dec 16 18:30:11 2015 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:30:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:30:14 <openstack> The meeting name has been set to 'networking_fwaas'
18:30:17 <sc68cal> #chair xgerman
18:30:18 <openstack> Current chairs: sc68cal xgerman
18:30:56 <ajmiller> Hi
18:31:00 <sc68cal> So. I think the biggest piece of business is getting the API spec from the 5 yard line, into the endzone
18:31:01 <bharathm> xgerman is on vacation. Not sure if he would join
18:31:02 <jwarendt> Hi
18:31:16 <madhu_ak> hi
18:31:16 <sc68cal> #chair SridarK
18:31:17 <openstack> Current chairs: SridarK sc68cal xgerman
18:31:23 <SridarK> Hi All
18:31:44 <sc68cal> #topic API spec discussion
18:31:58 <Aish> sc68cal: yes, we would like to get it merged.
18:32:04 <SridarK> sorry will be slow as i am debugging on another internal issue
18:32:13 <sc68cal> So - we're very close. I think there are some small details around the rule behavior
18:32:36 <sc68cal> #info openstack gerrit is being upgraded today
18:32:37 <SridarK> Aish: sc68cal: agree - i will have a last go later in the day today
18:32:59 <sc68cal> gotcha
18:33:03 <mickeys> I can do another round of comments tomorrow
18:33:26 <jwarendt> +1
18:33:32 <sc68cal> The main thing that kept me from +2'ing it was the addition of that note where if there is no source or destination included in a rule - that means that it matches any packet
18:34:26 <sc68cal> since gerrit is down I'll try and replicate my comment. Basically if you want it to match any packet, set the source or dest to 0.0.0.0/0 or ::/0
18:34:28 <mickeys> I checked security groups yesterday. The API allows no remote security group or remote address prefix. By the time it gets down to iptables, either way 0.0.0.0/0 is programmed in the rule. Horizon forces specification of 0.0.0.0/0
18:34:32 <xgerman> Hi, I am on mobile...
18:35:00 <xgerman> sc68cal: +1
18:35:04 <SridarK> sc68cal: to be more explicit
18:35:17 <SridarK> yes
18:35:43 <sc68cal> So, you must have a source and destination, that's my thinking for the rule
18:36:05 <sc68cal> now , the question is do we want to let rules that mix the kinds of source and destination
18:36:16 <sc68cal> like source_ip_prefix and destination_firewall_group
18:36:27 <mickeys> I thought it would be easier for users if they don't have to specify both, but if everyone else thinks they should both be specified, fine
18:36:41 <mickeys> I think we should allow source_ip_prefix and destination_firewall_group
18:36:48 <sc68cal> ^ this works for me
18:36:57 <xgerman> +1
18:37:04 <mickeys> Remember that if you are going to something external, firewall_group does not work
18:37:22 <jwarendt> Allow mixing from my perspective.
18:37:40 <sc68cal> mickeys: a firewall group could be external
18:37:52 <sc68cal> like if you have a 2nd subnet, router, and network, or something
18:37:57 <mickeys> A firewall group is a group of ports. How does that represent external addresses?
18:38:24 <sc68cal> mickeys: could be addresses on another tenant network - same tenant
18:38:33 <xgerman> External to the tenant but still in the same cloud
18:38:34 <mickeys> Maybe I should have said outside of OpenStack rather than external
18:38:43 <xgerman> Yep
18:39:04 <sc68cal> mickeys: gotcha - well if it's outside of openstack then it couldn't be a firewall group
18:39:12 <sc68cal> they'd most likely use ip prefix
18:39:14 <mickeys> If I want to allow traffic from some firewall group to a set of outside address prefixes, for exapmle
18:39:41 <mickeys> So we have to allow source and destination to use different constructs
18:39:51 <sc68cal> right - and I think we're all on board with that
18:40:02 <jwarendt> +1
18:40:08 <Aish> +1
18:40:18 <xgerman> +1
18:40:56 <sc68cal> so I mean that's the only two little things - if we just update the spec to reflect that, I'm ready to +2 it
18:41:38 * sc68cal moves the football to the 1 yard line
18:41:44 <SridarK> sc68cal: i just need some time till end of day to run thru
18:41:56 <SridarK> but over all i am fine
18:42:02 <xgerman> sc68cal: any opinion on position - priority
18:42:05 <xgerman> ?
18:42:30 <sc68cal> I haven't really followed it - so if we have consensus on one or the other I'm willing to follow
18:42:39 <sc68cal> is it just semantics, and they do the same thing?
18:42:49 <SridarK> xgerman: i am still on position for now - but we can look at if based on bandwidth
18:43:36 <xgerman> Ok.
18:43:38 <mickeys> They achieve the same thing, but the behavior is different
18:44:06 <mickeys> With position, things shift when you insert a rule. There is a specific API to insert a rule before or after another rule.
18:44:20 <mickeys> With priority, you just specify a value. Does not have to be monotonic, there can be gaps.
18:44:28 <mickeys> No insert before or insert after.
18:44:37 <mickeys> No shifting
18:44:55 <SridarK> mickeys: yes agree - more in lines of how much code we need to rewrite for M
18:44:55 <mickeys> Specific priority value is specified in the API
18:45:15 <sc68cal> ok - so based on that, I think I like position.
18:46:04 <sc68cal> I guess my only criticism is that with priority it's an opaque value
18:46:47 <sc68cal> with position, the ordering is a bit more explicit, plus it's one less thing a client has to put in his CLI or API request
18:47:20 <xgerman> Well, position is two things before and after
18:47:26 <sc68cal> since position is set and returned to the user, right SridarK ?
18:47:48 <xgerman> Nope. Position changes when you insert a new rule
18:48:09 <SridarK> position is just set relatively as specified
18:48:15 <sc68cal> xgerman: oh? it gets added at the head of the list, not tail?
18:48:21 <jwarendt> Position doesn't scale or cache or work RESTfully, since based on state of other rules and not self-contained.
18:48:32 <sc68cal> jwarendt: fair point.
18:48:42 <SridarK> jwarendt: agreed on that
18:48:53 <xgerman> +1
18:49:19 <sc68cal> if we go with priority - will it be a required value?
18:49:34 <xgerman> Yep
18:49:38 <sc68cal> or optional/assigned for you if you don't send it in your req
18:50:12 <xgerman> I think we want to be deterministic
18:50:17 <SridarK> sc68cal: that would be tricky
18:50:22 <sc68cal> SridarK: agreed
18:50:42 <xgerman> Required would be best
18:50:48 <mickeys> Some vendors automatically assign, doing +10 with every new rule. It is not easy to explain, or can be a little complex.
18:50:54 <mickeys> In ACLs on routers and switches
18:51:42 <sc68cal> OK - so my thinking is this. If we can, let's try out position - but let's definetly whip up a spec for priority
18:52:29 <sc68cal> since migrating between the two isn't really that big a deal unless I'm mistaken.
18:53:28 <SridarK> sc68cal: i agree on this, it may be a significant change on the rule front
18:53:52 <SridarK> if we can do this great else we get it in N
18:53:52 <sc68cal> priority being a required attribute is sort of a stretch to me, to force a user to pick some arbitrary value
18:54:57 <sc68cal> I
18:55:15 <sc68cal> am not hard core on this, we can always revisit later
18:55:33 <mickeys> +1
18:55:34 <sc68cal> and the migration between would be pretty straight forward from position to priority
18:56:00 <sc68cal> could just take position and multiply by 10 or something to give people space to stick stuff in between
18:56:03 <SridarK> sc68cal: i think we can figure that out with a mapping of position to priority
18:56:11 <SridarK> sc68cal: yes
18:57:13 <xgerman> Well, I think we can do that from the get go but didn't sign up for it so will defer to sc68cal
18:58:43 <mickeys> I think we have another big issue that could use more discussion. The current proposal is that things like IP address, protocol, port are in the API but not in the data model. This means they would get translated to address group and service group in the data model, and when you do a get, you would see the groups. I think if we are going to have individual IP address, protocol, and port, we should put them in the data
18:58:43 <mickeys> model as well. We should remember which one was provisioned and return that in the API when you do a GET.
18:58:53 <mickeys> IMO, it is both easier on the users, seeing the same thing in GET that they put in POST, and I think it is easier to populate the same fields from multiple sources in the plugin than to translate the API into different database objects.
18:59:49 <xgerman> I think having two representations for the same thing is confusing
19:00:13 <xgerman> Also that just complicates the data model
19:00:48 <SridarK> i think we discussed this earlier and thought we would refrain from doing this under the covers
19:02:32 <sc68cal> mickeys: good point
19:02:33 <xgerman> We only agreed that we give them those convenience functions
19:03:25 <mickeys> That was one proposal. I don't think we discussed it enough to reach full consensus.
19:03:56 <xgerman> Well, storing things two ways leads to a mess for little gain
19:04:43 <sc68cal> I think i'm a +1 on mickeys thinking
19:04:43 <mickeys> The place to reduce complexity is the API more than the data model, but we had good reasons for leaving individual IP address as well as address group in the API.
19:05:15 <xgerman> Well, I would kick them out
19:05:52 <jwarendt> I am +1 on mikey's position from a user perspective
19:06:16 <xgerman> So if you specify both it gets confusing
19:06:32 <mickeys> Both in one rule, or different rules?
19:06:45 <mickeys> We said we won't allow both in one rule for source, or both in one rule for destination
19:06:56 <xgerman> Even different rules you need to look in two places
19:06:57 <sc68cal> in one rule, I agree with xgerman. No doing both source_ip_prefix and source_firewall_group in the same rule
19:07:01 <SridarK> one rule is definitely out - we agreed on that
19:07:14 <sc68cal> pick one from the kinds of sources, one from the kinds of desintations
19:07:28 <mickeys> +1
19:07:41 <mickeys> I don't see the problem if some rules use individual IP address while other rules use address group
19:07:47 <sc68cal> but I think to mickeys point - don't munge it in the database. Make sure when we return a rule it's the same fields that they stuck in
19:08:19 <sc68cal> and with the neutron-classifier effort, that's actually pretty easy
19:08:44 <sc68cal> for now we just make the rule database table contain all six fields - but we can slim it down by using classifiers later
19:09:02 <mickeys> We can map to the same thing in the driver before we send RPCs down to the agent
19:09:33 <sc68cal> my thinking is, 6 columns for the src and dst types, but a single row would have just 2 filled in with data, the rest null
19:09:54 <sc68cal> until we swap over to classifiers, so we have less null columns floating around
19:10:04 <sc68cal> in a row
19:10:11 <xgerman> Well, I hate special cases...
19:10:23 <SridarK> i think that would work - so it is either the addr colum or the reference to the address group column
19:11:40 <sc68cal> or the firewall group column
19:11:56 <mickeys> +1
19:12:03 <xgerman> And if I like to add another address to my rule I either have to create a new rule with that up or delete that rule and make a new one with address group
19:12:17 <mickeys> Yes
19:12:22 <sc68cal> xgerman: sounds right
19:12:37 <sc68cal> or update the address group, if your rule pointed to it
19:13:07 <xgerman> Which it won't since we stopped automatic conversion
19:13:26 <xgerman> So like people would add another rule with ip
19:13:29 <mickeys> There are consequences to which representation the user chooses. They are not that bad.
19:13:42 <sc68cal> xgerman: yeah most likely
19:13:57 <sc68cal> mickeys: +1
19:14:11 <sc68cal> I think we've given them plenty of rope to hang themselves with
19:14:13 <sc68cal> :)
19:14:17 <SridarK> :-)
19:14:22 <sc68cal> plenty of yak shaving instruments
19:14:39 <xgerman> That is my concern - so I like to limit choices
19:15:40 <xgerman> But I trust sc68cal that classifieds will solve that :-)
19:15:45 <sc68cal> :)
19:16:42 <mickeys> On that note, the initial implementation will not use sc68cal's classifier proposal for the data model?
19:17:24 <sc68cal> mickeys: it might. but for the time being we just make the database table for a firewall rule map directly to how it looks in the API
19:18:01 <mickeys> sc68cal: OK. I will leave it up to you when you want to introduce the classifier.
19:18:30 <mickeys> Given all the things we have added, the classifier will need to be updated whenever we get to it.
19:18:53 <sc68cal> mickeys: right. I plan on pairing up with Aish on the database work and we'll go from there about using classifier
19:19:03 <xgerman> Cool
19:19:12 <Aish> yup..
19:19:18 <sc68cal> but for the purpose of the spec we can just plan worst case to just make a firewall rule in the DB be exactly like it is in the REST API
19:19:32 <sc68cal> then optimize it when we get to the code
19:19:42 <mickeys> Except for associations instead of lists ...
19:19:50 <sc68cal> mickeys: yep, exactly
19:19:51 <SridarK> sc68cal: +1 for M
19:19:54 <SridarK> mickeys: +1
19:20:25 <SridarK> sc68cal: can we save 5 mins for other discusions
19:20:38 <sc68cal> SridarK: sure. open discussion?
19:20:42 <SridarK> y
19:20:50 <SridarK> mid cycle etc
19:20:59 <sc68cal> any last things about api spec from anyone?
19:21:07 * sc68cal thinks he's shaved his yak down to stubble
19:22:04 <sc68cal> #topic open discussion
19:22:29 <SridarK> xgerman: ur suggestion was to pick a hotel near the airport ?
19:22:35 <SridarK> for the midcycle
19:22:40 <xgerman> Yes
19:23:00 <xgerman> That saves on driving in the morning
19:23:28 <SridarK> ok but is there a shuttle or we need to rent a car in terms of getting to the location
19:23:56 <SridarK> i guess i can look that up too - but if any of u have done this location b4
19:24:07 <xgerman> Most Rent a car but we can carpool
19:24:19 <SridarK> ok sounds good thx xgerman:
19:24:57 <xgerman> I also Once used cabs and Nummer rüdes to The dinner location
19:25:30 <SridarK> ok
19:26:34 <SridarK> Also are folks around next week for the mtg ?
19:27:03 <xgerman> Let's skip the next two
19:27:14 <xgerman> And resume next year
19:27:17 <SridarK> xgerman: +1
19:27:48 * xgerman already on vacation
19:27:51 <SridarK> there is probab quite a few folks off
19:29:08 <sc68cal> sounds good to me
19:30:37 <xgerman> Bye
19:30:53 <xgerman> #endmeeting