17:33:11 <SumitNaiksatam> #startmeeting Networking Advanced Services
17:33:12 <openstack> Meeting started Wed Jul 23 17:33:11 2014 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:33:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:33:15 <openstack> The meeting name has been set to 'networking_advanced_services'
17:33:18 <cgoncalves> hi!
17:33:36 <SumitNaiksatam> #info Spec approval deadline has passed
17:33:42 <s3wong> SAD
17:33:58 <SumitNaiksatam> indeed, especially for thos specs which got left out
17:34:06 <SumitNaiksatam> and definitely not funny!
17:34:31 <SumitNaiksatam> so if you feel strongly that you would still like your spec to be considered for Juno
17:34:32 <songole> hi
17:34:41 <SumitNaiksatam> please petition for a SFE
17:34:48 <SumitNaiksatam> spec freeze exception
17:35:02 <marios> SumitNaiksatam: out of interest, when are those expected until (is there a deadline)
17:35:03 <SumitNaiksatam> that said the likelihood of it going through are pretty slim
17:35:04 <vinay_yadhav> to whom should we address it to
17:35:16 <SumitNaiksatam> marios: honestly i am not aware of it
17:35:22 <marios> vinay_yadhav: see the mailing list, there are lots already
17:35:27 <Swami> hi
17:35:31 <SumitNaiksatam> vinay_yadhav: you can send to -dev mailer, there are a few
17:35:34 <vinay_yadhav> thanx marios
17:35:47 <vinay_yadhav> sumit: thnx
17:35:48 <SumitNaiksatam> our team has alread been give one for flavors
17:35:49 <cgoncalves> s3wong: +1 for SAD
17:36:08 <cgoncalves> I mean, SAD as in sad upper-case :-)
17:36:13 <SumitNaiksatam> cgoncalves, vinay_yadhav: i definitely feel your frustration
17:36:18 <marios> i was wondering what was happening/gonna happen with flavors and the deadline
17:36:21 <SumitNaiksatam> been there several times before!
17:36:31 <s3wong> salvortore said that at current rate (and volume), he advises not accepting any more exception other than some --- well - exception cases
17:36:43 <SumitNaiksatam> marios: lets discuss that in the agenda item
17:36:57 <s3wong> marios: flavor has requested SFE, and most likely will be accepted
17:37:00 <cgoncalves> SumitNaiksatam: yes, but I kind of would like to stress out here today the unexpected approval of the service chain spec
17:37:04 <SumitNaiksatam> anything anyone wanted to discuss here in terms of the process?
17:37:10 <marios> SumitNaiksatam: yeah thx, i was mostly responding to your update (missed the sfe for that)
17:37:14 <cgoncalves> SumitNaiksatam: nothing against you or mandeep, though
17:37:36 <marios> s3wong: thx
17:37:36 <SumitNaiksatam> cgoncalves: any reason you say “unexpected”?
17:37:49 <cgoncalves> SumitNaiksatam: I feel like it was approved without a broad discussion from the community and very few +1's
17:37:50 <SumitNaiksatam> cgoncalves: last i check there were no negative votes on that
17:38:37 <SumitNaiksatam> cgoncalves: and i personally was happy with what was mentioned in there since this is what we have been saying for the past three summits
17:38:48 <SumitNaiksatam> cgoncalves: hence my +2
17:38:48 <cgoncalves> SumitNaiksatam: although I can't complain much because I had no time to review it
17:39:30 <SumitNaiksatam> i cant speak for the other reviewers though
17:39:39 <anil_rao> Can I ask a question regarding the review process?
17:39:50 <SumitNaiksatam> anil_rao: sure
17:40:05 <cgoncalves> SumitNaiksatam: I know
17:40:10 <SumitNaiksatam> cgoncalves: we can discuss service chain spec in the agenda item if you have concerns
17:40:33 <anil_rao> I find that several +1s can be wiped out by a single -1, even if most folks don't agree with the reasons behind the -1. How does that work?
17:40:47 <cgoncalves> SumitNaiksatam: ok
17:40:48 <vinay_yadhav> Anil: +1
17:40:48 <SumitNaiksatam> anil_rao: yeah these things are subjective
17:41:00 <cgoncalves> anil_rao: +1
17:41:10 <SumitNaiksatam> anil_rao: its not necessarily the case that the -1s are “wiped” out
17:41:48 <marios> i should point out that anil_rao's point applies to neutron or even openstack more generally, its not an advanced services specs issue.
17:41:51 <SumitNaiksatam> anil_rao: but that shows some level of disagreement and hence the possibility of more discussion
17:42:00 <SumitNaiksatam> marios: yes definitely
17:42:15 <anil_rao> the reason I ask is I would like to know how to avoid such a scenario going forward.
17:42:42 <SumitNaiksatam> anil_rao: sure
17:43:14 <SumitNaiksatam> anil_rao: though i would like to point out that this is not a novel experience and unique to you
17:43:19 <vinay_yadhav> how do we make sure we have address all concerns when things are commented on the very last week or day :)
17:43:25 <SumitNaiksatam> anil_rao: as marios pointed out
17:43:33 <SumitNaiksatam> its across the project
17:43:42 <SumitNaiksatam> vinay_yadhav: absolutely
17:43:54 <s3wong> vinay_yadhav: that happens very often :-)
17:43:59 <anil_rao> We need to have some system where the collective +1s from several well meaning reviewers hold some weight.
17:44:07 <SumitNaiksatam> vinay_yadhav, anil_rao: to be honest, the amount of attention that the tap as a service spec got as a part of this team is unprecedented for a new feature
17:44:27 <SumitNaiksatam> it typically takes longer for a new feature to incubate and get through
17:44:48 <anil_rao> We are very thankful for that, which is why I was hoping that the support we got here counts. :-)
17:45:04 <marios> vinay_yadhav: anil_rao: I didn't submit a spec so I won't pretend to understand how p****d off you guys must be right now. i think this isn't something SumitNaiksatam can really address... IMO an email to the mailing list to provide feedback on the specs review process (and these last minute drive-by's) would probably be better targetted
17:45:09 <marios> my 2c
17:45:11 <vinay_yadhav> sumit: we are happy that advanced services group commented on the spec extensively and help improve it
17:45:34 <anil_rao> vinay_yadhav: +1
17:45:40 <SumitNaiksatam> if you approach other members of the community, they will politely tell you, please contribute by reviewing other blueprints as well and participating in  the Neutron priority activities like Nova network parity :-)
17:46:04 <SumitNaiksatam> marios: absolutely great suggestion
17:46:27 <anil_rao> agree
17:46:35 <vinay_yadhav> marios: thanx will try that
17:46:46 <marios> :( sorry
17:46:58 <SumitNaiksatam> and again, i can uenquivocally say, that i feel the pain of the folks whose spec did not get approved (i have been throught that before!)
17:47:10 <SumitNaiksatam> and i am not being fatalistic here
17:47:34 <SumitNaiksatam> and i think we as a team owned these specs
17:47:45 <SumitNaiksatam> so its “sad” for the entire team
17:47:50 <vinay_yadhav> i guess we can all try to make the system better for the future
17:48:32 <SumitNaiksatam> that said, like i mentioned privately to cgoncalves, vinay_yadhav, anil_rao before, it is very difficult to argue against the accepted priorities of the project
17:49:10 <SumitNaiksatam> and that priority in the J release has been pretty much on nova network parity (and DVR such that it supports the mutli-host feature)
17:49:58 <regXboi> I would point out the following ... any new patch wipes out all +1 and -1s
17:49:59 <SumitNaiksatam> but does that mean that we close our shop and twiddle thumbs
17:50:14 <SumitNaiksatam> regXboi: true
17:50:29 <regXboi> and -1s mean that something should be addressed in the comments
17:50:36 <SumitNaiksatam> regXboi: yes
17:50:51 <regXboi> I would argue that collective +1s shouldn't outweight a -1
17:51:02 <regXboi> because the -1 may be uncovering a case not thought of yet
17:51:15 <SumitNaiksatam> regXboi: that might be true in cases
17:51:35 <regXboi> and I can say that I've pushed back on at least one -1 successfully
17:51:36 <SumitNaiksatam> regXboi: but in this case the -1 was from cores
17:51:36 <vinay_yadhav> regXboi: true, but the +1 should not be wiped off either imho
17:52:08 <SumitNaiksatam> so while there is reason to be frustrated, hopefully if we keep marching in terms of the discussion, i think we have a head start for K
17:52:16 <cgoncalves> regXboi: while that's true, some specs got -1 from core reviewer(s) just because j3 was already swamped with approved specs
17:52:30 <regXboi> so... in order....
17:52:40 <SumitNaiksatam> as  a parallel activity, definitely do provide your feedback on the mailing list on the process, if you have concerns
17:52:42 <regXboi> +1s being wiped from new revisions actually makes sense
17:53:09 <regXboi> second order - I can't speak to the why of -1s (I'm not a core, so don't ask :) )
17:54:00 <mandeep> regXboi: I believe, any solution is going to have holes (removing +1s or -1s), I would just like better reporting that shows all +1/-1s across versions so that you do not have to go re-assert them again.
17:54:18 <vinay_yadhav> regXboi: it makes sense when the reviewer review the new patch and +1 or -1 it again :)
17:54:28 <regXboi> mandeep: that *would* be nice
17:54:40 <regXboi> but I'm not sure it's practical from gerrit's perspective
17:54:54 <vinay_yadhav> mandeep: +1
17:55:28 <regXboi> I'm just agreeing with SumitNaiksatam that expressing that on the ML is the way to go
17:55:31 <SumitNaiksatam> i think we have heard everyone, and been on this for about 25 mins now
17:55:39 <kevinbenton> mandeep: i think that’s what happens for workflow votes, but only cores have those
17:55:51 <SumitNaiksatam> so, lets move on for now
17:56:02 <kevinbenton> mandeep: although that might just be the -2’s…
17:56:14 <SumitNaiksatam> and feel free to reach out to me as well if you feel the need to continue this conversaton
17:56:31 <mandeep> kevinbenton: Yes, I think that -2 form cores is sticky.
17:56:32 <SumitNaiksatam> i have already preemptly reached out to the owners of the specs which did not get through
17:56:45 <SumitNaiksatam> enikanorov_: there?
17:56:56 <enikanorov_> yes
17:57:09 <SumitNaiksatam> #topic Flavors
17:57:19 <SumitNaiksatam> enikanorov_: i believe we got the FFE for this
17:57:26 <SumitNaiksatam> enikanorov_: and you have posted a WIP patch
17:57:49 <enikanorov_> right, the patch is actually ready for review
17:57:57 <enikanorov_> and i've got some comments from stephen already
17:58:01 <enikanorov_> which i'm going to resolve
17:58:01 <SumitNaiksatam> i am not sure what the plan is on the bp spec, since markmcclain was away on vacation last week
17:58:19 <SumitNaiksatam> enikanorov_: dont we need to get the spec approved first?
17:58:27 <enikanorov_> i'm working on cli also, hope to post it this week
17:58:32 <enikanorov_> SumitNaiksatam: yes, sure... :)
17:58:44 <enikanorov_> I asked markmcclain to folloup on spec
17:58:48 <SumitNaiksatam> enikanorov_: i am one of the assigned cores, so i am waiting on activity on the spec review in gerrit
17:58:51 <SumitNaiksatam> enikanorov_: thanks
17:58:55 <enikanorov_> or i can do that if he don't have enough time
17:59:08 <enikanorov_> so basically i can update the spec if he agrees
17:59:09 <markmcclain> I'll rev the spec
17:59:47 <enikanorov_> great!
18:00:03 <SumitNaiksatam> any questions for enikanorov_  or markmcclain?
18:00:18 <enikanorov_> oops
18:01:36 <SumitNaiksatam> enikanorov_ markmcclain: thanks
18:02:28 <SumitNaiksatam> #topic Service base and insertion implementation update
18:02:43 <SumitNaiksatam> s3wong, kevinbenton: ?
18:02:52 <SumitNaiksatam> and marios
18:02:58 <marios> hi
18:03:09 <SumitNaiksatam> marios: sorry i did not get a chance to respond to your email
18:03:32 <marios> SumitNaiksatam: haha, i was about to apologise for not checking my email
18:03:41 <SumitNaiksatam> marios: no worries
18:04:07 <kevinbenton> SumitNaiksatam: did you need me to describe the issue?
18:04:10 <SumitNaiksatam> s3wong: i believe you are repurposing kanzhe’s earlier implementation on the db and api
18:05:31 <SumitNaiksatam> kevinbenton: i believe you are referring to the discussion on where the service interface is implemented
18:05:51 <SumitNaiksatam> kevinbenton: go ahead
18:06:01 <marios> SumitNaiksatam: first off, thanks for all your last minute efforts on this last week!
18:06:16 <SumitNaiksatam> marios: np
18:06:26 <kevinbenton> yes. if we have the service interface API as a top level object, there won’t be an easy way to tell what type of service is being referenced by the creation of the service interface
18:06:42 <kevinbenton> because it will just be a UUID
18:07:20 <SumitNaiksatam> kevinbenton: even before we reach that point
18:07:35 <s3wong> SumitNaiksatam: sorry, talking to rkukura in office now
18:07:37 <kevinbenton> SumitNaiksatam: go ahead. I’m not sure what context is necessary
18:08:01 <SumitNaiksatam> kevinbenton: the neutron manager needs to decide where to dispatch the create service interface call to
18:08:08 <marios> i thought it was the backwards compat issue for the clients (though what kevinbenton describes sounds like another issue)
18:08:11 <s3wong> SumitNaiksatam: and yes, I am working on moving kanzhe's code to the latest model
18:08:25 <SumitNaiksatam> marios: we will come to that next
18:08:34 <marios> s3wong: is the code in gerrit?
18:08:40 <s3wong> marios: not yet
18:08:53 <marios> s3wong: i also have wip for vpn (and also needs conversion over to serviceinterface etc)
18:09:00 <marios> s3wong: k thx
18:09:00 <SumitNaiksatam> so we are proposing to implement a separate “service plugin” to implement the service interface
18:09:15 <marios> (very early wip)
18:09:47 <SumitNaiksatam> this “service plugin” will then make a call on the appropriate fwaas/vpnaas/lbaas service plugin
18:10:22 <SumitNaiksatam> this is where we face the second issue of deciding which sevice instance object is associated with the uuid (this is what kevinbenton was referring to)
18:10:28 <SumitNaiksatam> kevinbenton: i have some thoughts on that
18:11:01 <SumitNaiksatam> kevinbenton: we could potentially leverage notifications (say when a firewall is created) and have the new “service plugin” listen to that
18:11:30 <SumitNaiksatam> kevinbenton: when it gets the notification, it keeps a reference to in its own db as a firewall object
18:11:56 <kevinbenton> SumitNaiksatam: then it won’t work with services created before the plugin was activated. is that okay?
18:12:14 <SumitNaiksatam> hopefully we can ensure the order
18:12:31 <SumitNaiksatam> kevinbenton: but good point, and something to think about it
18:12:48 <kevinbenton> SumitNaiksatam: I mean way before, like during an Icehouse deployment :-)
18:12:48 <SumitNaiksatam> i think for the benefit for everyone else, this will probably be cleared with some WIP code
18:12:49 <s3wong> SumitNaiksatam: during Monday's conversation, I think we say that the service object (i.e. FWaaS object) DB has a attribute pointing back to ServiceBase entry?
18:13:18 <SumitNaiksatam> kevinbenton: ah, backward compatibility
18:13:21 <marios> s3wong: that's how i understand it (to a serviceinterface)
18:13:41 <SumitNaiksatam> kevinbenton: there would be no service insertion feature for icehouse
18:13:45 <s3wong> marios: actually to a serviceBase, then from the ServiceBase, we get the list of ServiceInterfaces
18:13:57 <s3wong> (that's the DB model)
18:14:06 <SumitNaiksatam> kevinbenton: i mean, the default insertion performed by the service happens in that case
18:14:15 <marios> s3wong: yeah, i assumed when it said 'servicebaseentry' it meant to one of the interfaces
18:14:18 <SumitNaiksatam> kevinbenton: so for example, firewall is inserted on all routers
18:14:36 <kevinbenton> SumitNaiksatam: oh, it’s not possible to change the insertion for an existing service?
18:15:05 <SumitNaiksatam> kevinbenton: at least in my mind we did not set out to provide that level of backward compatibility
18:15:25 <SumitNaiksatam> kevinbenton: that will be a hard problem to solve and i am not sure its worth the effort
18:15:39 <SumitNaiksatam> fwaas and vpnaas still have experimental APIs
18:15:46 <SumitNaiksatam> and LBaaS is going through a change
18:16:03 <SumitNaiksatam> so on the backward compatiblity
18:16:05 <s3wong> marios: servicebase maps one to one to each service instance; and servicebase holds the list of serviceinterfaces associated with that service instance
18:16:48 <SumitNaiksatam> i proposed a solution to marios (vpnaas) and sridaK (fwaas)
18:17:04 <SumitNaiksatam> marios: you are comfortable with that?
18:17:08 <marios> s3wong: right
18:17:26 <marios> SumitNaiksatam: i think it sounds sane right now, but we need to retain the router id for example (for vpn)
18:17:35 <SumitNaiksatam> marios: yes, we retain that
18:17:56 <marios> SumitNaiksatam: i think we can try stuff out and come back to it next week
18:18:01 <SumitNaiksatam> marios: i think we should strive to be as less intrusive as possible
18:18:05 <pcm___> sorry, as my connection dropped a bit. Is there a BP for this?
18:18:06 <SumitNaiksatam> marios: sure
18:18:27 <marios> apologies, have to put my 2year old to bed... hopefully brb
18:18:31 <SumitNaiksatam> pcm___: we are discussing the service base and insertion bp
18:18:42 <SumitNaiksatam> marios: no worires, thanks for joining
18:18:45 <pcm___> thanks
18:19:01 <SumitNaiksatam> pcm___: that includes the implementation for vpnaas, fwaas and lbaas
18:19:18 <hemanthravi> s3wong: are the new apis implemented in the new plugin or servicebase?
18:19:27 <Swami> sumitnaiksatam: can you post the link here, it would be useful.
18:19:32 <pcm___> goal being to have a common service?
18:19:42 <SumitNaiksatam> #link https://review.openstack.org/#/c/93128
18:19:45 <s3wong> hemanthravi: with SumitNaiksatam 's suggestion, the APIs would be on the new plugin
18:20:08 <hemanthravi> can't these be done in servicebase?
18:20:41 <SumitNaiksatam> hemanthravi s3wong: the REST APIs are handled in the new “service plugin”
18:20:56 <s3wong> hemanthravi: I don't think we have plugin for servicebase per se, though
18:21:00 <s3wong> it is abstract
18:21:02 <SumitNaiksatam> however, the service base will stil need to have these methods as well
18:21:23 <pcm___> SumitNaiksatam: Do the service's APIs come into the service base and then get forwarded to the respective service?
18:21:35 <s3wong> SumitNaiksatam: for other services to implement their own inherited methods?
18:21:58 <SumitNaiksatam> so the flow would be: REST call for creating service interface -> new “service plugin” -> fwaas service plugin
18:22:33 <SumitNaiksatam> pcm___: so the service base as defined in the spec stays the way it is (or may be a close variant of that)
18:22:46 <garyduan> Do we have a WIP patch about new "service plugin"?
18:22:47 <marios> SumitNaiksatam: so the point of the plugin is to maintain the association between fwaas_UUID and the interface, until that fwaas instance is inserted
18:22:51 <SumitNaiksatam> however, the service interface resource gets implemented in a new service plugin
18:23:13 <SumitNaiksatam> garyduan: perhaps you missed activity over the weekend, we just got the spec approved :-)
18:23:36 <SumitNaiksatam> marios: the main point of the new service plugin is to be able to honor the CRUD for the service interface
18:23:41 <garyduan> yes. I saw that, I wanted to +1, but it's already approved
18:24:11 <SumitNaiksatam> marios: since the existing plugins cannot be used to implement the service interface resource
18:24:18 <SumitNaiksatam> garyduan: np
18:25:02 <SumitNaiksatam> marios: otherwise you will have each of fwaas/vpnaas/lbaas implementing the same resource/extension
18:25:30 <SumitNaiksatam> marios: and the neutron manager (api layer) will not know which service plugin to send the call to
18:25:37 <garyduan> SumitNaiksatam: i see the implementation issue now
18:26:01 <garyduan> SumitNaiksatam: I should say, I understand the issue now
18:26:06 <SumitNaiksatam> garyduan: yeah, its a little difficult to explain in text here, hence i was saying it will be clearer with a WIP patch
18:26:15 <marios> SumitNaiksatam: thanks, a lot of this is still new to me
18:26:41 <garyduan> SumitNaiksatam: right. Look at the code is easier.
18:26:56 <SumitNaiksatam> marios: the side effect of the above is that we need to still dispatch to the fwaas plugin, and hence we need to know that a particular uuid in the service interface create call is a firewall object
18:27:12 <SumitNaiksatam> so we went much deeper into this discussion than planned
18:27:20 <SumitNaiksatam> #topic Service Chains
18:27:23 <marios> SumitNaiksatam: so then would 'create_service_interface' still need to  be implemented in each service, or is that what you're saying here. that this will be implemente3d in the service plugin only
18:27:29 <marios> (as an example)
18:27:39 <marios> SumitNaiksatam: nm
18:27:42 <SumitNaiksatam> marios: we would (the service base will change)
18:27:42 <marios> SumitNaiksatam: next tinme, sorry
18:27:46 <SumitNaiksatam> marios: thanks
18:27:59 <SumitNaiksatam> songole mandeep: ?
18:28:03 <SumitNaiksatam> quick update?
18:28:12 <SumitNaiksatam> i know cgoncalves you had questions on the spec?
18:28:16 <SumitNaiksatam> if we can keep it short
18:28:27 <mandeep> SumitNaiksatam: Sorry, I was pulled in a different discussion ...
18:28:30 <SumitNaiksatam> for this time, and we can continue the conversation later
18:28:36 <SumitNaiksatam> mandeep: no worries
18:28:58 <SumitNaiksatam> songole: my understanding is that you are on track for the implementation?
18:29:07 <SumitNaiksatam> implementation/WIP patch
18:29:23 <songole> SumitNaiksatam: yes. We are finalyzing on the plan
18:29:38 <SumitNaiksatam> songole: ok good, perhaps you can report next week
18:29:45 <songole> ok
18:29:48 <SumitNaiksatam> #topic Open Discussion
18:29:57 <mandeep> Yes, no new status update. There was a request from LouisF to allow for different forward and reverse paths, and we can look into that for a later versiion
18:30:08 <SumitNaiksatam> mandeep songole: thanks
18:30:12 <cgoncalves> SumitNaiksatam: sorry, lagged connection
18:30:20 <SumitNaiksatam> sorry, we did not get a chance to discuss traffic steering and Tap
18:30:34 <cgoncalves> SumitNaiksatam: what's the plan for implementing a PoC for SC?
18:30:35 <SumitNaiksatam> although my proposal is to still keep these on the agenda for this meeting leading into K
18:30:45 <LouisF> mandeep: i think the bp is incomplete as is
18:30:57 <cgoncalves> mandeep: maybe you can better answer to my question
18:31:03 <SumitNaiksatam> so next time onwards we wil try to give at least some time to these specs such that we dont have to restart the discussion later
18:31:34 <mandeep> cgoncalves: What was the question? I missed earlier part of the meeting.
18:31:34 <SumitNaiksatam> we are a little over time, so lets keep the discussion short, and we can continue over the mailer or next week
18:31:42 <mandeep> SumitNaiksatam: OK
18:31:49 <SumitNaiksatam> mandeep: cgoncalves is asking what is the plan for a PoC?
18:31:52 <cgoncalves> mandeep: plans on PoC for service chain
18:31:57 <SumitNaiksatam> mandeep: is there a time frame planned
18:32:06 <SumitNaiksatam> cgoncalves: i believe songole is also working on this
18:32:12 <mandeep> cgoncalves: Plan was to work on that (plan) this week
18:32:23 <cgoncalves> mandeep: ah! ok :)
18:32:29 <cgoncalves> SumitNaiksatam: nice, thanks
18:32:33 <SumitNaiksatam> mandeep: can we get something by next meeting?
18:32:57 <mandeep> SumitNaiksatam: Sure
18:32:59 <SumitNaiksatam> have a plan ready, say by tomorrow, and socialize in the next meeting (or earlier if you chose to use the mailer)
18:33:02 <SumitNaiksatam> mandeep: thanks!
18:33:11 <SumitNaiksatam> anything else?
18:33:11 <mandeep> LouisF: Can you email me the concern that you had?
18:33:22 <LouisF> mandeep: ok
18:33:23 <SumitNaiksatam> thanks all for reviewing the blueprints over the weekend
18:33:45 <SumitNaiksatam> hopefully it wont be the same rush with the reviews for J3
18:34:10 <marios> \o g'night all
18:34:23 <SumitNaiksatam> alright thanks all, and if you have any concerns please feel free to send me an email
18:34:26 <SumitNaiksatam> thanks all!
18:34:28 <SumitNaiksatam> bye
18:34:31 <songole> bye
18:34:31 <SumitNaiksatam> #endmeeting