18:03:10 <SumitNaiksatam> #startmeeting Networking Advanced Services
18:03:10 <openstack> Meeting started Thu Mar 13 18:03:10 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:03:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:03:14 <openstack> The meeting name has been set to 'networking_advanced_services'
18:03:44 <SumitNaiksatam> I was pinged by a lot of folks during the past few days about the status of the general services' framework
18:04:01 <SumitNaiksatam> and what went into Icehouse, and what remains to be done
18:04:25 <SumitNaiksatam> hence I though it would be good for the various services' team to converge here
18:04:46 <SumitNaiksatam> we used to have this meeting before but we suspended it to support more pressing issues facing Neutron
18:05:04 <SumitNaiksatam> unfortunately we did not get much into Icehouse in terms of the services' framework
18:05:26 <SumitNaiksatam> moreover we are also reconsidering some of the existing abstractions - namely service-types
18:05:32 <SumitNaiksatam> lets get started with that
18:05:39 <SumitNaiksatam> #topic Flavors Framework
18:05:49 <SumitNaiksatam> #link https://wiki.openstack.org/wiki/Neutron/FlavorFramework
18:06:15 <SumitNaiksatam> enikanorov_: put out the wiki and started a thread on the mailing list as well
18:06:42 <s3wong> SumitNaiksatam: quickly skim through it this morning, it seems very abstract. It only adds a flavor type on top of existing service type and provider driver
18:06:55 <SumitNaiksatam> s3wong: okay
18:06:59 <enikanorov_> s3wong: correct
18:07:06 <SumitNaiksatam> so i see the following points that we probably need to consider (and then i will yield to enikanorov_)
18:07:18 <enikanorov_> the idea is to choose provider based on service capabilities requirested by the user
18:07:23 <SumitNaiksatam> 1. the framework has to have generic application to Neutron services
18:07:42 <SumitNaiksatam> 2. it should provide for representation of different “flavors” of the same service
18:08:02 <SumitNaiksatam> 3. in terms of service matching we need to decide desire versus exact match semantics
18:08:19 <SumitNaiksatam> 4. and the name :-) ( we can punt this to the mailer)
18:08:38 <SumitNaiksatam> enikanorov_: is that reasonable characterization of the discussion till date?
18:08:47 <enikanorov_> yes, pretty much!
18:08:48 <pcm_> enikanorov_: would like to hear more about how the flavor translate to a specific driver instance... fuzzy to me
18:09:09 <hemanthravi> does it allow for def of a new type of service along with associated params?
18:09:20 <pcm_> maybe some concrete examples would help me (I'm dense :)
18:09:33 <enikanorov_> pcm: the flavor represends requirements (capabilities) that user wants from the service. some drivers support some caps, others don't
18:09:57 <enikanorov_> how capabilities are represented is yet to be defined
18:10:25 <enikanorov_> initially I proposed quite free form of definition like {'parameter': allowed_values (or range)}
18:10:33 <pcm_> enikanorov_: so, say for VPN, where may have multiple drivers that can all meet the need, how does one select a specific driver?
18:10:36 <enikanorov_> as an alternative, flavor could be a set of tags
18:10:56 <enikanorov_> pcm_: via scheduling, it can be random, it can consider available appliances
18:11:06 <enikanorov_> that is yet to be decided
18:11:34 <enikanorov_> the proposal is that scheduler asks drivers for resources that match the flavor
18:11:40 <s3wong> pcm_ : good point. Since the intention is to hide vendor name, that selection is very unpredictable
18:11:45 <enikanorov_> and then choses the backedn depending on scheduling algorithm
18:12:18 <SumitNaiksatam> enikanorov_: on the representation of capabilities, the base set of attributes can be abstract with the possibility to extend to specifics
18:12:19 <SridarK> enikanorov_:  There could be a use case where one might want to pick a specific vendor implementation as perhaps this has been validated earlier
18:12:30 <SridarK> should this be considered ?
18:12:37 <SumitNaiksatam> SridarK: my point ^^^
18:12:51 <enikanorov_> SumitNaiksatam: to me it should be a part of Admin API, where admin can create flavors in relatively free form
18:13:00 <SumitNaiksatam> incorporate base set of abstract attributes
18:13:03 <SumitNaiksatam> enikanorov_: yes
18:13:15 <enikanorov_> SumitNaiksatam: but also we need to be bw compatible, so I'm thinking about some default flavors, that drivers can export
18:13:24 <SumitNaiksatam> and then allow for free form attributes as well, in case the admin wants to expose
18:13:30 <s3wong> enikanorov_: admin can then specify vendor name into the available flavors then?
18:13:41 <SumitNaiksatam> enikanorov_: yes, defaults can make it backward compatible
18:13:42 <enikanorov_> SridarK: I think in this case that could be solved by the flavor that will be provider-specific
18:14:07 <SridarK> ok would we get into a proliferation of flavors
18:14:17 <enikanorov_> s3wong: yes, like that, add 'provider' parameter to a flavor and it will map to a specific provider, for instance
18:14:24 <banix> s3wong: that sounds like a reasonable option
18:14:42 <pcm_> +1 ^^
18:14:48 <SridarK> s3wong: +1
18:14:52 <enikanorov_> flavor workflow should definitely allow what is allowed with provider workflow
18:15:06 <s3wong> yes, so now flavor definition is an provider API, and selection API is tenant API?
18:15:15 <SumitNaiksatam> enikanorov_: to pcm_'s question we can also don't have to have exact match semantics
18:15:34 <enikanorov_> yes, selection is tenant API
18:15:38 <SumitNaiksatam> s3wong: i believe so
18:15:48 <enikanorov_> SumitNaiksatam: of course
18:16:00 <SumitNaiksatam> enikanorov_: ok good we are on the same page
18:16:07 <banix> Similar to nova flavors I suppose
18:16:18 <SumitNaiksatam> folks, lets have some structure to the conversation here
18:16:25 <SumitNaiksatam> i think we are talking over each other
18:16:38 <SumitNaiksatam> this is a long topic of discussion, so we are not going to resolve things here
18:16:58 <SumitNaiksatam> we want to get the discussion started and get people thinking so that they can provide feedback
18:17:05 <SumitNaiksatam> ok so who's next?
18:17:27 * pcm_ takes one step back :)
18:17:51 <SumitNaiksatam> pcm_: i was going to say you asked the first question :-)
18:17:58 <SumitNaiksatam> pcm_: so far good?
18:18:02 <pcm_> yes
18:18:07 <enikanorov_> so the question I have
18:18:13 <SumitNaiksatam> ok hemanthravi next
18:18:24 <enikanorov_> is about patches that integrate fwaas/vpn/l3 with provider framework
18:18:25 <SumitNaiksatam> enikanorov_: sorry go ahead
18:18:39 <SumitNaiksatam> enikanorov_: i don't think there is a plan to integrate those
18:18:40 <hemanthravi> was asking if flavors allows for a new type of service to be defined
18:18:51 <enikanorov_> i think that those patches make sense even if we agree on flavors
18:18:57 <enikanorov_> but with the exception
18:19:09 <SumitNaiksatam> enikanorov_: the service type framework patches are on hold
18:19:10 <enikanorov_> that provider should be exposet into the tenant API
18:19:17 <enikanorov_> but rather be a read-only attribute
18:19:23 <SumitNaiksatam> enikanorov_: ok, makes sense to me
18:19:49 <enikanorov_> because it seems that we're still going to have mapping between resource and the driver
18:19:52 <s3wong> enikanorov_: sounds good
18:19:58 <enikanorov_> even if we have flavors
18:20:03 <pcm_> enikanorov_: So set provider via flavor attriobute and allow showing through provider framework?
18:20:09 <SumitNaiksatam> enikanorov_: i think if we can explain how the new abstraction (if we call it flavors), incorporates the provider, that will be helpful
18:20:17 <mandeep> enikanorov_: SumitNaiksatam: There are similar needs in the group policy framework. And they too are creating artifacts for publishing and consuming services and having best match semantics. At appropriate time, should consider that as an alternative as well
18:20:17 <enikanorov_> flavor is a scheduling hint where provider is dispatching hint
18:20:29 <SumitNaiksatam> mandeep: sure
18:20:30 <SridarK> enikanorov_: could u pls clarify on the read only for tenant - meaning tenant cannot set a provider ?
18:20:48 <enikanorov_> SridarK: yes, tenant can't set the provider - that's an idea of flavor framework
18:21:02 <SridarK> that is fine thanks enikanorov_:
18:21:05 <enikanorov_> but we still need to bind resource to a provider, but not manually
18:21:11 <s3wong> SridaK: one would imagine tenant can select from available options, but not creating one
18:21:46 <SridarK> s3wong: Yes agreed
18:21:55 <banix> SumitNaiksatam: Can you elaborate why service type patches  are on hold? just not enough time for review?
18:22:18 <pcm_> banix: no, pending flavor discussion
18:22:25 <SumitNaiksatam> banix: ostensibly because we are rethinking the service type framework
18:22:49 <SumitNaiksatam> enikanorov_: hemanthravi's question was - "was asking if flavors allows for a new type of service to be defined"
18:23:08 <SumitNaiksatam> hemanthravi: i believe the answer is yes
18:23:08 <banix> and that is to generalize the framework, provide features such as not exact matches, etc
18:23:14 <enikanorov_> not sure i get the question :)
18:23:28 <mandeep> enikanorov_: At least in the policy framework discussion, it allows for both specific provider, or for it to be satisfied by "best match"
18:23:31 <hemanthravi> for eg a service other than FW, VPN
18:23:31 <enikanorov_> mainly because 'type of service' is a broad term
18:23:35 <SumitNaiksatam> enikanorov_: so that question is applicable to service chains as well
18:23:53 <SumitNaiksatam> enikanorov_: what if we want to expose a service chaing via the flavors framework
18:24:01 <SumitNaiksatam> enikanorov_: this was the earlier plan with STF
18:24:11 <enikanorov_> SumitNaiksatam: i think that's where tag representation of capabilities can help
18:24:15 <SumitNaiksatam> *chain
18:24:15 <s3wong> SumitNaiksatam: hemanthravi: the available service type in a flavor needs to be submitted via bp, I suppose. Instead of relying on flavor framework to allow everyone to freely add service type
18:24:17 <mandeep> SumitNaiksatam: This _should_ apply to service chains as well. A service chain is yet another service
18:24:44 <enikanorov_> you specify flavor={'type': 'chain_vpn_lbaas'} - something like that
18:24:46 <SumitNaiksatam> mandeep: thats what i would think
18:24:52 <enikanorov_> (primitive example)
18:24:52 <banix> s3wong: that won't work that nicely for service chains
18:25:22 <s3wong> banix: true, since those are dynamically created by tenants
18:25:22 <SumitNaiksatam> enikanorov_: yeah something like that
18:25:24 <enikanorov_> also, i'm not sure about ' freely add service type'
18:25:40 <enikanorov_> in my understanding 'service type' is something that has code implementation
18:25:41 <banix> but I see discussion on limiting the capability for having arbitrarily constructed chains
18:25:45 <enikanorov_> like now we have service plugins
18:25:56 <SridarK> SumitNaiksatam: we will need to have a "set" of service drivers for each element in the chain
18:25:57 <enikanorov_> so it's not something that admin or tenant defines
18:26:32 <SumitNaiksatam> banix s3wong enikanorov_ so i think the point here is that this deployment specific
18:26:32 <s3wong> enikanorov_: I guess the question is - should a service chain, defined by tenant, be a "service type"?
18:26:58 <enikanorov_> s3wong: i think you're talking about chain implementation
18:26:59 <SumitNaiksatam> s3wong: the service chain is not necessarily a dynamic construct
18:27:05 <enikanorov_> i think tenant can't specify chain template
18:27:06 <prasadv> enikanorov_: since the framework is matching, it can match the service type to the driver by querying isnt it?
18:27:20 <banix> enikanorov: and having a service type of type chain does not make sense? Just wondering if that could be an option
18:27:36 <SumitNaiksatam> s3wong: the particular deployment/provider has to support the service chain, and it will expose only those that it supports
18:27:56 <enikanorov_> banix: 'chain' is too abstract. FW_lbaas_chain makes sense
18:28:04 <enikanorov_> or other concrete chains
18:28:08 <SumitNaiksatam> enikanorov_: yes
18:28:08 <enikanorov_> but those are static
18:28:12 <enikanorov_> that's how i see it
18:28:19 <SumitNaiksatam> enikanorov_: that has been our approach all along
18:28:23 <enikanorov_> static - means we, developers, define them
18:28:33 <s3wong> SumitNaiksatam: in that case, the provider for such chain that provider can support has multiple drivers?
18:28:37 <enikanorov_> SumitNaiksatam: yep
18:28:59 <SumitNaiksatam> s3wong: could have multiple drivers
18:29:07 <SumitNaiksatam> s3wong: they will probably be different chains
18:29:22 <SumitNaiksatam> s3wong: i can see that you are probably seeing an issue with combinatorial explosion
18:29:29 <SumitNaiksatam> s3wong:  however in reality that might not be the case
18:29:35 <s3wong> SumitNaiksatam: absolutely
18:29:41 <banix> I may be thinking too broadly for an implementation, but that sounds like a big limitation. But I have seen earlier discussion on this and see the thoughts on this issue.
18:30:11 <banix> SumitNaiksatam: yes
18:30:19 <pcm_> so the chain is specific to the provider right?
18:30:28 <SumitNaiksatam> pcm_: yes
18:30:44 <SumitNaiksatam> s3wong banix: so essentially you are expressing the need to chains created by users?
18:31:06 <SumitNaiksatam> * need to create chains
18:31:18 <s3wong> SumitNaiksatam: it is extremely limiting is a tenant cannot choose to chain together available services provided by provider
18:31:26 <s3wong> s/is/if
18:31:33 <SumitNaiksatam> s3wong: ok
18:31:38 <SumitNaiksatam> so we are half way into the meeting
18:31:38 <pcm_> Would it be the case that the chain would always relate to one provider, or could we cross providers (does that even make sense)?
18:31:56 <SumitNaiksatam> i think this is a nice segue into the next part of the agenda
18:31:59 <banix> SumitNaiksatam: Yes, and the ability to compose chains from other services that are defined by the provider
18:32:10 <SumitNaiksatam> #topic Service insertion/chaining
18:32:33 <s3wong> perfect point to move into the next topic :-)
18:33:01 <banix> to wrap up the previous section, is it fait o say flavors are a generalized form of service types that we are agreeing on working towsrds?
18:33:02 <SumitNaiksatam> btw, we are not done with the flavors discussion, but we have started to bleed into the complementary discussion (so thought we could make progress on the agenda :-))
18:33:14 <SumitNaiksatam> enikanorov_: please stay with us :-)
18:33:24 <SumitNaiksatam> ok so coming back chaining
18:33:28 <enikanorov_> i will, although in read-only mode mostly :)
18:33:43 <SridarK> SumitNaiksatam: in terms of who defines the chain and who defines the provides in the simpler flavor case - seems we are saying diff things
18:33:44 <SumitNaiksatam> first an update
18:33:45 <cgoncalves> SumitNaiksatam: I also share banix's opinion on allowing users to define chains
18:33:51 <SridarK> *provider
18:34:06 <SumitNaiksatam> #link https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
18:34:07 <s3wong> go ahead SumitNaiksatam
18:34:57 <SumitNaiksatam> again due to the resource/time crunch we were left to target only a very tiny part of the above blueprint
18:35:05 <SumitNaiksatam> #link #link https://review.openstack.org/#/c/62599
18:35:20 <SumitNaiksatam> unfortunately, even that did not make it in!
18:35:35 <s3wong> SumitNaiksatam: this is already out for Icehouse, correct?
18:35:37 <SumitNaiksatam> not for lack of effort
18:36:06 <SumitNaiksatam> s3wong: nope, it was not granted FFE
18:36:09 <SumitNaiksatam> anyway
18:36:32 <SumitNaiksatam> so although it was a FWaaS related patch, the idea was to introduce the notion of a service context
18:36:40 <SumitNaiksatam> service context will aid in service insertion
18:37:14 <SumitNaiksatam> the service context can be one or a combination of a number of references to other neutron objects
18:37:19 <SumitNaiksatam> very simple and basic
18:38:07 <cgoncalves> SumitNaiksatam: would it be possible in the defined blueprint to allow vm instances to be part of a chain? use case: DPI is not supported in openstack as a service; one could create a vm instance with a DPI instance (e.g. ntop) and bind it to a chain FWaaS->VM_DPI->LbaaS
18:38:14 <SumitNaiksatam> the hope was that all services would implement the service context, and we could subsequently use it to build service chains
18:38:28 <SumitNaiksatam> cgoncalves: yes
18:38:46 <SumitNaiksatam> cgoncalves: its agnostic to the service implementation
18:39:08 <cgoncalves> SumitNaiksatam: awesome. thanks!
18:39:19 <s3wong> SumitNaiksatam: what is the definition of service context?
18:39:44 <SumitNaiksatam> s3wong: its in the blueprint ;-)
18:40:35 <SumitNaiksatam> s3wong: service_context can be used by the user to convey the intent to the backend as to where to anchor the particular service instance
18:40:42 <banix> Mainly a reference to where a service can be inserted
18:41:07 <SumitNaiksatam> banix: yeah, much more concise :-)
18:41:27 <s3wong> banix: I see. thanks. I also just found it in the document :-)
18:41:35 <SumitNaiksatam> s3wong: make sense?
18:41:47 <s3wong> SumitNaiksatam: yes
18:41:52 <SumitNaiksatam> okay
18:41:59 <SumitNaiksatam> so moving on
18:42:00 <banix> That seems very logical to me but I think there were concerns wrt backward compability
18:42:15 <banix> which as far as I can see are not there
18:42:16 <SumitNaiksatam> banix: actually those were not substantiated
18:42:19 <SumitNaiksatam> banix: yeah
18:42:20 <kathmandude> can there be multiple service instances with different contexts?
18:42:27 <s3wong> SumitNaiksatam: is ports Neutron ports or L4 port number?
18:42:45 <SumitNaiksatam> banix: that was probably lack of understanding, default semantics can make it backward compatible
18:42:54 <banix> yeah
18:42:57 <SumitNaiksatam> s3wong: all neutron constructs, so neutron port
18:43:12 <SumitNaiksatam> kathmandude: yes
18:44:00 <SumitNaiksatam> so perhaps these are too many topics for a short meeting
18:44:19 <banix> So service insertion context allows the insertion to be explicitly defined ….
18:44:36 <SumitNaiksatam> banix: yes, but as supported by the backend provider
18:44:51 <banix> that's right
18:44:53 <SumitNaiksatam> banix: there will be validation, and not all contexts will be valid for a service or deployment
18:45:28 <SumitNaiksatam> so what i was going to say is I think we have planted enough seeds in this discussion, both on the flavors front and the service insertion/chaining
18:45:38 <banix> yes
18:45:43 <SumitNaiksatam> we definitely need more discussion time
18:45:54 <s3wong> SumitNaiksatam: so how to proceed beyond these seeds? :-)
18:45:59 <SumitNaiksatam> i want to give time to pcm_ as well for the next topic
18:46:06 <banix> and probably a timetable for ourselves so we can move things forward
18:46:07 <SumitNaiksatam> s3wong: yes, lets summarize at the end of the meeting
18:46:12 <SumitNaiksatam> banix: yes
18:46:32 <SumitNaiksatam> #topic Vendor plugins for L3 services
18:46:38 <SumitNaiksatam> #link http://lists.openstack.org/pipermail/openstack-dev/2014-February/026193.html
18:46:44 <SumitNaiksatam> pcm_: all yours :-)
18:46:52 <pcm_> thanks
18:47:04 <pcm_> pretty much was thinking about these topics:
18:47:23 <pcm_> 1) how to handle/lcoate vendor config files
18:47:54 <pcm_> 2) way to do vendor validation (e.g. validate, commit, apply ~ to precommit/postcommit)
18:48:07 <pcm_> 3) How to tell client what vendor capabilities are
18:48:20 <pcm_> 4) How to report to plugin status, when there are problems
18:48:52 <pcm_> I've seen a bunch of these issues with VPN development and imagine other svcs do to.
18:49:10 <pcm_> Should we setup a separate IRC to discuss some ideas on this?
18:49:31 * pcm_ primarily wanted to get people thinking about it some
18:50:15 <SridarK> pcm_: we also need the flavor discussion to mature to understand what base we are building on
18:50:32 <pcm_> SridarK: agreed
18:50:45 <s3wong> pcm_: agree with SridaK. Seems like a lot of these should be solved by flavors framework
18:51:18 <pcm_> s3wong: not sure how flavors will handle some of the issues like #2
18:51:44 <s3wong> pcm_: #1 and #3 should
18:51:51 <SridarK> s3wong: pcm_'s intent is more to see how vendors adopt a framework
18:52:01 <pcm_> s3wong: agree
18:52:33 <pcm_> For #2, for example, the plugin for VPN will validate, commit and then call service driver to handle
18:52:49 <pcm_> that, unfortunately is too late for vendor to validate and prevent commit.
18:53:10 <pcm_> would be nice for a common framework that all services use to allow for this.
18:53:40 <pcm_> thinking hooks to pre/post commit actions, like done in ML2/L2 plugins
18:53:44 <banix> similar to ML2 separation for mechanism drivers?
18:53:55 <s3wong> pcm_ : plugin/driver has to be involved for #2, no escape for that one
18:54:05 <mandeep> banix: precisely. It looks like the same problem
18:54:27 <SridarK> pcm_: if SumitNaiksatam: enikanorov_: are okay too - could this be a part of the flavors discussion at least initially
18:54:29 * pcm_ need to read up on ML2 more :)
18:55:00 <SumitNaiksatam> SridarK: not sure i got that
18:55:00 <pcm_> SridarK: sure. There are likely parts that fit in nicely and some that maybe don't.
18:55:10 <SumitNaiksatam> SridarK: but we can follow up
18:55:15 <enikanorov_> that's an interesting point
18:55:35 <SumitNaiksatam> pcm_: sorry to cut you short, since only 5 mins, just want to plan for future meetings as well
18:55:43 <pcm_> sure np
18:55:43 <enikanorov_> basically right now the driver is able to put resource into ERROR state
18:55:44 <SumitNaiksatam> pcm_: we will continue the discussion in this forum
18:55:47 <enikanorov_> that's all it can do
18:55:47 <SridarK> SumitNaiksatam: since the flavors is also evolving - perhaps we need to get that model settled in first
18:55:56 <SumitNaiksatam> SridarK: sure
18:56:07 <SumitNaiksatam> #topic Summary and planning
18:56:15 <s3wong> enikanorov_: seems like we need to extend flavor framework
18:56:35 <enikanorov_> s3wong: how do you see it?
18:56:42 <SumitNaiksatam> so i think there is a lot of discussion needed on a different topics
18:56:56 <SumitNaiksatam> unfortunately time is short and we have too many meetings
18:57:19 <SumitNaiksatam> so how does everyone feel about having this is as a biweekly meeting
18:57:35 <mandeep> And make it 2 hrs ... we need that time
18:57:36 <pcm_> SumitNaiksatam: sure, or weekly...
18:57:36 <enikanorov_> i'm fine with that
18:57:39 <SridarK> SumitNaiksatam:  From the chaos - with folks jumping over one other  (in a good way)  in the mtg -  only reflects the the intense need to solve this problem :-)
18:57:49 <mandeep> (just to get to bottom of some of these discussions)
18:57:49 <enikanorov_> i'm for weekly, but 1 hour long
18:58:09 <banix> weekly seems what we need
18:58:14 <pcm_> enikanorov_: +1 and just limit topic
18:58:15 <s3wong> SumitNaiksatam: would be nice to make it NOT immediately before the group-policy meeting
18:58:18 <SumitNaiksatam> enikanorov_: man deep's suggestion to make to 2 hour but biweekely>
18:58:27 <prasadv> s3wong: +1
18:58:30 <SumitNaiksatam> s3wong: sure
18:58:35 <enikanorov_> 2 hrs is exhausting
18:58:43 <mandeep> OK
18:58:48 <hemanthravi> +1 weekly, 1hr
18:58:52 <SumitNaiksatam> if we keep it to only one topic, other topics will be delayed
18:59:01 <SumitNaiksatam> alright, one hour weekly
18:59:11 <SumitNaiksatam> we can alternate topics
18:59:17 <pcm_> es
18:59:19 <pcm_> yes
18:59:19 <s3wong> move it back to wednesday, perhaps?
18:59:20 <mandeep> That will work too
18:59:21 <SridarK> +1
18:59:28 <SumitNaiksatam> there are other topics which we did not even touch
18:59:29 <SumitNaiksatam> ok
18:59:34 <SumitNaiksatam> many others
18:59:41 <SumitNaiksatam> regarding day/time?
18:59:56 <SumitNaiksatam> wednesday?
19:00:00 <banix> Lets prioritize wrt what we need to get others onboard as well
19:00:08 <s3wong> SumitNaiksatam: +1 for Wednesday
19:00:51 <SumitNaiksatam> 17:00 UTC?
19:00:55 <banix> ok with wednesday
19:01:01 <SumitNaiksatam> that is 10 AM PDT
19:01:08 <banix> sounds good to me
19:01:08 <pcm_> +1
19:01:11 <s3wong> +1
19:01:14 <prasadv> +1
19:01:23 <SridarK> +1
19:01:25 <s3wong> good for enikanorov_?
19:01:39 <SumitNaiksatam> enikanorov_: is always here :-P
19:01:41 <enikanorov_> looks fine
19:02:05 <SumitNaiksatam> ok done for now - wedenesday 17:00 UTC
19:02:09 <SumitNaiksatam> we can adjust later
19:02:09 <banix> time to move to alt
19:02:19 <SumitNaiksatam> yeah, next meeting is waiting
19:02:19 <s3wong> Talk to you guys next week!
19:02:20 <banix> i mean for policy call
19:02:24 <cgoncalves> banix: indeex :)
19:02:26 <SumitNaiksatam> i had a summary ready, but not time
19:02:26 <pcm_> thanks for hosting SumitNaiksatam
19:02:28 <SumitNaiksatam> no
19:02:32 <cgoncalves> *indee
19:02:32 <SumitNaiksatam> ok thanks everyone
19:02:37 <s3wong> thanks!
19:02:42 <banix> thank you sumit
19:02:43 <SumitNaiksatam> will send summary in email
19:02:45 <SridarK> bye
19:02:46 <SumitNaiksatam> banix: sure
19:02:48 <SumitNaiksatam> #endmeeting