18:00:39 #startmeeting networking_policy 18:00:40 Meeting started Thu Jul 17 18:00:39 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:42 hi 18:00:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:44 The meeting name has been set to 'networking_policy' 18:00:50 #info agenda: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy 18:01:01 #announcements Juno specification submission deadline: July 10th, specification approval deadline: july 20th 18:01:13 so the SAD is 20th and not 17th as i previously noted 18:01:36 i erred to the conservative side, so it gives us a couple of more days 18:02:02 i know we have the vendor driver blueprints, and kevinbenton’s API intercept spec 18:02:17 anything other spec that is pending review? 18:02:34 we will get to the vendor drivers later in the agenda (if we have time) 18:02:57 okay 18:02:59 does it look like ant of the vendor bps will get reviewed/approved? 18:03:05 I plan to spend much of the next few days reviewing specs, including these 18:03:06 any 18:03:11 rkukura: thanks 18:03:15 banix: i plan to review as well 18:03:30 banix: at my end i will be able to review before SAD 18:03:53 rkukura: you feel comfortable about that as well? 18:04:15 great. i have a question regarding our bp but will wait for tits time slot 18:04:23 no, but I’ll review as much as I can as soon as I can 18:04:43 rkukura: okay 18:04:51 banix: thanks 18:05:07 my goal is to make a pass thru everything important on GP and ML2 by mid-day tomorrow 18:05:27 i think the vendor driver specs are all pretty similar in that they proxy the group policy calls over to their respective backends 18:05:49 so i guess its pretty much like you review one, and the rest are all along similar lines 18:06:05 folks correct me if i am wrong, or if any of the vendors are planning to do something different 18:06:17 now that you ask :) 18:06:18 if its a longer discussion we can take it up in the relevant part of the agenda 18:06:55 we wwant to have a new attribute for claasifiers and are not sure if that would the approval complicated or not 18:07:05 i can wait; your call SumitNaiksatam 18:07:25 banix: thanks 18:07:26 SumitNaiksatam: no, it's as you described for One Convergence GBP driver 18:07:55 hemanthravi: ok good 18:08:01 #topic Gerrit Reviews 18:08:28 #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches 18:09:04 SumitNaiksatam: can you comment in response to Eugene’s question on the intercept patch about why inter-plugin calls need to be intercepted? 18:09:21 kevinbenton: yes i will 18:09:36 kevinbenton: sorry about the delay 18:10:02 just posting the above link for the benefit of anyone who is not familiar with the series and the stacking 18:10:46 SumitNaiksatam: no problem. If anyone else is interested in the discussion around the intercept, the patch is here. #link https://review.openstack.org/#/c/105695/ 18:10:56 kevinbenton: thanks 18:11:04 kevinbenton: i do have that as a separate agenda item 18:11:15 kevinbenton: your spec that is 18:11:24 SumitNaiksatam: whoops :-) 18:11:26 any questions/comments on the series/stacking? 18:11:29 kevinbenton: np 18:11:44 kevinbenton: thanks for putting it out there, if we run out of time, we know what to skip :-) 18:11:56 ok moving on 18:12:04 #topic Resource Model/API/DB/Plugin Update 18:12:12 no major update here 18:12:35 rkukura pointed out today morning that gp-db-1 and gp-plg-1 were out of sync with the master and needed rebase 18:12:40 so those have been rebased 18:12:51 +1 18:13:11 i have not added the db migration script yet since i did not want to introduces churn while rkukura was working on it 18:13:17 but i had to rebase anyway today 18:13:40 any questions on gp-api/db/plg/-1/2/3? 18:14:07 hopefully next update after this to the gp-*-1 and gpm-*-1 series will have the DB migrations and be ready to merge 18:14:08 for the naming conventions on the patches please refer to: #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches 18:14:38 rkukura: yes, db migration should be straightforward 18:15:08 also banix is working on some of the advanced UTs for the drivers 18:15:16 banix: thanks for the update yesterday 18:15:36 yes when appropriate i like to ask a couple of questions wrt UTs 18:15:46 banix: go ahead 18:16:19 looking at the comment rkukura left here: #link https://review.openstack.org/#/c/96393/9/neutron/tests/unit/services/grouppolicy/test_grouppolicy_plugin.py 18:16:52 In the tests I have added I use the dummy driver and patch it for each test accordingly 18:17:08 Does that make sense or I am missing something here? 18:17:25 rkukura: ^^^ 18:17:41 banix: makes sense to me 18:18:03 ok thanks; will share the code soon 18:18:23 banix: The ml2 tests probably could do something like that, but there is also some logic in the driver for the tests I think. Its been a while since I looked 18:18:40 banix: thanks! 18:19:00 ok moving on 18:19:12 #topic Mapping Model/Driver Update 18:19:17 rkukura: over to you 18:19:59 OK, I’ve been working to make the resource_mapping driver production-ready (relatively) so we can remove the WIP from gpm-rmd-1. 18:20:24 rkukura: whats the ETA on that? 18:20:28 It now handles all the cleanup for implicitly created resources, and does not cleanup explicitly created resources 18:20:39 rkukura: nice 18:20:50 rkukura: thats using a db table? 18:21:15 I have a bit more work to do on this to handle updates (rejecting things that don’t make sense for this driver), and validating a few things for explicitly-created resources. 18:21:24 I hope to push the non-WIP update later today. 18:21:32 rkukura: sweet 18:21:59 I’ve already pushed updates to gpm-api-1, gpm-db-1, and gpm-plugin-1 rebasing on Sumit’s latest updates. 18:22:36 I’ve got a couple minor review comments to address in gpm-ipd-1 and will push that update shortly. 18:22:43 then get back to finishing gpm-rmd-1 18:23:10 After that, I’ll shift my focus to spec reviews until Sunday 18:23:15 That’s it for me 18:23:19 rkukura: thanks for the update 18:23:35 any questions for rkukura? 18:24:00 SumitNaiksatam: i have question on EPG provided/consumed contract lists 18:24:01 rkukura: so the implicitly created resources are recorded in the db? 18:24:12 SumitNaiksatam: The resource_mapping driver uses DB tables to keep track of owned resources, just like the implicit_policy driver does. 18:24:20 rkukura: ok 18:24:25 LouisF: please go ahead 18:24:32 in the scenario where a EPG has provided contracts 1-10 and the client now wants to send an update to remove contracts 9, 10 and add 11 and 12, should the client send an update that includes contracts 1-8, 11, 12? 18:25:20 LouisF: I think we need to define add_contract and remove_contract operations for this, similate to the router’s add_interface and remove_interface operations. 18:25:29 in orher words an update must always include the itended list of contracts 18:25:41 intended 18:25:49 LouisF rkukura: yes thats the plan 18:26:04 Updating the entire list will work, but has race conditions of multiple clients try to update the same thing at the same time. 18:26:05 LouisF: i believe the way its currently structured you ahve to send the entire list 18:26:12 rkukura: yes agreed 18:26:22 LouisF: so we will add those extra API operations 18:26:39 LouisF: add/remove, we do something similar for the router interfaces and firewall rules 18:26:52 Speaking of these add/remove opetations, if anyone knows how to list all the interfaces of a router via the client API, please let me know. 18:26:52 LouisF: its not in the patch right now though 18:27:41 LouisF: does that answer your question? 18:27:52 hi 18:27:57 what if an EPG potentially have 100s of contracts? 18:28:02 mlavalle: thanks for joining 18:28:15 nice to be here 18:28:17 LouisF: you will have both options 18:28:30 LouisF: of bulk update and well as single updates 18:28:37 rkukura: query ports based on device_id = router_id 18:28:59 LouisF: however its questionable whether EPGs will have 100s of contracts 18:29:10 ok when will add/remove contract be added? 18:29:25 kevinbenton: I was hoping not to have to resort to that, but didn’t see a better way 18:29:44 LouisF: i was planning to add that as a separate follow up patch 18:29:50 may need to do this in the UTs to verify subnets get added to routers 18:30:18 LouisF: i prefer to keep this patch series with the basic CRUD operations to faciliatate reviews 18:30:29 rkukura: yes, i remember coming across in the code that unfortunately the only associate between ports and routers is held in that device_id field of the port 18:30:29 SumitNaiksatam: ok 18:31:14 ok moving on (since mlavalle is here) 18:31:21 #topic Functional/System testing 18:31:36 mlavalle: thanks again for joining at a short notice 18:31:40 :-) 18:32:06 mlavalle: so the team here wants to be able to introduce some functional/system tests to be able to test the group policy API and workflow 18:32:19 mlavalle: what do you recommend is the best path forward? 18:32:39 i was informed that the LBaaS folks have a patch for the new API? 18:32:55 yeah I developed that for them 18:33:12 mlavalle: oh great, so we are approaching the right person! 18:33:17 if I understand coirrectly, we have a rest api here, correct? 18:33:22 mlavalle: yes 18:33:47 mlavalle: it starts with this patch #link https://review.openstack.org/#/c/95900 18:33:49 so we can definitely go ahead and develop a set of tempest tests, both at the api l;evel and at the scenario level 18:33:58 mlavalle: ok good 18:34:11 mlavalle: i will jump on this right away, any pointers? 18:34:23 mlavalle: we can take it offline if this is a longer discussion 18:34:42 moving ahead, we can folow the following approaches 18:34:51 1) I csn develop the tests for you 18:34:59 mlavalle: sure 18:35:06 2) I can train someone in your team to develop the tests 18:35:13 or a combination of both 18:35:24 whicever you fill more comfortable 18:35:26 mlavalle: One concern is that the juno version of GPM is likely to be considered “beta” without guaranteeing backward API compatability with the K release, but that tempest isn’t branced. Is this an issue? 18:35:29 mlavalle: in the short term we will have to use (2) 18:35:52 in any case, I will provide support 18:36:07 mlavalle: thanks! lets first address rkukura’s question and then we can work out logistics 18:36:36 rkukura: that's not a problem, we can evolve the tests as the api evolve 18:36:53 mlavalle: I recall marun proposing developing tempest-like tests in the neutron or some other repo to deal with this. 18:37:29 rkukura: yes, that's also a valid approach. however, since we will have a rest api, at some point in tume we will need tempest tests 18:37:56 mlavalle: So if these tests get merged to tempest during juno and then the API changes in K, how do we deal with it? 18:38:14 We don’t want to break running tempest against juno. 18:39:52 mlavalle: rkukura’s question ^^^? 18:40:21 rkukura: yeah….. I see your point…. maybe we should hold off developing the tests in tempest for the time being 18:40:39 let me bring this up with the tempest team and i'll get back to you next week 18:40:43 how's that? 18:40:45 I’m not arguing against putting our tests in tempest from the start, as long as that isn’t preventing us from making API changes that aren’t backwards compatible during K 18:41:01 mlavalle: so how is this being addressed for the new lbaas api/resources? 18:41:13 Should we start with a WIP patch for tempest tests in the mean time? 18:41:16 mlavalle: i am guessing the new api is beta over there are well? 18:41:22 rkukura: exactly 18:41:36 rkukura: yeah, I understand…. in the case of LBaaS we are working with WIP patches 18:41:38 rkukura: i was thinking the same, at least the WIP will allow people to test 18:41:44 we can do the same here 18:41:47 rkukura: doesnt have to be merged 18:42:03 mlavalle rkukura: ok great, lets have the WIP patch 18:42:06 everyone agree? 18:42:09 +1 18:42:13 +1 18:42:19 +1 18:42:55 ok great, so mlavalle i will sync with you, so that we have something at the earliest 18:43:10 our requirement is that something be ready by next week so that people can test it right away 18:43:15 moving forward with the tests, I think I can help extending the tempest rest clients and then have someone in your team develop the tests themselves 18:43:29 we have a pending -2 and part of it is ostensibly for this 18:43:36 mlavalle: nice 18:43:54 mlavalle: since we are running short on time here, i will sync with you and we can report progress in the meeting next week? 18:44:09 cool. I'll wait for your ping 18:44:17 :-) 18:44:22 SumitNaiksatam: Can we target the tempest REST client at just the initial 4 resources in gp-*-1 to get this going quickly? 18:44:27 mlavalle: thanks much! 18:44:29 thanks mlavalle 18:44:43 rkukura: precisely, just those first four 18:45:16 rkukura: i was thinking for now we will do only what we need to for the first series 18:45:23 +1 18:45:40 +1 18:45:40 ok moving on 18:46:07 #topic Security Groups mapping update 18:46:14 we needed more time for this 18:46:19 s3wong: sorry about that! 18:46:27 s3wong: but please go ahead 18:46:32 in the interest of time, I will only give a four lines update: 18:46:37 i know regxboi had commented 18:46:43 s3wong: please 18:46:58 thanks for LouisF and regXboi for their comments on doc, I responded to them and will update doc accordingly 18:47:59 I have an action item on checking multiple SG per port: turns out it is one of the basic operations according to OpenStack doc: 18:48:00 s3wong: can you clarify what you mean about the FW? 18:48:03 http://docs.openstack.org/admin-guide-cloud/content/securitygroup_workflow.html 18:48:26 LouisF: Firewall as in FWaaS instance 18:48:33 yes 18:49:23 and the last line of update: I pulled a branch off of rkukura 's latest RM gerrit and will start coding some basic stuff 18:49:45 the goal is to have at least some starting point prior to next week's hackathon 18:49:58 four lines of update :-) 18:50:20 that was 7 actually 18:50:30 s3wong: I’ll be in the bay area Monday-Thursday, and may be able to get together with you to work on this prior to the hack-a-thon if that helps 18:50:35 banix: well, you have to ignore LouisF 's question, that wasn't expected :-) 18:51:04 rkukura: certainly. we can set this up offline later. That would be great 18:51:36 s3wong: is everything in the document now? 18:51:40 s3wong: OK, probably late Monday or sometime Wednesday is best for me 18:51:44 s3wong: i did not read the latest update 18:51:51 s3wong: just want to know before you start coding 18:52:18 SumitNaiksatam: the content + my response to comments 18:52:34 SumitNaiksatam: I will update the doc later also 18:52:36 s3wong: okay i will check back, apologies for not getting back to you earlier 18:52:49 SumitNaiksatam: it's alright - can't get mad at cores this week :-) 18:52:58 s3wong: does it address regxboi’s comments? 18:53:00 s3wong: i read the update 18:53:07 SumitNaiksatam: yes 18:53:13 s3wong: okay sweet 18:53:23 LouisF: any further questions? (if so, please further comment on doc) 18:53:37 s3wong: will do 18:53:40 ok can we move to the vendor drivers? i know banix wanted to discuss 18:53:43 we would like to give 7 minutes to vendor drivers, I suppose 18:53:45 ok moving on 18:53:50 yes 18:53:53 #topic Vendor Drivers 18:54:05 we have six vendor drivers’ specs in review 18:54:22 check #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#July_17th.2C_10th.2C_2014 for the list 18:54:25 banix: go ahead 18:54:39 we might be able to go a little over in this meeting (if we are not kicked out) 18:54:44 as mentioned earlier we want to have a new attribte for classifiers; am wondering if adding that to the spec would cause any complications 18:55:05 banix: okay, yeah we had this disucssion last week with regxboi 18:55:18 banix: at this point i dont foresee any issues 18:55:25 banix: is that the mcast address match? 18:55:37 banix: that said, the leaner the spec the easier to review and approve 18:55:41 so this will modify the model to add a new attribute 18:55:45 s3wong: yes 18:55:53 banix: so add it only if you absolutely need it 18:56:12 banix: you dont need to modify the model, you extend it 18:56:27 SumitNaiksatam: ok; ye, thatis what i menat 18:56:30 meant 18:56:38 banix: yes sure :-) 18:56:58 rkukura: what do you think? 18:57:01 ok thanks 18:57:10 since you will be reviewing as well 18:57:25 not sure we want to go there, but I’ve been helping out on a spec for adding an ExtensionDriver API to ML2. We could do something similar. 18:57:55 rkukura: the idea is that for the ibm driver, banix will be extending the classifier resource to be able to add a field for multicast protocol 18:58:22 rkukura: banix needs this in Juno, i believe 18:58:36 rkukura: so i dont think any dependency will work for him 18:58:37 rkukura: The extension mech you are proposing is probably post Juno, correct? 18:58:44 I would suggest to keep the framework here generic enough such that other vendor drivers can extend in future if rquire 18:58:53 No, its needed for a spec already approved for Juno 18:59:04 rms_13: it is 18:59:13 cool 18:59:52 sorry I missed the mention, but was there any decision on merging tests to tempest for the new api? 19:00:04 rkukura: In Juno for ML2, I was asking about the timeframe for a similar mech for GBP post Juno 19:00:11 marun: we will be posting a WIP patch 19:01:00 SumitNaiksatam: sounds good. I don't think experimental features should have tests in tempest (and we can have similar coverage in-tree anyway), but we can always rework the WIP to be in-tree instead of in tempest before merge. 19:01:12 marun: Whether merging the tempest patch would lock-down the API post-juno is an open question that mlavalle is going to look into 19:01:18 marun: exactly 19:01:39 marun: this will help whoever wants to test this 19:01:43 rkukura: the discussions that I've had on the tempest side have indicated that api testing in tempest is for preventing backwards incompatible changes 19:01:51 marun: but does not have to be merged 19:01:54 rkukura: i.e. stable APIs 19:02:07 SumitNaiksatam: understood, definitely a good step. 19:02:28 marun: ok thanks 19:02:46 rkukura: so if we expect an API to not be stable, merging to tempest takes valuable qa cycles unnecessarily. 19:02:49 mlavalle: ^^ 19:03:04 (it's also more expensive for us) 19:03:22 so we are over time, and we are here until we are kicked out 19:03:38 marun: That’s why we are asking these questions, but it seems a WIP tempest patch will let us get started quickest. 19:03:52 rkukura: completely agree that it is a good starting point 19:04:33 #agreed Group Policy team will introduce WIP tempest patch to aid in end-to-end testing of the stacked patches 19:04:36 rkukura: the retargetable spec was just merged and the code hasn't yet, so api testing in-tree is not ready yet. 19:04:47 banix: So back on the issue of extending resources for your plugin, my recommendation is that you should to do that. We can have a more generic mechanism in future (modeled on ML2, depending on that experience), but you should not depend on that for the Juno plugin. 19:05:00 marun: One consideration would be that if we know this won’t go into tempest anytime soon, maybe we should use python-neutronclient instead of the tempest REST client. 19:05:11 rkukura: but I do expect to have the ability to start merging in-tree API tests in juno-3 19:05:13 mandeep: thanks for directing back to the topic in discussion here 19:05:19 rkukura: no, the tempest rest client is the way to go 19:05:38 rkukura: see mandeep’s suggestion ^^^ , does that work for you? 19:05:45 rkukura: I'm working with dkranz to refactor the tempest client so that we can implement it against the plugin api 19:05:46 mandeep: agreed regarding the extension dricer 19:05:49 driver 19:05:51 mandeep: ok 19:06:04 rkukura: that would allow tests in the tempest tree written for the rest client to be trivially portable to our plugin api 19:06:16 rkukura: that won't be possible with the native client 19:06:45 marun: That is useful for API tests, but our initial focus is really on end-to-end system tests with nova, tempest, … 19:06:51 rkukura: 19:06:52 https://review.openstack.org/#/c/106916/ 19:06:56 s/tempest/keystone/ 19:06:57 ok banix mandeep rkukura so we are agreeing that banix you will use resource extension for now in your driver, and later resort to a more generic mechanism for drivers as and when that evolves 19:07:11 rkukura: there's nothing stopping that from being maintained in our tree either 19:07:31 SumitNaiksatam: If he really wants an extension, he might need the kind of thing we are planning for ML2 19:07:32 SumitNaiksatam: sounds good 19:07:56 rkukura: Yes, post Juno. 19:08:03 rkukura: but I'm less clear on how scenario tests for experimental features should be handled by tempest 19:08:29 It basically calls the extension driver to validate extended attributes, persistent them, and put them in resource dictionaries for Context objects and responses. 19:08:44 rkukura: in any case, there has been discussion on the list about deprecating the use of the native python clients in scenario testing because they make debugging so much harder 19:08:58 marun: I will bring up the issue of scenario tests for experimental features during next week's tempest meeting 19:09:20 rkukura: i think given the short time frame for Juno, i would not want to block a vendor driver for a framework which is evolving in another part of the code base 19:09:50 rkukura, mlavalle: http://lists.openstack.org/pipermail/openstack-dev/2014-July/039879.html 19:09:53 just a note - we are currently discussing the “vendor driver” agenda item in our topic 19:09:57 mlavalle: appreciated 19:10:02 marun: I’m not really concerned about which client is used for these tests, but just want to make sure we have a short term plan for end-to-end system tests were we really validate correct connectivity between VMs. 19:10:20 rkukura: there's nothing stopping us doing that for VMs in functional tests. 19:10:25 the tempest topic was discussed earlier, and we can circle back once we are done discussing the current agenda item 19:10:30 rkukura: VMs -> fake VMs 19:10:59 rkukura: I know I keep talking about this, I haven't had specific use cases to implement and I was supposed to get back to you about this a couple of weeks ago. 19:11:31 rkukura my earlier point - i think given the short time frame for Juno, i would not want to block a vendor driver for a framework which is evolving in another part of the code base 19:11:32 marun: Certainly need running neutron-server, l2-agent, l3-agent, and dhcp-agent at least. 19:11:36 rkukura: I'd be up for proving this idea if I can get a detailed-enough description of test planning 19:11:41 rkukura: do you agree? 19:12:04 rkukura: sounds entirely like overkill for a feature that rides on top of the existing infrastructure 19:12:29 rkukura: it would be more valuable to write functional tests for those pieces without group policy and then add group policy to the mix 19:12:29 SumitNaiksatam: I think we’d have to incorporate the “extension” as part of the GP API. 19:12:42 rkukura: imho 19:13:20 rkukura: i am not sure i understand that 19:13:36 marun: I’m not disagreeing with any of that, but we have a very short term requirement to have some sort of end-to-end system testing. Just trying to find the quickest path to that. 19:13:53 rkukura: the suggestion was to have a separate extension module which will extend the policy classifier resources 19:13:57 *resource 19:14:00 rkukura: We are running out of time, so let us discuss this right after the meeting. At this stage, IMO it is too late to propose a chnage to GBP API for Juno. 19:14:24 mandeep: i dont think a change to the GBP API is required 19:14:27 rkukura: fair enoujgh 19:14:36 ok i think we are having two separate meetings here 19:14:38 SumitNaiksatam: There would need to be code somewhere that handles these extended attributes. The extension driver is what we are proposing to do this in ML2. 19:15:22 rkukura: that can be in the vendor’s driver, right? 19:15:28 keeping what s3wong mentioned about this week in mind. 19:15:28 Lets not forget that this is an iterative process, and details in the specs will often get revisited/changed during development. 19:15:30 rkukura: I believe that the right model is to implement it in ML2 in this cycle, and use that learning to extend GBP plugin in the next cycle 19:16:00 rkukura: sure 19:16:04 SumitNaiksatam: The drivers do not have a mechanism to handle the persistence of new attributes. 19:16:50 mandeep: I agree, but I’m not sure there is a short term solution for banix for juno. 19:16:55 rkukura: i think what you are saying is that the resource extension cannot be supported if its not added to the GP plugin 19:17:04 rkukura: OK, I understand your point now 19:17:32 ok lets take this offline and see what is the best way to approach it in the short term 19:17:34 rkukura: yes i understand your point and gree 19:17:38 I was under the impression that the drivers have a mechanism to handle this 19:17:48 #topic open discussion 19:17:59 That’s what we’ve concluded on ML2, which whose mechanism drivers have the same model. Initially some changes to the mechanism driver API were proposed, but even that did not allow extended attribute values to be returned in REST responses. 19:18:11 we skipped a couple of items 19:18:20 anything we wanted to discuss urgently? 19:18:30 extending the model will require changing the plugin which is itself under eview hence the complications 19:18:43 ok thanks for the commnts rkukura mandeep and SumitNaiksatam 19:18:48 kevinbenton earlier pointed out the API intercept spec patch: https://review.openstack.org/#/c/105695/ 19:18:53 banix: yes 19:19:02 banix: If the extension driver gets into ML2 for juno, I’m confident copying it into GP would be trivial. 19:19:09 banix: there has to be some place to load the plugin 19:19:22 * load the extension 19:19:34 ok so we are 20 mins over 19:19:38 anything else? 19:19:50 alternatively one could have a separate service plugin altogethr. right? 19:19:57 banix: yes 19:20:09 so just a reminder, we have the hackathon next week 19:20:22 so we will most likely not be doing this IRC meeting next week 19:20:30 hope to see you all these 19:20:32 if possible google hangout will be good 19:20:33 *there 19:20:36 banix: That would let you add new resources, but not extend GBP resources 19:20:43 banix: yes sure, we will plan something along those lines 19:21:11 rkukura banix: lets take this offline and find a solution 19:21:17 thanks all, bye! 19:21:20 bye 19:21:21 #endmeeting