18:29:29 <sc68cal> #startmeeting networking_fwaas
18:29:30 <openstack> Meeting started Wed Nov 18 18:29:29 2015 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:29:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:29:34 <openstack> The meeting name has been set to 'networking_fwaas'
18:30:06 <vishwanathj> hi
18:30:07 <sc68cal> Unless there are any objections i'd like to dedicate the whole hour to just discussing the new api spec
18:30:13 <SridarK> +1
18:30:18 <mickeys> +1
18:30:22 <annp> Hi
18:30:29 <bharath> Hi
18:30:36 <xgerman> hi
18:30:53 <badveli> hello all
18:31:10 <sc68cal> #topic API spec review - https://review.openstack.org/243873
18:31:17 <jwarendt> hi
18:31:19 <madhu_ak> hi
18:31:31 <xgerman> yeah, I like us to get that approved right after Thanksgiving
18:31:43 <xgerman> aka M1
18:32:10 <sc68cal> xgerman: ack. the latest revision has me hopeful
18:32:20 <xgerman> me, too
18:32:22 <xgerman> :-)
18:32:39 <SridarK> yes i think we are fairly close too
18:32:40 <s3wong> hello
18:32:45 <mickeys> What do we intend for scope of the spec. Just defining the API? Or going into backend reference implementation as well?
18:32:52 <sc68cal> mickeys: just the API.
18:32:56 <xgerman> +1
18:33:06 <badveli> i had some questions on the common backend which i will point out in spec
18:33:18 <sc68cal> badveli: no do not talk about backends in the spec please
18:33:19 <xgerman> well, that doesn’t matter on the API
18:33:42 <SridarK> so for the referennce implementation - we can create another one going off this as the master spec
18:33:51 <badveli> but i am not very clear on how we are going to incorporate
18:34:01 <badveli> ok thanks we will take it in another spec
18:34:34 <xgerman> sc68cal we should alo talk midcycle
18:34:45 <xgerman> after the API discussion
18:35:10 <sc68cal> xgerman: good point, 15 minutes enough?
18:35:14 <xgerman> yep
18:35:21 <xgerman> likely less
18:35:48 <xgerman> so back to API
18:36:24 * sc68cal opens up gertty
18:37:00 <badveli> i am thankful for incorporating the service group and firewall group's
18:37:29 <xgerman> how is tuff called? accept, reject, deny — or drop?
18:37:34 <sc68cal> the issue is there does not seem to be a way to actually add ports to a policy
18:37:52 <sc68cal> err
18:37:53 <SridarK> I am in the midst of the latest rev - one thought is that given that we are taking the reference impl out of this discussion - what we are going after is the final form ?
18:37:59 <sc68cal> firewall gropu
18:38:00 <sc68cal> *group
18:38:30 <xgerman> SridarK we should be able to start implementing a stubbed API server
18:38:32 <badveli> yes looked to me it is a consturct to group address
18:38:34 <xgerman> or extension
18:38:41 <mickeys> Through firewall group port association. Everything is CRU.
18:38:49 <badveli> firewall groups to be a construct to group address
18:38:59 <sc68cal> mickeys: right - but how is a association created via the API?
18:39:13 <xgerman> those class are missing
18:39:17 <mickeys> When I wrote things up in the etherpad, I was thinking of all the tables as API
18:39:32 <mickeys> I was not thinking that some are data model and others are API
18:39:50 <xgerman> well, we need to spec out the calls like we did for the rest
18:39:54 <mickeys> Aish: xgerman: What was the thought behind calling some data model?
18:40:30 <xgerman> yeah, we probably need to specify our tables somewhere
18:40:38 <SridarK> i think so too adding the CRU on an attribute should cover that
18:40:57 <sc68cal> My suggestion - perhaps add an attribute to the firewall group REST API resource - ports?
18:41:39 <mickeys> I think of the Firewall group attributes table and firewall group port association tables as the JSON body of REST APIs
18:42:07 <xgerman> mickeys, part of the spec are some example calls so we should do the same for the new constrcuts
18:42:16 <xgerman> and base it on those tables
18:42:42 <xgerman> otherwise we are inconsistent
18:42:43 <mickeys> Agreed. We need to define endpoints/URIs and give examples
18:42:59 <sc68cal> we're worse than inconsistent - we leave it undefined.
18:43:12 <SridarK> sc68cal: i think u are asking for something along the lines for policies etc that are shown
18:43:41 <sc68cal> SridarK: right - that will help, but we also need to show how someone would associate a port to a firewall group
18:43:47 <sc68cal> via the REST API
18:44:14 <SridarK> sc68cal: ok i get it makes it more clear for sure
18:45:47 <sc68cal> don't forget - this API spec will be around for a loooooong time, people will be using it to figure out how to implement
18:46:01 <badveli> yes looked from the firewall groups it looked like more address groups but not sure how they are applied ports
18:46:38 <mickeys> Firewall groups are primarily a collection of ports. Firewall group port association table is how you apply to ports.
18:47:13 <mickeys> Whether addresses should be in firewall groups in addition to ports, or have a separate address group is an open issue. Right now there is a separate address group. We need to decide this soon, preferrably now.
18:48:11 <SridarK> mickeys: my sense is that it would be simpler to keep them separate and the validation around this will be simpler
18:48:54 <sc68cal> mickeys: firewall group port association table is how we *store*
18:49:03 <badveli> thanks mickey i am trying to understand how is the firewall group port association table populated
18:49:09 <sc68cal> mickeys: it does not specify how a user actually sends an API request to get it to store
18:49:24 <sc68cal> and how it's formatted/structured/expressed
18:50:28 <xgerman> yep, that’s the gap we need to close with the next respin
18:51:21 <mickeys> Original preference was extension to port table, so that it could be defined when a port is created, but that was seen as potentially controversial. So we talked about specifying it in FWaaS tables. The question is whether there is a list of ports in the firewall group table, or a separate URI just for the firewall group port association
18:51:41 <sc68cal> mickeys: you're still thinking database tables though
18:52:13 <mickeys> Firewall group must be its own endpoint/URI, with the attributes specified in the table
18:52:28 <sc68cal> as a consumer of this API, what URI, what kind of JSON do I send to get Port AAAAA associated with firewall group BBBBB ?
18:52:48 <mickeys> Agreed that we need to specify this.
18:53:13 <sc68cal> I'm in agreement with the database model side, we're good there.
18:53:15 <mickeys> Aish: xgerman: You added the firewall group port table. Are you thinking separate URI?
18:53:55 <xgerman> nope, I think we mixed data model and REST calls
18:54:10 <jwarendt> Usually there is an encoded URI association ../firewall/<id>/ports/... at the REST level, or separate resources with URI/ID links.  Need REST api first - db is implementation.
18:54:31 <sc68cal> jwarendt: +1
18:54:44 <mickeys> So add a list of ports as an attribute to the firewall group URI when we add that?
18:54:48 <jwarendt> Though ultimately need: 1) plugin interface 2) driver interface 3) db layer to go along with REST.
18:55:16 <sc68cal> mickeys: that sounds reasonable to me
18:55:16 <xgerman> 2) I think we have more than one driver interface for different aspects
18:55:26 <xgerman> sc68cal +!
18:55:28 <xgerman> +1
18:56:11 <xgerman> yeah, one of the aims of the new API is to not make it more difficult for the user. So he does;t have to create 10 things to get a firewall...
18:57:12 <sc68cal> we're very close - I can feel it
18:57:28 <xgerman> +1
18:57:43 <mickeys> Do we want to mention the port extension as well, and note that it may come later? The rationale for the port extension is that the person creating the port can adjust associated firewall groups as they are creating the port. I doubt an application deployer is going to mess with FWaaS.
18:58:04 <sc68cal> I'd rather not
18:58:05 <mickeys> There was some concern about the difficulty in adding things to the port table
18:58:26 <xgerman> well, as soon as you do something for all of Neutron velocity dies
18:58:28 <SridarK> so the fw group is the binding point of the policy and where it is applied - from a db perspective the association to ports can be a separate table
18:59:14 <xgerman> yep, and that keeps us adding things to the port table of the critical path
18:59:19 <SridarK> agree on the port extension - let that come later
19:00:20 <s3wong> mickeys: wouldn't the sequence of event being user creating port, and associate the port with a FW group? Why would a FW group already been associated with a port being created?
19:00:56 <SridarK> s3wong: the vm port case
19:01:01 <sc68cal> ^ this
19:01:11 <xgerman> s3wong we like the concept of a default firewall
19:01:11 <sc68cal> associate a new vm port to an existing policy
19:01:17 <mickeys> s3wong: That is the issue. By the time there is a VM port for us to associate / put in the list in the firewall group, the VM port is already active
19:01:23 <sc68cal> s/policy/firewall group/
19:01:29 <mickeys> So, the default firewall group would apply temporarily
19:01:46 <xgerman> and then the user can change it to his likings
19:02:09 <xgerman> in the future you might be able to specify a firewall group on nova create
19:02:29 <SridarK> xgerman: thats vision :-)
19:02:42 <xgerman> yep, I should have said far future
19:02:48 <SridarK> :-)
19:03:08 <s3wong> xgerman: not a bad vision
19:03:21 <sc68cal> Do we have a good description of what service_group attribute of a firewall rule is?
19:03:21 <SridarK> +1
19:03:30 <mickeys> As far as document structure, I think the firewall group attributes should be moved to the API section, with the addition of a port list. We then need to figure out where to put the data model section, including the firewall group port association table
19:04:20 <xgerman> agreed, I think their is a data model impact in the spec teamplate
19:04:44 <badveli> sc68cal: the service group UUID can be referred by firewall, we had it in the service group spec
19:04:51 <mickeys> sc68cal: For service group, the question is how we can reference it as an important part of the API, but specify it outside in a separate spec
19:05:30 <sc68cal> mickeys: badveli: ok - but what does it *do* ?
19:05:30 <mickeys> Is it OK to leave it in the attributes table and refer to another spec?
19:05:45 <badveli> mickeys: i think that is fine
19:05:48 <xgerman> I think this is what we have to do
19:06:00 <SridarK> mickeys: yes i think we can point to badveli's spec
19:06:08 <badveli> we can reference it
19:06:15 <mickeys> A group of objects, each with protocol, source L4 port range, dest L4 port range. In the future, L7 objects such as application ID.
19:06:17 <SridarK> and leave it as something that is being explored for the future
19:06:35 <xgerman> (and might become some classifier)\
19:07:01 <badveli> sc68cal: the service group spec clearly mentions the functionality i did not add L7 objects as of now
19:07:04 <mickeys> The thought is, for a particular application, there will be certain protocol/L4port combinations that you will want enabled. Once someone specifies the service group for that application, you can reuse that over and over again, wherever that application is deployed.
19:07:32 <sc68cal> so basically a classifier
19:07:38 <mickeys> Exchange, SAP, etc
19:07:42 <sc68cal> or multiple classifiers
19:07:49 <mickeys> Not a full classifier. Nothing to do with addresses or identity.
19:08:04 <sc68cal> classifier doesn't have to require addresses
19:08:08 <s3wong> list of application classifiers
19:08:12 <xgerman> yeah, so I think keeping that out of the API spec gives us some flexibility later
19:08:26 <mickeys> Say if I want to use exchange or SAP or FTP ...
19:08:28 <sc68cal> and I'd like to remove the attribute from the API for now
19:08:41 <sc68cal> we can add it back in once we have something more concrete
19:09:11 <xgerman> mmh, we have the service group so it shouldn’t matter if they are done with classifiers or not
19:09:17 <xgerman> matter to the API
19:09:30 <sc68cal> we're already making a big hunk of work by having address groups
19:09:36 <badveli> sc68cal: should we have it there , i am pretty sure this will decouple the notion of service from the firewall
19:10:02 <sc68cal> as well as firewall gruops
19:11:01 <sc68cal> SridarK: what are your thoughts
19:11:03 <SridarK> sc68cal: yes i have some concerns on actually what we will implement - but if we keep this spec as the end goal and we call out implementation for M outside of this
19:11:11 <SridarK> sc68cal: u read my mind
19:11:32 <SridarK> sorry straddling mtgs
19:12:02 <xgerman> yeah, I think we should spec out what we want and then figure out the implementation strategy later
19:12:17 <sc68cal> Ok. let me noodle on it a bit more - I think if we make it more clear what it will do - API interaction wise, i'll be more happy with leaving it in
19:12:47 <sc68cal> and let me re-read badveli 's spec - the link to it might satisfy me
19:13:00 <badveli> sc68cal: let me know if you have questions
19:13:02 <badveli> thanks
19:13:05 <mickeys> I am unclear where are ending up. Leave service group as is, but clarify the reference? Define it completely in the spec? Take it out?
19:13:19 <sc68cal> mickeys: leave it in, and give me a link over to badveli's spec in the notes
19:13:29 <badveli> +1
19:13:36 <xgerman> understood
19:13:41 <mickeys> Reference the Kilo version?
19:13:49 <mickeys> badveli: Any plans to resubmit for Mitaka?
19:14:01 <badveli> yes i am doing it
19:14:05 <sc68cal> I think this will work - if this is the most up to date - http://specs.openstack.org/openstack/neutron-specs/specs/juno/service-group
19:14:21 <xgerman> yeah, specs usually just roll forward...
19:14:21 <mickeys> There is a kilo spec
19:14:30 <badveli> https://review.openstack.org/#/c/131596
19:14:35 <SridarK> i think we can use the kilo spec
19:14:53 <SridarK> badveli: u will need to clean this up and resubmit ?
19:15:02 <sc68cal> ok then use http://specs.openstack.org/openstack/neutron-specs/specs/kilo/service-group.html
19:15:15 <xgerman> yep
19:15:18 <badveli> yes, should we add the notion of L7
19:15:19 <mickeys> +1
19:15:23 <mickeys> Not yet
19:16:29 <badveli> will it be ok to resubmitt before our API spec gets approved?
19:16:59 <sc68cal> let's use a HTTP link to the rendered HTML - if your spec gets approved for mitaka we can always update the link
19:17:08 <sc68cal> to point to the new URL
19:17:46 <sc68cal> from the firewall side there isn't any difference - since we're just storing a UUID
19:17:54 <xgerman> +@
19:17:56 <xgerman> +1
19:18:18 <mickeys> +1
19:18:21 <badveli> ok thanks.
19:18:22 <SridarK> yes it is a resource we refer to
19:18:23 <sc68cal> ok, we've got about 10 minutes left - xgerman - midcycle?
19:18:26 <SridarK> so +1
19:18:36 <xgerman> #topic midcycle
19:18:43 <sc68cal> sorry I didn't add you as chair
19:18:44 <sc68cal> #topic midcycle
19:18:48 <xgerman> #link https://etherpad.openstack.org/p/lbaas-mitaka-midcycle
19:18:59 <xgerman> so dougwig likes to colocate with LBaaS
19:19:15 <xgerman> they picked 1/13-1/16 as potential dates
19:19:29 <xgerman> would they work for you guys?
19:19:43 * sc68cal checks
19:19:46 <s3wong> 1/16 is a Saturday?
19:19:51 <xgerman> really?
19:20:21 <s3wong> yep
19:20:41 <sc68cal> so 1/12 to 1/15?
19:20:50 <xgerman> would be fine by me
19:21:12 <sc68cal> works for me too
19:21:14 <jwarendt> works
19:21:19 <xgerman> awesome
19:21:27 <mickeys> No conflicts for me
19:21:30 <sc68cal> is the Idaho option - dougwig 's house?
19:21:45 <xgerman> might be some hunting cottage
19:21:59 <mickeys> Idaho in January? That wouldn't be Sun Valley, would it? :-)
19:22:15 <sc68cal> what's seattle like in jan?
19:22:16 <SridarK> Brr!!
19:22:21 <xgerman> nope, I think Seattle and San Antonio are more realistic  options
19:22:33 <SridarK> +1
19:22:46 <sc68cal> lol "somewhere new" crossed out
19:22:54 <s3wong> like any other months, raining :-)
19:23:45 <sc68cal> I think whichever is easiest to organize and host
19:24:07 <sc68cal> san antonio weather probably is better than SEA, but i'm not picky
19:24:26 <xgerman> yeah, big concern from Doug is that we go to Seattle each time but...
19:24:32 * sc68cal sneaks over to mountains to snowboard after midcycle
19:24:57 <SridarK> i always welcome u too the bay area
19:25:08 <jwarendt> xgerman cannot fit  us all in San Diego unfortunately if chasing good weather.
19:25:26 <s3wong> sunny California!
19:25:43 <xgerman> I can probably work something out but there are also budgetary constraints
19:26:22 <vishwanathj> Which company will host in San Antonio, will that be rackspace?
19:26:31 <xgerman> yep
19:26:57 <xgerman> there is a lot of travel budget thinling behind locations
19:28:28 <xgerman> ok, I guess we are good
19:28:34 <xgerman> please vote on location
19:29:12 <xgerman> and I think we are done for today ;-)
19:29:23 <vishwanathj> bye all
19:29:23 <sc68cal> yup
19:29:26 <sc68cal> bye all
19:29:27 <SridarK> bye all
19:29:27 <vichoward_> o/
19:29:29 <mickeys> bye
19:29:31 <sc68cal> #endmeeting