18:47:44 <SumitNaiksatam> #startmeeting Networking FWaaS
18:47:45 <openstack> Meeting started Wed Apr 30 18:47:44 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:47:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:47:48 <openstack> The meeting name has been set to 'networking_fwaas'
18:48:06 <SumitNaiksatam> #topic STF patch
18:48:27 <SumitNaiksatam> btw, SridarK garyduan, still here?
18:48:33 <garyduan> yes
18:48:37 <SridarK> SumitNaiksatam: yes here
18:49:16 <SumitNaiksatam> sorry for the delay
18:49:23 <SridarK> no worries
18:49:37 <SumitNaiksatam> garyduan: thanks for taking the effort on the STF patch
18:49:54 <SumitNaiksatam> garyduan: you saw some of the discussions on flavors
18:50:11 <SumitNaiksatam> garyduan: i am hoping that STF will stil be used
18:50:34 <garyduan> SumitNaiksatam: I think it will, right?
18:50:44 <SumitNaiksatam> garyduan: enikanorov_ is proposing that
18:50:46 <garyduan> SumitNaiksatam: eventually need to map to driver
18:50:55 <SumitNaiksatam> garyduan: i am not sure everyone is on board though
18:51:09 <SridarK> i guess only the mapping part will change ?
18:51:16 <SumitNaiksatam> garyduan: if we like that idea we should push for it
18:51:20 <garyduan> SumitNaiksatam: the alternative is everyone write their plugin
18:51:23 <SumitNaiksatam> SridarK: true, some changes
18:51:49 <SumitNaiksatam> garyduan: yeah, that should not be the only option
18:52:02 <SridarK> garyduan: SumitNaiksatam perhaps from a vendor perspective we need to start with writing as a svc plugin
18:52:14 <SridarK> and refactor when this becomes avail ?
18:52:50 <SumitNaiksatam> SridarK: certainly an option, perhaps will illustrate to the community the need for the framework, once they see common code
18:52:51 <enikanorov_> SridarK: that would be quite difficult
18:53:02 <enikanorov_> SridarK: i think you need to target a driver from the beginning
18:53:11 <SumitNaiksatam> but certainly helps vendors to make progress
18:53:25 <SridarK> enikanorov_: agree only on timing of release cycles for products
18:53:45 <enikanorov_> moving from plugin to driver can be difficult
18:53:54 <SumitNaiksatam> enikanorov_: the concern here is that the vendors have not been able to make progress in the entire icehouse cycle
18:53:58 <enikanorov_> as you need to deprecate, change deployment practive, etc
18:54:01 <SridarK> enikanorov_: rather i meant that is the only reason to take that extreme approach
18:54:10 <SumitNaiksatam> enikanorov_: and there is stil no clear path for them in Juno
18:54:59 <SumitNaiksatam> enikanorov_: if there is a way to provide enough evidence that they can get a driver out based on a framework, within Juno, we are forcing them to take this extreme approach
18:55:00 <enikanorov_> SumitNaiksatam: i think that's a management problem. we need to bring those who 'not onboard' to our meetings or to propose alternative approaches
18:55:21 <SumitNaiksatam> enikanorov_: i agree there is a process issue
18:55:47 <enikanorov_> otherwise it all can be unproductive. And i personally think that issue is no big deal from impl perspective
18:55:48 <SumitNaiksatam> we are having meetings in the community including this one
18:55:54 <enikanorov_> but rather important from UX perspective
18:56:14 <SumitNaiksatam> not sure what more to do to get people to participate
18:56:28 <enikanorov_> SumitNaiksatam: yeah, but I noticed that bps are getting reviewed by whole oother group of people :)
18:56:53 <enikanorov_> (then who attend the meetings i mean)
18:57:06 <SumitNaiksatam> enikanorov_: i believe you are saying that those review bps dont attend these meetings
18:57:10 <SumitNaiksatam> enikanorov_: i agree
18:57:15 <enikanorov_> yep
18:57:23 <SridarK> I do hope we can get this adopted and agreed upon even if we start getting it out in phases
18:57:38 <SumitNaiksatam> enikanorov_: i think the people who attend the meetings should commet on the reviews and reference the discussion in the meetings
18:57:48 <SumitNaiksatam> *comment
18:57:51 <SumitNaiksatam> anyway
18:58:02 <SumitNaiksatam> we digressed a bit
18:58:10 <SridarK> sorry
18:58:21 <SumitNaiksatam> enikanorov_: so you plan to bring up the STF tie in as separate bp spec?
18:58:35 <enikanorov_> oh...
18:58:39 <SumitNaiksatam> SridarK: no, not at all
18:59:13 <enikanorov_> i can take it, but i'm not sure i'll have enough bandwidth for this
19:01:38 <SumitNaiksatam> enikanorov_: understandable
19:01:38 <SridarK> SumitNaiksatam: The notion of keeping STF is good - so with garyduan: 's work for fwaas - vendors have something to work against - i think that will be easier to digest
19:01:38 <SumitNaiksatam> SridarK: agree
19:01:38 <enikanorov_> i think basically we need to work with mark macclain to resolve his concerns
19:01:38 <SumitNaiksatam> garyduan SridarK: any chance that you will have the bandwidth to refactor STF?
19:01:38 <SumitNaiksatam> enikanorov_: ok
19:01:39 <garyduan> SumitNaiksatam: no problem
19:01:39 <SridarK> SumitNaiksatam: i can help some - but i may get oversubscribed - we can talk offline
19:01:44 * SumitNaiksatam thinks this is quite a bit of a heavy protocol to have to individually reach out to people
19:01:55 <SumitNaiksatam> garyduan SridarK: good
19:02:08 <SumitNaiksatam> enikanorov_: lets bring this up with the PTL, what say?
19:02:34 <enikanorov_> yes sure
19:03:34 <SumitNaiksatam> #action SumitNaiksatam enikanorov_ to reach out to mestery and mark mcclain to sort out the future of the service provider framework
19:03:49 <mestery> https://wiki.opendaylight.org/images/HostedFiles/Fedora20_ODL_OpenStack.zip
19:05:00 * SumitNaiksatam happy to see mestery participate in some way in FWaaS :-)
19:05:14 <SumitNaiksatam> on next topic
19:05:15 <mestery> SumitNaiksatam: Yes me too!
19:05:31 <SumitNaiksatam> mestery: we wanted to reach out to you regarding the service provider framework
19:05:32 <pcm_> wondering about STF for VPNaaS as well
19:05:38 <SumitNaiksatam> pcm_: good
19:05:54 <SumitNaiksatam> mestery: wondering if this meeting is a good time, or we should send you an meail
19:05:56 <SumitNaiksatam> email
19:06:00 <pcm_> Nachi had a review (and I had client code), but both nixed in icehouse
19:06:05 <mestery> SumitNaiksatam: Lets see what we can cover her
19:06:29 <SumitNaiksatam> the firewall and the VPN vendors are having a really tough time integrating their drivers
19:06:43 <pcm_> Guess we should have a common solution for all services (and maybe push up to common code)?
19:06:56 <pcm_> SumitNaiksatam: yeah, that be me
19:06:57 <SumitNaiksatam> they have tried to use the service time framework (which is now evolving to flavors) before, but their patches are on hold now
19:07:01 <Swami> SumitNaiksatam: yes you are right, we need to have the Framework sorted out for the services.
19:07:12 <SumitNaiksatam> pcm_ Swami: yes
19:07:28 <SumitNaiksatam> mestery:  so while we are making progress with the flavors discussion
19:07:38 <SumitNaiksatam> mestery: how that ties in to the backed provider is not clear
19:07:56 <mestery> SumitNaiksatam: OK. Any plans there or ideas?
19:08:01 <SumitNaiksatam> mestery: enikanorov_ has been suggesting that we reuse the existing service type framework for that
19:08:14 <mestery> That makes some sense. :)
19:08:14 <SumitNaiksatam> mestery: others seem to be in agreement
19:08:33 <SumitNaiksatam> enikanorov_: can you share your thoughts? or what the objections are?
19:08:38 <enikanorov_> mestery: there's however some specifics. right now STF has a bit of public API
19:08:49 <enikanorov_> and that bit is not quite suitable for public clouds
19:09:00 <enikanorov_> so we just remove it in favow of flavor framework
19:09:04 <enikanorov_> *in favor
19:09:23 <enikanorov_> but STF is also a dispatching mechanism from rest calls to vendor drivers
19:09:29 <enikanorov_> that part is really useful
19:10:26 <SumitNaiksatam> enikanorov_: so your proposal is to refactor that part and keep it
19:10:47 <SumitNaiksatam> i also have not see any alterante proposal
19:10:48 <enikanorov_> SumitNaiksatam: exactly
19:11:17 <SridarK> enikanorov_: also if this keeps the plugin - driver i/f reasonably intact except for the provider scheduling aspect - something to start off with
19:11:47 <SumitNaiksatam> mestery: some of the firewall team members participating here and representing vendors are suggesting that they might have to take extreme approach of creating vendor specific service plugins if they dont have a resolution to this
19:12:03 <SumitNaiksatam> mestery: i am guessing this is the same with VPNaaS as well
19:12:11 <mestery> SumitNaiksatam: Understood. So is hte issue we need to get the framework merged soon?
19:12:15 <SridarK> enikanorov_: perhaps "reasonably" is a bit of a stretch but atleast something to start with
19:12:26 <enikanorov_> i think that approach is not good, it will create a lot of contention once API will develop
19:12:48 <enikanorov_> SridarK: it will keep plugin and driver's interface
19:12:54 <SumitNaiksatam> mestery: i believe the issue is that there is some opposition to keeping that part of the STF
19:13:05 <SumitNaiksatam> enikanorov_: i am articulating the issue correctly?
19:13:13 <mestery> SumitNaiksatam enikanorov_: Understood.
19:13:33 <enikanorov_> SumitNaiksatam: as far as i understand, the concern is about user allowed to chose implementation (vendor)
19:13:44 <pcm_> same issue with VPNaaS, currently, no way to support mutiple providers.
19:13:48 <enikanorov_> so it's about implementation typesbeing exposed
19:13:57 <SumitNaiksatam> enikanorov_: but you are addressing that with the flavors framework
19:14:11 <enikanorov_> once we hide it behind flavors - we still can leverage dispatching mechanism of STF
19:14:24 <SumitNaiksatam> enikanorov_: so ideally once that is addressed there should not be an issue with using STF in the backend
19:14:27 <enikanorov_> still can = still should
19:14:35 <enikanorov_> SumitNaiksatam: yes
19:14:42 <SumitNaiksatam> mestery: ok it seems like we need your nod on this
19:14:49 <garyduan> I think it's the most feasible way
19:14:58 <enikanorov_> SumitNaiksatam: so right now i'm suggesting to merge the patch STF+fwaas, removing 'provider' from public API
19:15:10 <SumitNaiksatam> enikanorov_: agree
19:15:18 <enikanorov_> SumitNaiksatam: it's 'noop' from functionality perspective, but a basis for flavors applied to fwaas
19:15:24 <SridarK> this seems like a light at the end of the tunnel :-)
19:15:24 <mestery> SumitNaiksatam: OK, understood. Doing 2 meetings at once now, apologies. :)
19:15:43 <SumitNaiksatam> mestery: no worries, at least you are listening to us :-)
19:15:49 <mestery> :)
19:15:49 <SridarK> mestery: u need to clone urself :-)
19:15:54 <mestery> SridarkK: :P
19:16:02 <SumitNaiksatam> SridarK: :D
19:16:21 <SumitNaiksatam> enikanorov_ garyduan: i think we should push forward with the proposal
19:16:26 <pcm_> So, once flavors is avail, we'll have the selection (UI) component. in the meantime use the same method of selecting (sole) default provider in neutron.conf?
19:16:48 <SumitNaiksatam> pcm_: i would think so
19:17:14 <enikanorov_> pcm_: yes
19:17:31 <pcm_> sounds good to me... hsip it :)
19:17:32 <SridarK> enikanorov_: if this flies then it will be refactoring a STF implementation to flavors
19:17:35 <pcm_> ship
19:17:45 <enikanorov_> SridarK: not exactly
19:17:58 <enikanorov_> SridarK: STF is a bit of different part of mechanism
19:18:04 <SridarK> enikanorov_:
19:18:06 <enikanorov_> STF is about dispatchin rest calls to drivers
19:18:19 <enikanorov_> Flavors is about cheduling service instance to a driver and to a backend
19:18:24 <SridarK> enikanorov_: agree at least better than svc plugin to flavors
19:18:36 <SridarK> enikanorov_: that is what i meant
19:18:41 <enikanorov_> ok
19:19:00 <SumitNaiksatam> enikanorov_: can we have a short write up of how the STF refactoring should happen in your opinion?
19:19:09 <SumitNaiksatam> enikanorov_: i know you are swamped
19:19:17 <SumitNaiksatam> enikanorov_: but we need to be on the same page
19:19:19 <enikanorov_> SumitNaiksatam: yes, will do
19:19:30 <enikanorov_> SumitNaiksatam: should i post it to neutron spec?
19:19:35 <SumitNaiksatam> ok good, enikanorov_ thanks
19:19:39 <SumitNaiksatam> enikanorov_: sure
19:19:42 <enikanorov_> ok
19:19:52 <SumitNaiksatam> we can then decide, who can take that up
19:20:10 <SumitNaiksatam> garyduan: perhaps you can follow up on that
19:20:12 <Swami> enikanorov_: that would be nice
19:20:28 <garyduan> SumitNaiksatam: ok
19:20:34 <SumitNaiksatam> #action enikanorov_ to post STF refactor proposal
19:20:37 <SridarK> enikanorov_: perhaps a few of us can also discuss at some point during the summit
19:20:48 <garyduan> SumitNaiksatam: I will submit the spec to gerrit
19:21:02 <enikanorov_> SridarK: sure
19:21:35 <SumitNaiksatam> SridarK: i would hope we sort this out before the summit
19:21:46 <SumitNaiksatam> that would be ideal :-)
19:21:48 <SridarK> SumitNaiksatam: yes that would be best
19:22:01 <pcm_> +1
19:22:10 <SumitNaiksatam> enikanorov_: thanks much for that
19:22:13 <SumitNaiksatam> mestery: as well
19:22:17 <Swami> sumit: can you include me in any offline discussion
19:22:24 <SumitNaiksatam> Swami: of course
19:22:43 <Swami> SumitNaiksatam: thanks
19:22:57 <SumitNaiksatam> garyduan are you feeling more comfortable now?
19:23:05 <SumitNaiksatam> regarding STF patch that is
19:23:28 <garyduan> SumitNaiksatam: :-)
19:23:36 <SumitNaiksatam> ok moving on
19:23:52 <SumitNaiksatam> #topic Firewall Zones
19:24:08 <SumitNaiksatam> SridarK: can you provide upate?
19:24:15 <SumitNaiksatam> *udpate
19:25:04 <SridarK> some more questions on how we want to model zones - whether as a neutron resource or we can provide this as a list of existing neutron resources (ports etc)
19:25:45 <SridarK> from the service context discussion perhaps as a list seems more in line ?
19:26:54 <SridarK> Also thinking in terms of zones and service context looking at zones as a subset of where the service is inserted
19:27:33 <SumitNaiksatam> SridarK: okay
19:27:42 <SumitNaiksatam> SridarK:  you were working on a document for this
19:27:54 <SridarK> capturing some thoughts for perhaps an internal discussion and the push it up
19:27:56 <SumitNaiksatam> i am still a little bit on the fence
19:27:59 <SridarK> yes
19:28:16 <SumitNaiksatam> it seems like an uphill battle to convince the rest of the community
19:28:29 <SumitNaiksatam> we will do it if it is required
19:28:53 <SumitNaiksatam> but we need to see what our priorities are
19:29:04 <SumitNaiksatam> garyduan: what do you think?
19:29:18 <SumitNaiksatam> SridarK: sorry, commenting without looking at the doc
19:29:22 <garyduan> I think port is fine
19:29:33 <SumitNaiksatam> SridarK: but since you mentioned that there might be an alternative
19:29:34 <SridarK> SumitNaiksatam: are u saying for zones or more in general on services insertion etc
19:29:36 <SumitNaiksatam> garyduan: ok
19:29:39 <garyduan> for edge firewall, this concept still applies
19:29:44 <SumitNaiksatam> SridarK: i meant zones
19:30:07 <SridarK> SumitNaiksatam: no issues - want to have more discussion on this - so that is good
19:30:20 <SumitNaiksatam> garyduan: with the current service insertion suggestion, we might be able to apply the service on a port
19:30:51 <SridarK> SumitNaiksatam: ok - i think we will put in usecases across vendors and customers to what extent can be shared
19:31:05 <garyduan> SumitNaiksatam: yes. that's why i was thinking in that direction too
19:31:28 <SumitNaiksatam> SridarK: ok good, and we can accordingly validate if the current service insertion suggestion help
19:31:32 <SumitNaiksatam> garyduan: ok good
19:31:50 <SridarK> SumitNaiksatam: garyduan: But we will need different FW instances for each zone pair ?
19:31:53 <garyduan> SumitNaiksatam: but I believe there some use cases that the traditonal zone fits better
19:32:20 <beyounn> SumitNaiksatam: just to confirm, when we apply server to ports, there also be direction info, right?
19:32:31 <beyounn> s/server/service/
19:32:43 <SumitNaiksatam> beyounn: good question
19:33:01 <SumitNaiksatam> beyounn: i believe if we have direction notion, then it will satisfy zones requirement?
19:33:14 <SridarK> SumitNaiksatam: i saw direction in latest doc from Kanjie
19:33:28 <beyounn> SumitNaiksatam: that is my feeling
19:33:49 <SumitNaiksatam> SridarK: i am not completely sure about that
19:34:06 <SumitNaiksatam> beyounn: so we have direction in the firewall rules, right?
19:34:23 <SridarK> SumitNaiksatam: ok
19:34:56 <beyounn> SumitNaiksatam: when we want is something like "from zone1 to zone2 match source_address,dest_address,port.. then reject"
19:35:02 <beyounn> s/when/what/
19:35:28 <beyounn> SumitNaiksatam:but from zone2 to zone1 the rule can be different
19:35:34 <SumitNaiksatam> i doubt that service insertion is going to have a directional notion
19:36:01 <SridarK> beyounn: yes
19:36:58 <SumitNaiksatam> i am just trying to look up what is the notion of direction on our firewall rules
19:37:30 <SumitNaiksatam> oh actually we dont have direction
19:37:38 <SumitNaiksatam> we have source and destination
19:37:50 <SridarK> SumitNaiksatam: we only have src , dst
19:38:08 <beyounn> how about we still stick with Zone and build test case around of it and then compare with service insertion to see if it can fit?
19:38:10 <SridarK> we will need to overlay the notion of direction btwn zones
19:38:25 <beyounn> s/test case/use case/
19:38:28 <SumitNaiksatam> beyounn: sure
19:38:38 <SumitNaiksatam> SridarK: you are going to do that?
19:38:48 <SridarK> SumitNaiksatam: yes
19:39:10 <SridarK> SumitNaiksatam: beyounn garyduan: perhaps we can have some offline discussions too
19:39:19 <SumitNaiksatam> SridarK: sure
19:39:21 <beyounn> Sridark:sure
19:39:41 <beyounn> SumitNaiksatam: how was the plan for F2F mgt?
19:39:43 <SumitNaiksatam> #action SridarK to work on draft of zones proposal, focussing on use case
19:39:55 <SumitNaiksatam> beyounn: sure, lets take that offline
19:40:00 <SridarK> perhaps beyounn: & I will run into each other if we are working out side ;-)
19:40:03 <beyounn> SumitNaiksatam:ok
19:40:23 <SumitNaiksatam> SridarK: ah thats what you meant by offline :-)
19:40:24 <beyounn> Sridark: Let have a beer :-)
19:40:40 <beyounn> I have good wine in my home :-)
19:41:14 <SridarK> SumitNaiksatam: thanks - i think some offline brainstorming will help - some dependency on service insertion will also need to be clarified so we can model accordingly
19:41:27 <SridarK> SumitNaiksatam: beyounn; ;-)
19:41:41 <SumitNaiksatam> #topic Service Objects
19:41:54 <SumitNaiksatam> beyounn: we intend to target this for Juno?
19:42:18 <beyounn> SumitNaiksatam:Still, I will write spec
19:42:26 <SumitNaiksatam> beyounn:  ok great
19:42:57 <SumitNaiksatam> #action beyounn to submit gerrit bp spec for Service Objects extension: https://blueprints.launchpad.net/neutron/+spec/fwaas-customized-service
19:43:29 <SumitNaiksatam> #topic Juno priorities and Atlanta design summit session discussion
19:43:59 <SumitNaiksatam> #info design summit session: http://junodesignsummit.sched.org/event/72f3dc6498fa2821fab5f941b9690da9
19:44:14 <SumitNaiksatam> we have a share 40 minute slot with VPNaaS
19:44:26 <SumitNaiksatam> *shared
19:44:32 <SumitNaiksatam> so we will get 20 minutes
19:44:48 <SridarK> SumitNaiksatam: it will be good if we can drive some commonality with VPN on service insertion
19:45:27 <garyduan> Do we plan any other things in FWaaS
19:45:34 <SumitNaiksatam> SridarK: we will discuss service insertion in the advanced services common requirements session
19:45:44 <SridarK> SumitNaiksatam: yes agreed
19:45:47 <SumitNaiksatam> garyduan: everything is up for discussion at this stage
19:45:53 <garyduan> Like logging, app-id etc.
19:45:53 <SumitNaiksatam> including vendor drivers
19:46:07 <SumitNaiksatam> garyduan: do we have the resources to do that?
19:46:14 <beyounn> and address book
19:46:18 <SridarK> SumitNaiksatam: we will have a vendor BP
19:47:10 <SumitNaiksatam> garyduan: since we were blocked in icehouse, i would like be more focussed in juno to push forward
19:47:29 <SumitNaiksatam> *like to
19:47:31 <garyduan> SumitNaiksatam: agreed
19:47:51 <SumitNaiksatam> we need to decide absolutely what we want to get through in Juno
19:47:55 <SumitNaiksatam> please think accordingly
19:48:09 <SumitNaiksatam> we will also be looking for reviewers attention
19:48:31 <SumitNaiksatam> so its not just how fast we can churn patches, we also need reviewers to be able to review them
19:48:59 <garyduan> SumitNaiksatam: that's partly process issue
19:49:17 <SumitNaiksatam> if we put too many things out there at the same time, it dilutes reviewers attention and nothing gets in
19:49:39 <SumitNaiksatam> garyduan: i think process is changing, but its a bit of everything
19:50:03 <SumitNaiksatam> garyduan: so we need to be pragmatic
19:50:16 <garyduan> SumitNaiksatam: I don't think we have time to do those things, but some discuss in F-to-F meeting might be helpful
19:50:26 <SumitNaiksatam> garyduan: you yeah absolutely
19:50:38 <SumitNaiksatam> garyduan: we need to have a long term road map for sure, i think we have had on
19:50:46 <SumitNaiksatam> i am just asking now about Juno
19:51:05 <SumitNaiksatam> what are our absolute priorities
19:51:31 <SumitNaiksatam> i believe the ones we already have in flight (service insertion and STF) are the ones we have already identified
19:51:43 <SridarK> SumitNaiksatam: IMO, zones is important
19:51:54 <SumitNaiksatam> we need to decide besides those what is critical
19:52:20 <garyduan> and beyounn's patch too
19:52:29 <garyduan> to make FWaaS complete
19:52:35 <SumitNaiksatam> garyduan: yeah
19:53:00 <garyduan> not really complete, but cover the basis
19:53:13 <SumitNaiksatam> so i would think that the realistic thing is here to first focus on the patches that we already have in flight
19:53:30 <SumitNaiksatam> we need to file new blueprints for them, and that itself is going to take some more time to converge
19:53:50 <SumitNaiksatam> besides i believe both SridarK  and garyduan have the vendor drivers planned as well, right?
19:54:07 <SridarK> SumitNaiksatam: yes
19:54:27 <garyduan> SumitNaiksatam: yes, in our case, refactor
19:54:38 <SumitNaiksatam> so thats going to be a handful between 3 or 4 people
19:55:07 <SumitNaiksatam> and considering the limited reviewer attention we get
19:56:01 <SumitNaiksatam> i would propose that we focus on these things which are in flight first, and once we the blueprints are re-approved, code patches are resubmitted, we can potentially think of any new features we can try to target for juno
19:56:59 <SumitNaiksatam> we can definitely have discussions on features in longer term road map, but that would be proposed priority - first get our existing patches reviewed and merged
19:57:00 <garyduan> yes
19:57:28 <SridarK> SumitNaiksatam: sure and we can continue more offline discussions too
19:57:29 <SumitNaiksatam> if we can get that far, that will be a huge step forward compared to icehouse :-)
19:57:36 <SumitNaiksatam> SridarK: absolutely
19:58:12 <SumitNaiksatam> ok lets, starting thinking in terms of the couple of topics that we might want to bring up in the summit discussion
19:58:21 <SumitNaiksatam> we also need to create an etherpad
19:58:36 <SumitNaiksatam> anyone want to do that?
19:58:41 <SumitNaiksatam> or else i can do it
19:58:58 <SridarK> SumitNaiksatam: I can do it
19:59:03 <SumitNaiksatam> SridarK: great
19:59:35 <SumitNaiksatam> #action SridarK to create design summit etherpad
19:59:41 <SumitNaiksatam> alrighty, anything more for now?
20:00:03 <garyduan> no for me
20:00:07 <SumitNaiksatam> its been a long meeting, but i think we at least made progress on the STF discussion
20:00:15 <SridarK> we can figure out more next steps offline then
20:00:25 <SumitNaiksatam> SridarK: yes
20:00:29 <SumitNaiksatam> great, thanks SridarK garyduan beyounn for joining
20:00:35 <SumitNaiksatam> bye all!
20:00:39 <garyduan> bye
20:00:45 <SumitNaiksatam> Swami: as well
20:00:49 <SridarK> Thanks and bye all
20:00:53 <SumitNaiksatam> #endmeeting