14:00:19 <enikanorov__> #startmeeting neutron lbaas
14:00:20 <openstack> Meeting started Thu Mar 27 14:00:19 2014 UTC and is due to finish in 60 minutes.  The chair is enikanorov__. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:24 <openstack> The meeting name has been set to 'neutron_lbaas'
14:00:31 <sballe> Morning
14:00:35 <s3wong> hello
14:00:38 <evgenyf> hi
14:00:40 <rm_work> heya
14:00:42 <edhall> hi
14:00:44 <enikanorov__> agenda for the meeting:
14:00:47 <enikanorov__> #link https://wiki.openstack.org/wiki/Network/LBaaS#Agenda_for_Meeting_27.03.2014
14:01:08 <enikanorov__> we've got two pages created recently: glossary and requirements
14:01:19 <vjay2> hi
14:01:35 <enikanorov__> i'd like to start with any questions you may have for these pages
14:01:46 <enikanorov__> #topic LBaaS Glossary
14:02:15 <enikanorov__> any questions on the glossary?
14:03:05 <enikanorov__> seems to be none
14:03:06 <rm_work> I still don't like the way VIP is defined for this project (not a problem with the glossary necessarily?)
14:03:19 <rm_work> Is this not the time for that? :)
14:03:24 <enikanorov__> rm_work: what is your concerns, could you remind?
14:03:39 <enikanorov__> *concern
14:03:39 <sballe> I like the glossary. It makes things a little clearer
14:03:52 <rm_work> There is a general definition of VIP as "Virtual IP" which is… not the definition here
14:04:01 <rm_work> I know there were concerns regarding backwards compatibility
14:04:42 <enikanorov__> ok, the definition in the glossary states:
14:04:48 <enikanorov__> Object that represents an endpoint of load balancing device that has IP address.
14:04:49 <enikanorov__> In existing model it also has tcp port, protocol, session persistence setting. Vip is plugged into a subnet, so as an object, it has subnet attribute.
14:04:53 <sbalukoff> True: Glossary lists only the current meaning of "VIP" in the Neutron LBaaS model--  not what it will mean should one of the proposed object models get chosen.
14:05:09 <enikanorov__> is there something particular that you would like to change?
14:05:41 <sbalukoff> Well, if we adopt object models 2 or 3 in the proposal, the meaning of VIP changes, correct?
14:05:47 <rm_work> Well, it mentions "in the existing model", I am wondering if that is the place to open discussion of what it should mean going forward
14:05:48 <rm_work> or not
14:06:17 <rm_work> if not, ignore me and move on, we can discuss it later :) just want to be on record
14:06:37 <enikanorov__> ok, i see. probably terms need their context, thus 'in current model'
14:06:47 <markmcclain> yeah I think it is important that the glossary not be a rigid definition of terms.  If we're going to make changes to the API then it is likely we will need to make deliberate changes to how some items are described
14:07:02 <enikanorov__> markmcclain: good to have you here!
14:07:48 <enikanorov__> ok, lets move on to the requirements
14:08:44 <enikanorov__> #link https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements
14:09:35 <enikanorov__> any questions/suggestions on requirements?
14:10:16 <sbalukoff> Yes: How specific do we want to be under "operator requirements"
14:10:35 <sbalukoff> And it'd be nice if someone could fill out a "use case" so we get an idea of the template we should be using for those. ;)
14:11:08 <enikanorov__> sbalukoff: i think the first item is about ability to add appliances dynamically
14:11:18 <sbalukoff> "User requirements" looks pretty complete to me. I can't think of anything else to add there.
14:11:25 <enikanorov__> and that's quite clear requirement
14:11:44 <markmcclain> I think this is a good start, but am concerned the requirements seem to imply physical boxes or appliances
14:11:46 <enikanorov__> on other operator reqs... we're still too far
14:12:07 <enikanorov__> markmcclain: it's better to say backends, but yes, reqs imply that
14:12:08 <sballe> I am not sure what is meant by "he load balancer shall have the ability to monitor the health of nodes and automatically remove/add them from/in rotation. " under Health Check monitoring
14:12:12 <sbalukoff> markmcclain: Which ones?
14:12:21 <markmcclain> no not backends but functions
14:12:25 <sballe> Are we talking about the user' VM?
14:12:37 <markmcclain> "A _user_ should be able to configure multiple tcp endpoints (Vips) for single IP address that point to the same pool of nodes"
14:13:12 <jorgem> sballe: The health monitor requirement is there so that bad backends/nodes can automatically be removed from serving traffic
14:13:32 <markmcclain> it seems that load balancer and user on conflated
14:13:37 <markmcclain> s/on/are/
14:13:48 <sbalukoff> markmcclain: I think that's so people can have http and https on the same IP. DNS limitations are going to dictate that in many cases.
14:13:51 <jorgem> sbadia: example: i have 5 web servers being load balanced. 1 dies for some reason. the lb should not serve traffic to it
14:14:04 <jorgem> sballe: sorry that was meant for you
14:14:05 <sballe> I understand the requirement. I am just tryign to figure out what the use cases was. By node you mean the tenant's VM/nodes.
14:14:11 <markmcclain> the requirements should focus on how the API should change to enable the user to take actions
14:14:29 <enikanorov__> sbalukoff: yes. and i think markmcclain is saying that it's per implementation whether same ip different port is on the same loadbalancer or not
14:14:31 <german__> sballe, jorgem: the add requirement seems excessive (indicating a spare pool of nodes)
14:14:46 <sballe> jorgem, No problem. I agree with the requirements. I just wanted to make sure I 100% undertood what it says.
14:14:46 <markmcclain> I'm not actually arguing the requirement
14:15:08 <markmcclain> I'm saying the requirements should be stated from user or operator perspective
14:15:19 <markmcclain> not that of the virtualized appliance
14:15:30 <enikanorov__> in fact that consideration greatly affect or object model discussion
14:15:35 <rm_work> german__: I think it just means "one of the nodes that was already taken offline, if it comes back online"
14:15:41 <rm_work> german__: not that there would be additional pools of nodes
14:15:48 <jorgem> sballe: I can modify it. Requirements should be very clear so I'll try to update it
14:15:50 <sbalukoff> Oh! Ok, I see.
14:15:51 <rm_work> so "remove, and add back"
14:16:07 <german__> yep, that sounds good
14:16:10 <sballe> german__, I agree when I read it I thought we were talking about a pool of standby nodes...
14:16:16 <enikanorov__> ok, anything else on requirements?
14:16:26 <rm_work> honestly, "remove" and "add" may be the wrong terms there
14:16:45 <rm_work> "disable traffic flow" and "restore traffic flow" are more accurate
14:16:53 <sbalukoff> markmcclain: Just to I understand your concern: You'd like to see these requirements rephrased from a user's or operator's perspective.
14:16:55 <sballe> rm_work, agreed
14:17:05 <markmcclain> sbalukoff: yes
14:17:08 <jorgem> rm_work: that works for me
14:17:14 <sbalukoff> Not necessarily that the underlying implementation be considered, per se.
14:17:22 <markmcclain> it also makes it easier to use them to evaluate the API
14:17:23 <sbalukoff> (in the stated requirement itself.)
14:17:28 <jorgem> rm_work: so you want to update the requirement?
14:17:34 <rm_work> jorgem: doing it now
14:18:28 <enikanorov__> #action rephrase requirements so they are stated from user perspective
14:18:30 <sballe> Do we have a requirement to monitor the LB themselves?
14:18:43 <sballe> I do not see that anywhere
14:19:00 <sbalukoff> sballe: Not yet. That should probably go under 'operator requirements'
14:19:08 <enikanorov__> agree
14:19:10 <german__> +1
14:19:18 <sbalukoff> (I'm assuming by 'LB' you mean 'appliance' as stated in the glossary)
14:19:38 <jorgem> sbalukoff:  +1
14:19:40 <enikanorov__> lb - any backend, not necessarily an appliance
14:19:44 <german__> we could lump it under diagnostic -- but making it explicit might be better
14:19:52 <tvardeman> +1
14:20:05 <crc32> +1
14:20:10 <sballe> +1
14:20:12 <enikanorov__> there is some work been done on that by obondarev
14:20:17 <sbalukoff> enikanorov__: Ah yes, backend.
14:20:27 <sbalukoff> Sorry, I'll try to use our defined terms, going forward. :)
14:20:27 <enikanorov__> ok, lets move on to the object model discussion
14:21:20 <enikanorov__> so previously most of us tend to prefer approach which introduced loadbalancer object
14:21:41 <enikanorov__> and markmcclain had objections to that idea
14:21:59 <enikanorov__> markmcclain: could you please go over them again
14:22:01 <sbalukoff> Correct! And we want to make sure those objections are understood.
14:22:03 <sbalukoff> :)
14:22:25 <enikanorov__> right. so i feel those are connected to that API perspective approach
14:22:42 <markmcclain> the are connected to the aPI
14:22:45 <enikanorov__> but I'm still not sure I understood those
14:23:03 <blogan> hello everyone
14:23:03 <markmcclain> the API should be reflective of what a tenants wants to do
14:23:16 <markmcclain> and not of how the backend implements it
14:23:30 <enikanorov__> markmcclain: yes. one of such tasks is to be able to provide another VIP on the same IP address
14:23:34 <enikanorov__> the question is
14:23:38 <jorgem> markmcclain: agreed
14:23:49 <enikanorov__> how tenant can express this intent via the API
14:23:49 <enikanorov__> ?
14:24:41 <markmcclain> enikanorov__: the intent the express is the functions they want on their network
14:25:06 <enikanorov__> agree. so I want http and https balancing on 1 ip address
14:25:23 <enikanorov__> what kind of API  calls will allow me to do that?
14:25:44 <markmcclain> enikanorov__: that is what needs to be designed
14:26:04 <enikanorov__> well, it is already designed, and we have several proposals already
14:26:04 <jorgem> markmcclain: So how does introducing the load balancer object not allow that?
14:26:08 <enikanorov__> one is with loadbalancer
14:26:28 <markmcclain> jorgem: not really
14:26:29 <enikanorov__> jorgem: i think the question is for me
14:26:54 <enikanorov__> it allows that by keeping neutron port for the loadbalancer configuration
14:27:09 <enikanorov__> so creating another vip for the configuration could share the port
14:27:39 <enikanorov__> the details about the port are not exposed to the user though
14:28:02 <markmcclain> enikanorov__: you're thinking too low level right now
14:28:15 <rm_work> possibly we need all of: Loadbalancer, Listener, Vip
14:28:38 <enikanorov__> i'm thinking on API level. right now there is no way of specifying such method through API
14:28:52 <enikanorov__> and one of the ways is logical grouping at API level
14:29:23 <rm_work> Loadbalancer has a Vip, and: POST /api/loadbalancer/<lbid>/listener { port: 443, https, etc }
14:29:39 <rm_work> multiple listeners per Loadbalancer object
14:29:46 <markmcclain> enikanorov__: the reason we cannot currently specify something is because current API is problematic
14:29:57 <rm_work> (that's what I would be thinking if i were a customer)
14:29:58 <markmcclain> I think we need to decide what the ideal version of the API should look like and work from there
14:30:39 <markmcclain> rm_work: but what does the lb object provide?
14:30:53 <enikanorov__> the ideal version of API in my opinion, is when users accesses lbaas api as if they would access real LB
14:31:02 <jorgem> markmcclain: I agree. The API could be made more user firendly
14:31:04 <rm_work> LB object is a container for: Vip(1), Listeners(n) and some other stuff
14:31:33 <enikanorov__> so that's not only an API, but also a user expectation. users works with loadbalancer, which has vips, pools, etc
14:31:43 <jorgem> +1
14:31:45 <enikanorov__> that's how i see what user wants
14:31:51 <markmcclain> enikanorov__: we're virtualizing the functions not the appliances
14:31:56 <blogan> yes so a user expects to get a load balancer object when they use load balancing as a service
14:32:18 <sballe> blogan, +1
14:32:22 <markmcclain> I think a user only expects because that is was we constructed in the first iteration
14:32:25 <tvardeman> blogan: +1
14:32:39 <german__> +1
14:32:55 <edhall> a tautology
14:32:55 <ajo> project stats for tautology, 90 days
14:33:03 <enikanorov__> i think lbaas is not to widely used to create usr expectations
14:33:35 <enikanorov__> existing lbaas API is fine - but for simplistic configurations only
14:33:57 <blogan> i mean neutron is networking as a service and users definitely expect to create networks
14:34:02 <markmcclain> enikanorov__: the feedback I get from folks is they find the current API confusing
14:34:19 <sbalukoff> markmcclain: Other 'aaS' services use a virtual representation of appliances, too. For example, neutron (ie. "network as a service") has concept of a 'router', and this doesn't correspond to anything physical per se (though it can).
14:34:29 <enikanorov__> it both allows fine-grained control over the objects plus more 'user-friendly' APIs on top of that, like Heat have
14:34:52 <sbalukoff> markmcclain: I find current API confusing as well because there's no "load balancer" in our LBaaS. :)
14:35:07 <enikanorov__> markmcclain: agree it's confusing, but if we fix that, that would not be a completely different API
14:35:35 <markmcclain> sbalukoff: the similar argument could be made about the router too
14:35:38 <sballe> markmcclain, I second sbalukoff
14:35:40 <rm_work> do we want people using LBaaS API, or using Heat? because it seems like basically anything I want to do with a LB keeps being moved up to the Heat layer :/
14:36:01 <german__> both :-)
14:36:09 <jorgem> since its not part of core yet wouldn't now be the best time to change it? I understand there is a backwards compatibility concern but I would buy that if it were in core
14:36:15 <enikanorov__> rm_work: i think it's a bit another discussion
14:36:30 <rm_work> enikanorov__: ok
14:36:32 <jorgem> enikanorov: yeah…much larger scope
14:36:39 <sballe> rm_work, I wish we could integrate heat into LBaaS but still use LBaaS API to trigger LBaaS functiobality via heat. I believe other services are doing this
14:36:41 <markmcclain> jorgem: now is the time to alter the aPI
14:37:00 <enikanorov__> that's what we're trying to do - change the API
14:37:05 <jorgem> markmcclain: okay backwards compat. is a real concern I'm assuming
14:37:16 <blogan> markmcclain: is now the time to drastically change the api and break backwards compatibility?
14:37:21 <rm_work> sballe: sounds interesting, but a two-way dependency seems scary to me
14:37:36 <markmcclain> jorgem: yes backwards compatibility is a concern
14:37:37 <rm_work> maybe I am thinking about it wrong, it's early :P
14:38:07 <enikanorov__> i think the confusion of the existing API comes from some simplifications
14:38:13 <jorgem> markmcclain: Okay, that's fine with me. How much can we alter then if it currently needs an update?
14:38:19 <blogan> markmcclain: not breaking backwards compatibility is a big hinderance when it comes to fixing the api, unless those api calls are just deprecated but still work
14:38:21 <sballe> rm_work, It could be for advanced capabilities and maybe for a set of LBaaS extension APIs
14:38:21 <enikanorov__> like pool object playing a role of 'loadbalancer' object
14:38:35 <markmcclain> jorgem: I think we have the opportunity to define a new api
14:38:44 <markmcclain> and provide compatibility with the old one
14:39:16 <sbalukoff> markmcclain: That's going to get confusing if we re-use terms. (eg. meaning of 'VIP' changes in object model proposals.)
14:39:18 <markmcclain> blogan: we only have to provide compatibility at the rest layer
14:39:20 <jorgem> markmcclain: That makes sense. I feel like we will eventually need to get in the groove of that so now is as good a time as ever
14:39:21 <rm_work> markmcclain: doesn't that require a way to Version the API? unless we're not straying too far
14:39:36 <sballe> markmcclain, can we not use API versioning to ensure backwards compatibility for a little while?
14:39:53 <blogan> sballe: i dont think so since its a service plugin
14:39:53 <sballe> rm_work, you were reading my mind ;-)
14:39:59 <sbalukoff> Aah yes-- versioning the API could allow us to re-use terms that have been re-defined in later models.
14:40:05 <enikanorov__> i think backward compat is concern  not for community only, but for vendors & users as well
14:40:22 <markmcclain> we will need to provide rest compatibility
14:40:28 <enikanorov__> that's why i'm only pro changing the API if it's staying in existing 'boundaries'
14:40:30 <rm_work> sballe: i don't know neutron very well, so I don't know exactly how it works, but people keep asking about whether we can version or not, and so far it has sounded like NOT -- since we are a plugin for neutron, and it would have to be a neutron version
14:40:48 <rm_work> I would love some final clarity on that
14:40:54 <enikanorov__> right now all 3 proposals can be made bw-compatible
14:41:05 <markmcclain> for the main server we will be discussing and working on the v3 API
14:41:11 <sballe> rm_work, I am learning myself which is why I maybe ask slilly questions.
14:41:25 <rm_work> enikanorov__: I feel like most of those proposals were MADE to be bw-compatible on purpose, and i would like to see one where that is not necessarily a consideration
14:41:34 <rm_work> sballe: well, i'm right there with you :)
14:41:37 <markmcclain> during Juno, so that will provide an opportunity to design this api as we need and then provide backwards compat to v2 clients
14:41:41 <sballe> rm_work, :)
14:41:46 <markmcclain> rm_work: +!
14:42:08 <rm_work> ok
14:42:15 <blogan> markmcclain: so design a new API for v3 neutron now?
14:42:26 <rm_work> so we'd have to version the new LBaaS API along with Neutron 3
14:42:38 <rm_work> that's… going to be a ways out, yes?
14:42:43 <markmcclain> blogan: yes work to clean up a few items and make some extensions core
14:42:55 <sbalukoff> Juno release is this fall, right? That's not *that* far out.
14:43:15 <markmcclain> rm_work: yes there is an opportunity new versions of service plugins
14:43:20 <rm_work> does "during Juno" mean "after the release"?
14:43:24 <rm_work> so, AFTER this fall?
14:43:36 <markmcclain> sbalukoff: correct … 6 months is very short
14:43:38 <rm_work> or does it mean "to go with the Juno release"
14:43:42 <rm_work> guessing latter
14:43:52 <rm_work> just want to make sure
14:43:53 <enikanorov__> i think, if we're going to make new API
14:43:57 <markmcclain> tentatively starts offering the v3 api with juno
14:43:59 <enikanorov__> we may improve existing
14:44:04 <rm_work> markmcclain: ok thanks
14:44:05 <enikanorov__> with some of the approaches
14:44:11 <enikanorov__> so users can evaluate it
14:44:47 <enikanorov__> that also could help us create requirements for the new API and see what exactly was not good about the existing one
14:45:17 <enikanorov__> markmcclain: how's that sounds?
14:45:34 <markmcclain> we have a good start with the requirements wiki
14:46:03 <blogan> i am glad we have that and a glossary
14:46:34 <enikanorov__> markmcclain: i mean, while v3 API is designed, may we work on improving v2?
14:46:43 <jorgem> markmcclain: So what I am hearing is start fresh on work towards a v3 API? That is the priority right now?
14:46:47 <rm_work> +1 clean API break to go with Neutron v3 (and keep existing API backwards compatible, but do some mods as enikanorov__ proposes)
14:46:54 <markmcclain> enikanorov__: depends on the work
14:47:17 <markmcclain> jorgem: I think a fresh start is a good idea
14:47:22 <rm_work> take off the handcuffs
14:47:23 <jorgem> I'm just trying to figure out what we should be focusing on right now
14:47:43 <enikanorov__> markmcclain: the most important reqs are multiple vips per pool and L7 rules, which were going to depend on 'loadbalancer' object
14:48:01 <sbalukoff> SSL is also a big req.
14:48:03 <jorgem> markmcclain: Ok. If that's the case we should really drill down on the requirements and prioritize them.
14:48:17 <jorgem> Operator requirements are huge too
14:48:22 <sbalukoff> jorgem: +1
14:48:26 <markmcclain> enikanorov__: they only depend on the load balancer object because that was the way they were implemented
14:48:31 <markmcclain> jorgem: +1
14:48:32 <vjay2> jorgem:+1
14:48:35 <crc32> +1
14:48:41 <sballe> jorgem, +1
14:48:52 <german__> +1
14:48:57 <tvardeman> jorgem: +1
14:49:04 <blogan> markmcclain: what do you mean that is the way they were implemented? when?
14:49:06 <sballe> resiliency/ha is a big on for us
14:49:10 <enikanorov__> markmcclain: yes, that is so, partially. but whole change will help to evaluate the new API and features it allows to do
14:49:27 <sbalukoff> sballe: Us too!
14:49:27 <enikanorov__> markmcclain: so that will help to build v3 API
14:49:32 <rm_work> blogan: i think he meant "proposed to be implemented"
14:49:34 <jorgem> markmcclain: Rackspace can provide data to back up some of these requirement decisions too
14:49:49 <jorgem> It would be nice for other operators to do the same
14:49:58 <markmcclain> jorgem: great
14:50:06 <sballe> markmcclain, so can HP cloud re: date to backyp requirements
14:50:10 <sbalukoff> jorgem: I think we could as well.
14:50:19 <jorgem> sbalukoff: awesome
14:50:19 <markmcclain> sballe: great
14:50:29 <jorgem> I'm sensing an action item
14:50:39 <sballe> jorgem, ;-)
14:51:02 <markmcclain> if we can drive the design priority based on real usage that will be very helpful
14:51:05 <jorgem> #action Provide operator data to aid in requirements discussion
14:51:56 <jorgem> For example, 90%ish of our cloud lbs are http and https
14:52:14 <jorgem> Thus, we would focus (from our perspective) on requirements that hit on http and https
14:52:20 <sbalukoff> jorgem: It's more like 95% for us.
14:52:31 <german__> same here at HP Cloud
14:52:36 <edhall> It's less than half for us
14:52:37 <jorgem> However, I would like to get everyone's data pooled together to help in the decision process
14:53:00 <jorgem> edhall: Nice! Didnt' expect that
14:53:14 <jorgem> edhall: I'd be very interested to hear you average users use case
14:53:26 <jorgem> edhall: And be glad to share ours :)
14:53:42 <edhall> In terms of traffic, HTTP/HTTPS of course.  But LB is an internal HA mechanism as well.
14:53:46 <enikanorov__> ok, it makes sense to create another wiki with user scenarios then
14:54:11 <markmcclain> glad we're getting some usage data will help to prioritize work
14:54:36 <enikanorov__> #action create wiki page to collect usage data
14:55:11 <blogan> markmcclain: are you 100% opposed to a load balancer logical model?
14:55:12 <jorgem> Percentages are a good measure I think
14:55:15 <sballe> markmcclain, I am worried that in some ares like resiliency while we all have the same need for HA that the requirements are different.
14:55:17 <sbalukoff> Doesn't look like we're going to get to talk about HA stuff today?  should we plan on continuing that discussion on the mailing list?
14:55:29 <markmcclain> blogan: I'm not 100% opposed
14:55:51 <markmcclain> I just want to work through the functions a user needs and how they interact with it from the API
14:56:18 <rm_work> enikanorov__: we are probably a ways out from discussing the precise role of Heat vs LBaaS API functionality? would that be next time, or TBD
14:56:32 <enikanorov__> rm_work: ...or ML
14:56:33 <jorgem> blogan: I think once we get data we can revisit that per the functions that get priority
14:56:43 <rm_work> enikanorov__: ok, good point.
14:56:50 <enikanorov__> markmcclain: some say that users want virtualized appliances also
14:56:58 <enikanorov__> markmcclain: why can't we provide both?
14:57:49 <sballe> sbalukoff, re: Service resiliency I was hoping we had the time to discuss today.. ML will have to do until next meeting.
14:58:19 <sballe> enikanorov, Can we put HA/resiliency and the pool of standby approach on the next agenda? I'll do some homework before next meeting
14:58:33 <rm_work> markmcclain: IME people like to interact with virtual things that are representations of what they're used to physically -- so to touch a LoadBalancer, they'd expect a LoadBalancer object. I suppose we could TRY to redefine that, but I can't think of a good reason why
14:58:34 <enikanorov__> sballe: sure we can
14:58:35 <sbalukoff> sballe: Yep.
14:59:36 <markmcclain> enikanorov__: for virtualized appliances it will depends on which user you're talking about the tenant or service provider different use cases
14:59:52 <enikanorov__> tenant, not provider
15:00:42 <enikanorov__> i feel that API could provide both 'functions' and 'virtualized appliances' for those who need it
15:01:01 <enikanorov__> and i can't understand why we limiting it to functions only
15:01:11 <enikanorov__> ok... we're out of time
15:01:19 <blogan> enikanorov: are you talking about using VMs and containers as backends?
15:01:26 <jorgem> thanks everyone!
15:01:34 <enikanorov__> blogan: no. i'm talking about logical concepts
15:01:34 <s3wong> thanks!
15:01:37 <enikanorov__> #endmeeting