17:31:57 #startmeeting Networking Advanced Services 17:31:57 Meeting started Wed May 7 17:31:57 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:31:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:32:01 The meeting name has been set to 'networking_advanced_services' 17:32:07 Meeting agenda: #link https://wiki.openstack.org/wiki/Meetings/AdvancedServices 17:32:10 hi 17:32:17 #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices 17:32:20 hi. 17:32:36 sballe: hi 17:33:05 #topic Neutron Advanced Services' Common Framework 17:33:15 #link https://review.openstack.org/#/c/92200 17:33:48 per our discussion during the past several weeks, and direction from the PTL, the above umbrella blueprint was posted 17:34:17 hope there were no surprises with regards to the content in that spec, it was based on the consensus until last week 17:34:23 if you get a chance a please review 17:34:34 SumitNaiksatam: do we need to get this approved, or it simple stands to bring other pieces together? 17:34:35 thoughts/questions? 17:34:43 banix: ah good point 17:34:50 SumitNaiksatam, Is this proposal a step closer towards having a clean integration between Neutron core and the Advanced Services? 17:34:52 Hi 17:34:57 my understanding is that it probably needs to get approved 17:35:21 however, we need to get all the dependent blueprints in 17:35:36 we will follow up on the individual components in the agenda of the meeting 17:35:39 and interface? or is it more a workflow type of thing e.g. service lyfe cycle 17:35:59 sballe: its both 17:36:06 banix: does that answer 17:36:12 SumitNaiksatam, perfect. thx 17:36:14 SumitNaiksatam: yes thanks 17:36:20 SumitNaiksatam: well, at the very least, service definition isn't being pointed to the reference link in the doc 17:36:27 sballe: there is some amount of integration, though not perfect 17:36:40 sballe: this is a step in the process of organic evolution 17:37:10 s3wong: ?? 17:37:40 SumitNaiksatam: [3] isn't properly pointing to the document with service base definition 17:37:42 s3wong: do you have a new link/ 17:37:55 SumitNaiksatam: same service insertion document 17:38:06 hi 17:38:14 s3wong: ok, need to check 17:38:20 s3wong: will update accordingly 17:38:20 hi there.. bit late! 17:38:40 most of those references are place holders though, waiting for the gerrit blueprints to be filed 17:38:52 sballe: does that answer your question? 17:38:53 SumitNaiksatam: good 17:39:30 hi to all those who just joined 17:39:56 ok moving on 17:40:23 so since we have a high level plan, i propose that we henceforth start tracking in individual item 17:40:28 SumitNaiksatam, yes. I am looking at the BP now. I would like to see somewhere that we identify the need for a clean integration with Neutron 17:41:10 sballe: the whole discussion iis in the context of Neutron itself 17:41:27 sballe: so there are multiple touch points with neutron 17:41:39 sballe: or rather with the rest of neutron 17:41:48 SumitNaiksatam, I understand but I am told that the LBaaS for example manipulate the Neutron tables directly. There should be an API for that 17:41:55 sballe: in every component that is identified 17:42:26 sballe: why? lbaas is a part of neutron, it has direct access to the DB 17:42:27 sballe: sure, that might have been an implementation short cut 17:42:43 the api is LbaaS DB plugin itself 17:42:49 no additional layer is needed 17:42:57 enikanorov: yes, i agree those are local calls 17:43:07 enikanorov: not REST api calls 17:43:45 enikanorov: perhaps what sballe is indicating is that services should access neutron through clean interfaces rather than manipulating the db tables 17:43:46 SumitNaiksatam, enikanorov IMHO we want to make sure that we have a clean interface and integration between the core of Neutron and the Advanced Services. 17:43:50 if indeed that is happening 17:44:01 SumitNaiksatam, Yes that was my point. Thx 17:44:04 sballe: agreed 17:44:24 enikanorov: sound okay, i think we are on the same page, right? 17:44:54 SumitNaiksatam, Can we add this item to the BP? 17:45:06 SumitNaiksatam: i'm actually not sure :) 17:45:11 sballe: yes sure, please also feel free to comment 17:45:15 enikanorov: ok :-) 17:45:22 while services are plugins which are within the same process accessing the same DB... 17:45:22 SumitNaiksatam, Will do. 17:45:37 i wonder what additional interfaces are needed to work with it? 17:46:16 anyway, we can discuss it offline 17:46:39 enikanorov: hypothetical example - you might not want lbaas code to maniplulate neutron “port” table directly 17:46:53 this was mention by markmcclain1 and mestery at some point when we talked about the neutron/LBaaS connection 17:47:00 sballe: is that what you had in mind? 17:47:14 SumitNaiksatam: well.. we're all gentlemen, we trust other's code, right? 17:47:17 SumitNaiksatam, yes along these lines 17:47:21 or otherwise we would be writing java 17:47:28 enikanorov: ha 17:47:35 enikanorov: :D 17:47:40 ok we are getting philosophical, so we move on 17:47:56 this discussion on the drinks table in atlanta :-) 17:48:03 sure :) 17:48:12 perfect. count me in :-) 17:48:31 so my earlier question to the team, regarding tracking progress on the individual components listed in the bp (going forward in this meeting) 17:48:33 sound okay? 17:48:39 sure 17:48:42 yes 17:48:43 i can update on flavor fw 17:48:45 Yes 17:48:50 SumitNaiksatam: yes, please continue 17:48:52 that way we can have some milestones and dates 17:49:03 good 17:49:15 so start with our favorite topic 17:49:19 or rather flavor 17:49:27 yes 17:49:28 "flavor-ite" 17:49:39 ok 17:49:46 #topic Flavors framework 17:49:52 enikanorov: you are the cook! 17:49:56 er…chef 17:50:04 so... i think https://review.openstack.org/#/c/90070/ is in good shape and pretty much everything about the framework itself is covered 17:50:07 so please review 17:50:19 enikanorov: ok 17:50:23 questions for enikanorov? 17:50:31 well, I'm going to jump in and say that going up the stack - it looks fine 17:50:32 however we've found an issue that we didn't though on much 17:50:35 enikanorov: my apologies, i have been behind 17:50:40 going down the stack, I have questions 17:50:43 it's not a blocker for the framework itself 17:51:02 regXboi: sure, whats down the stack 17:51:03 but it's something that should be solved for the integration between flavors and particular service 17:51:05 welcome regXboi 17:51:13 enikanorov: what is the issue? 17:51:21 what I don't see is a way for someone to pick between different implementations of services by the same provider 17:51:24 i'm giving an example: 17:51:33 user creates a service using some flavor 17:51:43 enikanorov: please go ahead 17:52:01 and then tries to create/update some part of it, which chosen implementation doesn't support 17:52:14 so user gets an 'unsupported' error 17:52:33 the issue is that user might not know from the flavor that this feature is not supported 17:52:39 particular example: 17:52:51 user creates haproxy loadbalancer 17:53:07 then it tries to add PING health monitor that haproxy doesn't support 17:53:15 ... 17:53:46 enikanorov: seems to tie in w/my concerns about vendor validation, and client capabilities 17:53:47 right not it's not very clear to me how to indicate that to a user prior trying and failing 17:53:59 enikanorov: well, I don't think flavor can be this descriptive (which health check type do you support?) - so return unsupported isn't too bad, right? 17:54:04 one option is to have detailed description of flavors 17:54:15 s3wong: it's actually bad 17:54:25 s3wong: because you don't know the provider now 17:54:46 s3wong: how can you know what you should change to get this damn feature working? 17:55:18 enikanorov: on the flip side, if every supported features need a tag, that makes the flavor language too bloated 17:55:25 so looks like flavors need to include lots of stuff, or otherwise such failures will be very confusing for a user 17:55:28 shouldnt you have specified this requirement when you asked for the service ? 17:55:37 s3wong: that's true as well 17:55:57 even a vendor driver supports PING server, the function might work a little differently from vendor to vendor 17:55:58 banix: right, but should I require each and every kind of feature? 17:56:12 gduan: yes. 17:56:13 gduan: good point 17:56:24 so this might be solved by 'get_capabilities' call 17:56:39 enikanorov: so we had discussed earlier about different types of attributes 17:56:42 but we need such method before flavor fw choses the provider 17:56:46 or capabilitites 17:56:58 there are those which are common to all “types” of services 17:57:01 enikanorov: In my L3 vendor plugins I have a BP on that. How client knows vendor capabilities 17:57:21 enikanorov: Though not sure how to best handle that. 17:57:23 then there are those that are common “within" a service type 17:57:40 and then there are those which are more specific to drivers 17:57:42 very soon, for more complicated services, get_capabilities will return several pages worth of information 17:57:44 so, framework itself is flexible enough to handle this problem in various ways 17:58:02 but when it comes to integration - it better to be solved in some convenient way 17:58:09 s3wong: which is fine. no? 17:58:23 I doubt there is an 'accurate' description of capability 17:58:23 we don't want to bloat flavors for cloud ops, but we also don't wan't to confuse users 17:58:48 enikanorov: hence the suggestion to have different categories of capabilitites 17:58:56 banix: user would have to sniff through the list of capabilities before a user can choose - like a product catalog 17:59:14 SumitNaiksatam: yeah, the categories are just strings, and it's all about string matching 17:59:29 enikanorov: i am suggesting separate API calls perhaps 17:59:32 so it's more about a general way of how we handle it 18:00:11 enikanorov: so you can say, get_service_capabilities(), get_servcice_type_capabilities(), get_service_driver_capabilities() 18:00:20 for the particular example above i suggest it is solved by adding 'healthmonitor:PING' capability 18:00:22 and then at the end, tenant might say "hey, I know Netscalar can support all the stuff i want, where can I pick that?" :-) 18:00:24 something like that, those api names might be off 18:00:41 s3wong: 'how' can i pick that 18:01:00 SumitNaiksatam: yes, that's what we will need 18:01:26 Should this BP address this issue? https://review.openstack.org/#/c/89366/1/specs/juno/l3-svcs-vendor-client-cap.rst 18:01:34 so my concern is 18:01:36 enikanorov: then every capability should be scoped with service type. 18:01:44 flavor maps to several providers 18:01:46 enikanorov: who should be define these capability ist? 18:02:10 sorry typos 18:02:18 and then we need precise flavor to let user work with particular feature 18:02:29 gduan: driver's authors 18:02:53 enikanorov: i think beyond the simple cases, the user could pick based on the vendor and the particular implementation for esoteric needs 18:03:06 Kanzhe: there can be common capabilities (base capabilities) and then those that are specific to types 18:03:21 SridarK: yes, but the main goal of Flavors to hide providers from the user 18:03:39 enikanorov: I think gduan 's point is, who is going to set up the set of meta-tags like healthmonitor:... 18:04:06 enikanorov: exactly; so we are getting distanced from that 18:04:06 s3wong: it's done on 1) driver side 2) by cloud operator 18:04:08 s3wong: yes, the superset of all possible capability names 18:04:10 SumitNaiksatam: sure. Scope can be used to indicate common, type specific, etc. 18:04:15 enikanorov: i agree but i am afraid that we will have something unwieldy on the more complex cases 18:04:36 s3wong: then vendor drivers claim they support the subset 18:04:39 SridarK: choosing provider is also supported by the flavors 18:04:39 ok, we need to move on 18:04:43 enikanorov: I am guessing flavor framework would limit the available categories - which can be perceived as limiting vendors (disclaimer: I do NOT work for a network service vendor) 18:04:46 so, so i'll finish 18:04:52 enikanorov: sure 18:04:59 the issue i've told about is for integration 18:05:03 SumitNaiksatam: regXboi had a question 18:05:03 the framework itself is fine 18:05:08 so please review and approve :) 18:05:24 so the framework is intended to hide provider from user - i get that 18:05:29 enikanorov: yes, I agreed. The framework and workflow is fine 18:05:33 enikanorov: why not just provider:model for flavor. and refer to manuals for detail capabilities. :-) 18:05:36 yes, all please review, and we need make move forward on this topic 18:05:51 what I don't see is what about specification of a particular instance of a service from a provider 18:05:51 Can folks look at my BP, as it tries to address caps to client? 18:06:00 that may not be flavor, but I'm not seeing it anywhere 18:06:12 pcm_: sure, thanks 18:06:19 Kanzhe: I think that's what enikanorov wants to avoid, exposing provider brand/product names 18:06:20 regXboi: explain? 18:06:29 pcm_’s blueprint: https://review.openstack.org/#/c/89366/1/specs/juno/l3-svcs-vendor-client-cap.rst 18:06:34 so flavor is intended to hide provider from user 18:06:39 yep 18:06:39 SumitNaiksatam: thanks. If it fits, we can use it as a forum for discussion of this part of it. 18:06:43 pcm_: will take a look, sure 18:06:52 what happens in the case where a provider has multiple instances of a service available 18:06:58 pcm_: will look; thanks. 18:07:03 and wants to allow a user to specify the instance 18:07:13 regXboi: multiple backends you mean. 18:07:27 regXboi: provider doesn't allow user to specify particular backend 18:07:33 um 18:07:33 but it could be sheduled with flavors 18:07:43 regXboi: the scheduling algorithm takes care of that, tenants don't get to choose a particular backend 18:07:48 say, flavor has a tag: 'connetctions':'unlimited' 18:07:51 that's an assumption I don't quite agree with, but ok 18:08:05 and that will hint sheduler to place an instance to a performance backend 18:08:31 regXboi: user is not in control of backends, neither provider, nor particular appliance/device 18:08:47 regXboi: that's whole point of abstraction 18:08:47 ok, I'll let it drop 18:09:11 we can have f2f discussion in the summit as well 18:09:23 enikanorov: ok to move on? 18:09:24 SumitNaiksatam: sure, even more then once i guess 18:09:35 SumitNaiksatam: that's it from my side if there are no more questions 18:10:09 enikanorov: flavor only get 1/3 of a design session :-) 18:10:16 enikanorov: great thanks, that discussion was a full course meal for this meeting! 18:10:21 s3wong: we can do more 18:10:40 flavor will be part of the adv services common framework discussion 18:11:01 so we will get 2/3rd of the time to cover the adv services topics 18:11:07 enikanorov: sound okay? 18:11:10 yes 18:11:19 i dont know what the third topic is about 18:11:37 i was hoping that proposer would have joined thid forum 18:11:51 so we could have had a coherent plan/strategy 18:11:51 anyway 18:11:58 #topic Base service definition 18:12:07 s3wong: over to you 18:12:18 #link https://docs.google.com/document/d/1AlEockwk0Ir267U9uFDc-Q6vYsWiAcAoKtCJM0Jc5UI/edit#heading=h.v0wed816g3i1 18:12:39 this captures any changes we need to make to base service defintion to support insertion and chaining (and also flavors) 18:12:39 Kanzhe and I decided to merge the two topics into one document 18:12:45 s3wong: ok 18:13:03 so we are going to have one gerrit spec for this? 18:13:13 SumitNaiksatam: yes 18:13:20 ok 18:13:38 s3wong: can you quickly highlight the changes to the base service definition? 18:13:50 s3wong: The two topics are service base class definition and service insertion. 18:14:01 SumitNaiksatam: My understanding was that we will have a different gerrit blueprint for chanining 18:14:13 mandeep: yes thats a different spec 18:14:14 SumitNaiksatam: I am OK either way, just asking for clarification 18:14:19 SumitNaiksatam: OK 18:14:22 is the list of service ports in service base class ordered or not? 18:14:22 mandeep: we will come to that in the agenda 18:14:25 The ServiceBase object is used to maintain the connection mapping of where a service is being inserted 18:14:29 mandeep: sorry i think i forgot to add that 18:14:44 s3wong: please proceed 18:14:48 regXboi: No - order will be determined by ... the service chaining framework 18:14:56 s3wong: thanks 18:15:10 regXboi: servicePorts are not order. This is not serviceChaining. 18:15:20 wasn't thinking of service chaining 18:15:27 was thinking of abstraction 18:15:45 regXboi: Do you see a need for ordering? 18:15:50 mandeep: added 18:15:51 not sure - was asking 18:15:57 need to think about it some more 18:15:59 SumitNaiksatam: Thanks 18:16:10 I added flavor to track which user defined flavor maps to this service object, and Kanzhe and me had extended ServicePort definition to cover different types of insertion, therefore just having a list of ServicePort seems to be good enough 18:16:42 s3wong: ok, does this reconcile with the flavors blueprint? 18:17:20 SumitNaiksatam: yes, I read through enikanorov 's bp before writing the workflow 18:17:25 s3wong: nice 18:17:28 s3wong: The service port seems to assume that an external port cannot be another neutron port, only something on a physical device. 18:17:29 so it should work well with the flavor framework 18:18:01 bmelande: good point, s3wong can you take note ^^^ 18:18:12 the next topic is related, so lets move on 18:18:21 bmelande: sorry, that must be due to my poor writing (and lack of detail description). ExternalPort is something that does not belong to the tenant who requests the service 18:18:22 #topic Service insertion proposal update 18:18:44 Kanzhe: ? 18:18:47 : #link https://docs.google.com/document/d/1AlEockwk0Ir267U9uFDc-Q6vYsWiAcAoKtCJM0Jc5UI/edit#heading=h.v0wed816g3i1 18:18:53 so if you have a ServiceVM that is managed by the admin, for example, the tenant object still connects to it via the ExternalPort 18:19:10 SumitNaiksatam: yes. It is the same doc that s3wong and I put together. 18:19:14 so not limited by the physical / hardware device 18:19:14 s3wong: thanks 18:19:32 Kanzhe: ok good, any changes over the past week? 18:19:32 servicePort is the main abstraction to express service Insertion. 18:19:35 bmelande: will update doc to reflect that 18:19:43 Kanzhe: ok good 18:19:51 SumitNaiksatam: The main changes is about workflow. 18:20:01 Kanzhe: what is the ETA for submitting this to gerrit 18:20:02 ? 18:20:24 s3wong and I will convert to gerrit in the next day or two. 18:20:35 Kanzhe: ok nice 18:20:48 s3wong: Our use case is that service VM has a set of port (owned by special service tenant). Those ports are effectively trunk port. Multiple networks (in tenants owning the service instance) are trunked on the trunk port. 18:20:51 Kanzhe: can you please very quicly summarize what is the change to workflow that you are indicating? 18:21:09 SumitNaiksatam: the major change really is about not having admin specific objects, but relying on service agents to give us interface information 18:21:20 The main change is to clarify the integration with flavor BP 18:21:35 s3wong, Kanzhe: ok 18:21:45 perhaps folks need to read through the doc 18:21:52 bmelande: can you comment on the doc? 18:21:53 bmelande: Erik submitted a code review for trunk port 18:21:55 bmelande: yes, that was the use case we talked about also at the ServiceVM meeting 18:22:39 bmelande: with the absence of trunk port support, one way is the driver for CRS1000v would need to return an ExternalPort per each VLAN 18:22:43 s3wong, SumitNaiksatam,gduan: yes will do, yes he did, yes thats the one we talked about 18:23:09 bmelande: ok thanks 18:23:16 one thing that is not quite clear in the google doc 18:23:26 regXboi: sure, go ahead 18:23:35 is overlay transport considered L2 or L3 for insertion mode 18:23:49 I can argue both 18:24:25 regXboi: the insertion mode (Lx) depends on whether the service is inserted into a Neutron network or connected to a router 18:24:36 can we add that then? 18:24:37 regXboi: i would imagine that is a property of the network 18:24:42 that makes it much cleaner 18:24:52 and yes, then it becomes a property of the network 18:25:07 regXboi: will clarify in the document. Thanks! 18:25:16 s3wong Kanzhe: thanks! 18:25:31 i know we are rushing here a bit 18:25:38 #topic Traffic Steering 18:25:47 cgoncalves: over to you 18:25:54 #link https://review.openstack.org/#/c/92477 18:26:10 SumitNaiksatam: five minutes for traffic steering, service chaining, and open discussion 18:26:11 cgoncalves: thanks for submitting promptly 18:26:13 :-) 18:26:20 and also for the pretty ascii! :-) 18:26:21 as most of you know I've submitted the proposal. there's the link ^ 18:26:32 s3wong: sure, why not! :-P 18:26:38 SumitNaiksatam: still struggling with the use case pics though 18:26:47 s3wong: after all the hours we spent before 18:26:55 cgoncalves: pics? 18:27:05 SumitNaiksatam: https://docs.google.com/document/d/1Bk1e8-diE1VnzlbM8l479Mjx2vKliqdqC_3l5S56ITU/edit#heading=h.jpcx6ne3dl50 18:27:28 oh you mean inserting the figures for the use cases 18:27:35 cgoncalves: dont worry about it 18:27:39 this wekk I've been thinking on start developing this BP 18:27:39 perhaps a reference is good 18:27:41 cgoncalves: sorry for our delay - with ServiceBase now having all the attachment information, perhaps there is something there you can leverage in this bp? 18:27:52 in the BP one question 18:28:04 I'd like to hear from you on how do you think it would be best to implement it. 18:28:14 the statement that the abstraction *can be leveraged* implies that there is more than one way to specify a service chain 18:28:22 is that a good idea? 18:28:32 regXboi: Yes 18:28:41 regXboi: there are different levels of abstraction 18:28:49 regXboi: There are multi-function boxes that can not support full traffic streeing 18:28:59 s3wong: will look again, sure 18:29:05 regXboi: But they can honor the requirements of a chain 18:29:13 cgoncalves: thanks 18:29:26 cgoncalves: great. Thanks! 18:29:28 cgoncalves: we will continue to discuss this in the summit 18:29:41 cgoncalves: i know you cannot make it, but we shepherd it 18:29:45 having more than one way to do something is adding complexity, so I have to ask if it is really necessary 18:29:46 SumitNaiksatam: ok, but note that I won't join you all though 18:29:52 SumitNaiksatam: ok 18:29:52 cgoncalves: I trust that you and your team will be in Atlanta? perhaps we can meet and discuss? 18:29:56 that's all 18:30:07 mandeep regXboi: nice segue to the topic 18:30:11 s3wong: we won't make it this time, sorry 18:30:16 #topic Service Chaining 18:30:23 mandeep: please continue 18:30:34 mandeep: i know you have dependency on the earlier items 18:30:36 Following up on comments from regXboi 18:30:56 * regXboi listens 18:31:13 The current proposal for service base, service insertion and servoce chaining 18:31:19 we are going to go a few minutes over (hope thats fine with everyone) 18:31:24 allow for a very complete model to be developed in future 18:31:44 But we already have existing services that can provide services in a very common use case 18:32:04 That is "chaining multiple bump-in-the-wire services" 18:32:23 The intent of this proposal is to identify that use case (and it's context) 18:32:50 and define the expectations on the semantics of that service 18:32:57 so you envision this as being for L2 insertions? 18:33:22 that way, the service could be achieved by sterribg traffic between multiple services inserted in a network 18:33:45 mandeep: clarity - that implies that this is for L2 insertions and not for L3 insertions? 18:33:48 (at L2 or L3), or by a multifunction service that can honor the chain semantics 18:34:10 The semantics are defined in terms of BITW model. 18:34:16 That is typically L2 18:34:52 But the implementation may wrap it in L3 or any other tagging mechanims - the abstraction does not imply the implementation 18:35:13 so, I ask because I didn't make the jump from port to L2 18:35:13 The semantics need to be honoured, and the specification is of those semantics 18:35:37 I read this as being applicable to ports on a router 18:36:08 regXboi: a lot of the questions you are asking are actually meant to be answered in teh service insertion blueprint 18:36:11 regXboi: Actually you are correct. I was using L2 incorrectly 18:36:38 SumitNaiksatam: it's likely, the topics tend to bleed together 18:36:54 regXboi: completely agree 18:37:26 regXboi: but at a high level, the thinking was that the service chain blueprint would leverage the service insertion and traffic steering abstractions provided to it 18:37:34 regXboi: The intent is to define a semantic at usage/consumption of the service and not require orchestration/steering if your technology can not support it 18:37:51 mandeep: Understood, though I'm still concerned about having more than one way to accomplish something, but I'll put some more thought into nailing down the issues I foresee 18:37:56 regXboi: But if it is available, that would probably be the simplest mapping 18:38:07 because if they aren't real, then there's no reason to worry 18:38:13 mandeep: agreed 18:38:21 regXboi: OK, I will look into that as well 18:38:37 mandeep: we will have the spec in gerrit by next week? 18:38:49 mandeep: i know you have a dependency on the service insertion blueprint to land 18:38:54 regXboi: They are real .. that is how for example the current FW service is provided (on the router port) 18:39:00 SumitNaiksatam: Yes 18:39:05 mandeep: great, thanks 18:39:15 regXboi mandeep: thanks for that discussion 18:39:21 #open discussion 18:39:27 we are over time as usual 18:39:31 you mean #topic? 18:39:38 :-0 18:39:39 regXboi: yes 18:39:43 i am getting restless 18:39:44 :-) 18:39:48 #topic open discussion 18:40:09 anything else to discuss before we meet in person next week? 18:40:29 an official announcement that we won't have meeting next week? :-) 18:40:43