17:30:35 #startmeeting Networking Advanced Services 17:30:35 Meeting started Fri Jun 27 17:30:35 2014 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:30:38 The meeting name has been set to 'networking_advanced_services' 17:30:45 #topic Flavor Framework Conclusions 17:31:03 Hopefully by now most people ahve read both proposals from enikanorov and markmcclain. 17:31:10 mestery: yes 17:31:20 What I'd like to see here is we come to an agreement on these which moves us forward for Juno. 17:31:22 markmcclain: thanks for posting yours 17:31:27 markmcclain: Yes, thanks for posting that! 17:31:34 hi 17:31:45 mestery: +1 17:31:53 sorry it took so long.. connectivity in west montana wasn't so good :) 17:32:24 I think banix and enikanorov made some good attempts at summarizing hte key differences between the proposals in comments on markmcclain's spec. 17:32:38 I think first of all, we're all in agreement we want flavors in Juno, right? :) 17:32:51 mestery: yes! :-) 17:32:54 yes 17:32:56 yes 17:33:01 mestery: +2, A 17:33:11 yes 17:33:24 yes 17:33:25 I also think we need to move forward quickly on this, given where we're at and the time left, so something simple which can grwo in future releases makes sense. 17:33:40 After saying all that, where should we start on coming to a conclusion here? :) 17:34:15 yes time is critical here 17:34:23 the approaches are quite different, to me it doesn't seem that one is simpler then the other 17:34:47 so basically it's about doing something that could be easily extended later 17:34:52 should we first looks for things which are obvious and we certainly want to do as a first iteration? 17:35:03 *look 17:35:23 SumitNaiksatam: yes that was make approach when I stepped back last week to look at the problem anew 17:35:26 enikanorov: Agreed, something simple for now which allows for expansion in the future. 17:35:33 markmcclain: great! 17:35:33 s/make/my/ 17:36:07 so we have been all talking about differences, what are the common things between the two proposals? 17:36:18 is the user facing API consistent across the two 17:36:27 SumitNaiksatam: yes 17:36:33 it's flavor_id on the service instance 17:36:46 but that's integration part, I'd say 17:37:04 enikanorov markmcclain: so what the user sees as a part of the flavor definition is the same across both the proposals? 17:37:16 SumitNaiksatam: that's no so similar 17:37:22 (i have read the proposals, but just want to make sure that we are all on teh same page here) 17:37:27 yeah we agree on attaching flavor_id to the logical service and also once it's bound dispatching calls directly to driver 17:37:38 in markmcclain's proposal user sees description, in my proposal user sees tags as more formal contract 17:38:04 markmcclain enikanorov: can we potentially add tags later as a second iteration enhancement? 17:38:11 enikanorov is correct, my proposal also exposes the set of API extensions available for a flavor (ie TLS, L7) 17:38:25 SumitNaiksatam: yes 17:38:28 extension list is questionable, imo 17:38:29 SumitNaiksatam: +1 17:38:32 markmcclain: ok cool 17:38:40 why do coarse grained when we later move to fine grained? 17:38:47 I think it's less questionable than tags. :P 17:39:15 the problem is that most drivers going to implement all extensions 17:39:33 if two drivers implement SSL, but different cyphers 17:39:36 ... 17:39:43 that's where tags help 17:39:50 or the description. 17:39:52 that just one example of many 17:39:53 enikanorov: i think the claim is that coarse grain is currently simpler to achieve in Juno, but does not leave out the eventual path towards fine grained 17:40:02 SumitNaiksatam: +1 17:40:04 +1 17:40:09 markmcclain: is that an accurate assessment? 17:40:11 considering implementation - it's not 17:40:14 We can always formalize the contract over time 17:40:47 also, each author sees implementation of his proposal to be simpler :) 17:40:55 enikanorov: :-) 17:40:58 I also agree tag will be difficult to control 17:41:01 the next thing is driver profiles 17:41:08 enikanorov: human nature :) 17:41:13 where metadata seem to be the same tags as in my proposal 17:41:31 but I'd like to understand more how metadata works 17:41:49 enikanorov: +1 17:41:52 enikanorov: would it be conceptually possible to think of profiles as a set of tags? 17:41:59 so metadata is a dict of driver specific parameters passed at driver init time 17:42:03 banix: yes, i think it's close 17:42:07 banix: That's kind of what I was thinking as well 17:42:34 so the problem for operator then that he needs to know driver specific details 17:42:35 the metadata is really designed to toggle behavior in a driver to match the profile's description/sla 17:42:37 so can we agree on using the spec as teh vehicle for carrying the info, tags or metadata? 17:42:42 banix: That is what I was thinking as well 17:42:42 markmcclain: the idea being that drivers won't necessarily share the same specific parameters 17:42:46 it could be just a set of tags, or it could configure the driver slightly different for each flavor (simple example, you tell driver A to use backend hosts 1-2 for flavor X and hosts 3-10 for flavor Y). 17:42:50 even if they are implementing the same "feature" 17:43:03 enikanorov: operators already know that info because most go through selection process when purchasing equipment 17:43:15 sbalukoff: +1 17:43:26 markmcclain: right, but metadata should really be bound to implementation, e.g. code 17:43:27 dougwig: yes 17:43:30 markmcclain: metadata is created by admin,right? 17:43:40 it's not purely ask-API-create-flavor 17:44:07 so it really requires introspection into how it's done on the inside 17:44:17 enikanorov: no it is configuration options or it could even be a pointer of where to read in config file 17:44:20 you can't just pass anything 17:44:23 garyduan: yes 17:44:35 yep, the pointer of where to read is better 17:45:03 enikanorov: Why can't you just pass anything? 17:45:06 enikanorov: the operator does not have to read the code, just understand the init options a vendor might offer 17:45:14 but then it's just the same as to use tag from a flavor to do the same 17:45:22 markmcclain: does driver need to expose anything? 17:45:26 markmcclain: This is similar to what they'd need to put in a config file when using the driver, right? 17:45:27 sbalukoff: because it makes no sense for the driver 17:45:28 ie pass ha=true at initialization time to ensure the backends creates pairs 17:45:52 markmcclain: ok, that's a tag. and it's on a profile 17:46:00 whynot have two ways of specifiying service parameters tagOr metadata and point to a location where you can find key,vals or whateber minimum per service 17:46:01 garyduan: no drivers should not need to be aware of flavors at this time 17:46:02 enikanorov: It does if the driver knows how to interpret the metadata passed to it. :P 17:46:04 so why not to put it on Flavor so user see it, formally? 17:46:04 mestery: yes 17:46:17 pgpus: two ways = confusion 17:46:18 I think the issue will be with tags that you have no formal description of what the tag means. Clearly it means a function is supported, but how do you document what that means in practice? 17:46:34 ijw +1 17:46:36 markmcclain: that makes sense to me. 17:46:38 ijw: but that problem is not solved 17:46:51 ijw: we now have the operator figure that out 17:47:00 ijw: +1 17:47:03 It's not the operator that cares: it's the tenant. 17:47:13 Extensions are self-documenting but per enikanorov's point they can't possibly catch nuances. 17:47:18 tags are self-descriptive via their names 17:47:20 enikanorov: it's not put on flavor because that exposes specific details of the implementation backend and may not be the same for multilple vendors 17:47:24 ijw: but operators are the one exposing metadata here, right? 17:47:43 s3wong: yes, but wouldn't you like those tags to be cross-operator? 17:47:56 I'd agree operator should define the tag or metadata 17:48:00 s3wong: I don't think tenants get to see the metadata 17:48:01 markmcclain: yes, that's why specific details are kept in driver's config 17:48:10 ijw: standardizing the set of tags and letting everyone implement will take time 17:48:12 s3wong: So that's not actually exposed to the tenant. 17:48:13 while on flavors only generic stuff like 'HA: True' is set 17:48:13 I mean, surely the point here is 'I want a service X supporting Y' and whoever I ask it of I get a service that suits my purposes. 17:48:17 if he/she says the driver support L7, the drivers supports L7 17:48:27 markmcclain: yup - I'm not really solving your problem, I'm trying to define it 17:48:28 ijw: if tags are exposed by drivers, then driver-tags would be cross-operator 17:48:33 ok, can i summarize from a user facing API perspective, that the main difference between the two proposals is that in markmcclain’s proposal the meta-information is not exposed to the user, the operator configures that 17:48:40 where as in enikanorov’s proposal 17:48:49 it gets exposed as tags within the flavor 17:48:50 s3wong: only if drivers agree what those tags mean, and that's the definition issue I'm referring ot. 17:49:04 SumitNaiksatam: correct 17:49:07 tags are implementation-agnostic definitions of the service 17:49:09 and the user can choose the flavors based on the tags 17:49:16 sbalukoff: right, but operator would need to set metadata as part of what features drivers can expose, thus a manual process 17:49:20 so no impl details sneak into flavor 17:49:31 markmcclain: ok 17:49:47 enikanorov markmcclain: hence my earlier suggestion, can we add tags as a second iteration enhancement 17:49:55 ijw: that has always been the question on enikanorov 's proposal - that we as community would have to define some common tags per service type 17:50:00 enikanorov markmcclain: that way we can have the best of both proposals 17:50:08 s3wong: Defining what products an operator wants to offer is going to be a manual process in any case. ;) 17:50:12 SumitNaiksatam: right. so the difference is granulaity of what tenant sees; markmcclain shows well defined limitted number of extensions enikanorov shows fine grained properties 17:50:15 s3wong: and if they're common tags, are they not attributes of the implementation? 17:50:16 enikanorov markmcclain: we can start with somethin “simpler” 17:50:20 SumitNaiksatam: right tags can be added later once we have standard set 17:50:33 markmcclain SumitNaiksatam: +1 17:50:45 enikanorov: does that seem reasonable? 17:50:47 I think we need something simple for Juno at this stage. 17:50:50 ijw: yes, they would be 17:51:00 i have a couple more questions 17:51:20 one is do we really need driver entry poins in driver profile? 17:51:36 i think current provider framework can be used for this purpose 17:51:37 enikanorov: same question here 17:51:41 every service needs to be managed by driver so why not just expose managment parameter and leave alone vwndor variations and just provide basic defalt services we have like FW,LB, VPN etc 17:51:44 sbalukoff: that's a fair point :-) 17:51:47 enikanorov: one sec 17:51:56 enikanorov: let’s see if we can get an agreement on the API as SumitNaiksatam was suggesting 17:52:00 lets all first have agreement on the tenant facing API 17:52:04 banix: yeah 17:52:20 we will get to the admin side of the API in a but 17:52:22 bit 17:52:29 SumitNaiksatam: +1 17:52:32 enikanorov markmcclain mestery: what say? 17:52:38 well, not having tags on the flavor actually creates another question i was going to ask 17:52:51 SumitNaiksatam: I think we're close on this front, so yes. 17:52:57 I think from user perspective yes 17:53:28 mestery markmcclain: cool 17:53:33 enikanorov: whats your question 17:53:49 do we really need to associate flavor with driver profile 17:54:01 but it seems that if no tags - we have to do that 17:54:12 but scheduling would not make much sense then 17:54:16 enikanorov: right there has to be some kind of association layer 17:54:36 enikanorov: yes. need the association. will still have a list of possible choices 17:54:36 because from flavor perspective there's no hint to use when choosing from associated profiles 17:54:39 which enables an operator to make a flavor to several possible backend implementation options 17:54:49 enikanorov: it is a list of driver profile though, not really one to one mapping, so some sort of scheduling still needed, right? 17:55:01 but what would be the criteria other than random choice? 17:55:05 Take the case of nova flavor did we really tie it to the drivers there? 17:55:05 enikanorov: german has pointed out that I had left weight off as an initial metric of the list 17:55:09 enikanorov: perhaps in the first iteration this will be limited without the hints/tags 17:55:16 * markmcclain pushed update with that 17:55:29 markmcclain: do you agree ^^^? 17:55:30 yep, i've seen update with weight, but... 17:55:38 what does it solve? 17:55:51 are you going to get max weight each time? 17:55:59 s3wong: yes there is a selection call to bind flavor to a driver 17:56:00 Right, so to be clear, the question is: a tenant has requirements that are met by several available service implementations: what should happen. Is that right? 17:56:12 weight is actually a hardcoded kind of tag 17:56:32 enikanorov: enables operator control to say set a preference that backend A should be preferred over backend B 17:56:44 *implementation A over B 17:56:46 enikanorov: Not the same kind of tag that's in your proposal 17:56:55 sbalukoff: the same, indeed 17:57:07 pgpus: nova can still bind because of extra data for flavor 17:57:09 markmcclain: but how impl B is ever chosen? 17:57:18 it it's weight is lower 17:57:42 enikanorov: depends on selection algorithm 17:57:50 I've also intentionally kept it simple too 17:58:05 because I think that making a really good one is a great future BP :) 17:58:12 well, that's important, because simplest is random choice 17:58:14 for example, round-robin in first release 17:58:22 enikanorov: where there is no more resources for backend A? 17:58:26 No, actually simplest is offering the tenant the choice. 17:58:27 weighting scheduler need to consider capacity or something 17:58:32 s3wong: exactly 17:58:36 Or weighted round robin 17:58:43 Or weighted random choice. 17:58:44 enikanorov: i think its okay to have limitations in the first release 17:58:57 as long as we know what they are, and we have path towards evolution 17:59:03 ijw: The tenant should have no view of resources, only logical entities after they have been scheduled 17:59:08 in this case the path is to to incoroporate tags 17:59:09 Folks: Scheduling needs to be dirt simple for Juno or this won't land, that's the reality at this point. 17:59:12 mandeep +1 17:59:15 can you sggest what extra data for flvor is equivalent for neutron to tie it to neutron plugins? is it metadata/ 17:59:16 if driver A has no resource, it can be feedback to plugin and select the next one 17:59:19 I don't want to rathole on scheduling here either. 17:59:25 i mean that's just a workarounds for the fact that 'naked flavor' is not a scheduling hint 17:59:40 mestery: Good point. 17:59:40 mestery: +1 17:59:47 mestery: +1 scheduling is for Paris :) 17:59:50 markmcclain: :P 17:59:59 ok lets get an agreement here 18:00:02 hang folks 18:00:07 * hang on 18:00:14 i think its okay to have limitations in the first release 18:00:14 SumitNaiksatam: Whew, had me worried there ;) 18:00:21 as for something simple - I remember avishay's patch where he enabled driver to choose it's configuration based on provider name 18:00:24 as long as we know what they are, and we have path towards evolution 18:00:36 that's actually very close to what is called driver profile 18:00:37 SumitNaiksatam: +1 18:00:38 in this case the path is to to incoroporate tags 18:00:46 as a future iteration 18:00:52 enikanorov markmcclain: can we agree? 18:01:01 this is in the context of the user/tenant facing API 18:01:17 SumitNaiksatam: +1 18:01:28 markmcclain: great, enikanorov? 18:01:29 yep, as simple first step we may just introduce flavors layer on top of providers 18:01:34 you service profile's path and that service prpofile will have tags? 18:01:35 enikanorov: i know this is not ideal 18:01:42 enikanorov markmcclain: nice 18:01:45 may be with just 1:1 and no scheduling and such 18:01:55 enikanorov: nice 18:01:59 markmcclain: how does it sounds? 18:02:12 then we could flush out what we really want from driver profiles 18:02:31 enikanorov: operators need more than 1:1 18:02:36 markmcclain: sure 18:02:50 markmcclain: +1 18:02:54 but at least we'll get user-facing api more or less stable 18:03:08 and then extend this with other more advanced features 18:03:36 in terms of implementation that seems to be the simplest. plus migration is also simple, as well as operators workflow 18:04:08 so service profiles are must 18:04:29 that's solvable with providers 18:04:30 because the mutli-vendor requirement why we started the who flavor discussion in the first place 18:05:06 I have questions about profile, but I want to wait until we get there :-) 18:05:37 markmcclain: so i agree, i'm just saying someone already impemented the idea very close to driver profiles 18:05:51 that coudl be reused and merged with flavors 18:05:52 OK lets take a sample service profile for existing FW,LB,VPN as see if this makes sense 18:05:59 enikanorov: sounds like you're agreeing about profiles, just not where to put them? 18:06:19 markmcclain: so we both get rid of provider attribute on the service instance, plus not too much changing the existing flow 18:06:59 dougwig: i'm not opposed to profiles, just honestly it is possible right now with very small changes in the code 18:07:04 What should a fw profile conatin like neutron firewall-list 18:07:04 neutron firewall-policy-list 18:07:04 neutron firewall-rule-list 18:07:22 that's however has another issues listed in markmcclain's proposal in the beginning, but with flavor layer it is solvable 18:07:49 pgpus: firewall itself is the service instance 18:08:11 sounds like we have reached an agreement. right? 18:08:30 will flavor and proivder type be able to express these in profiles in terms of some unit of measure to say like weight vwe discussed for user to undertsand which profile they pickup? 18:08:48 banix: Seems like it. 18:08:57 I think so 18:09:04 the one contention seems to be profiles 18:09:21 which are a evolved form of providers 18:09:27 markmcclain: I'm for using current workflow with keeping it in conf 18:09:42 at least for now 18:10:03 with flavors we are able to solve issues of providers 18:10:05 I think there a benefits to keeping providers in the DB and not in conf. 18:10:11 Er... not in conf files. 18:10:17 enikanorov: are you saying 1:1 mapping between profile and driver? 18:10:35 profile:driver is N:1 18:10:42 driver may have multiple profiles 18:10:54 we will have to re-invent like ml2 an mlProfile 18:11:03 that my question, 18:11:31 Mark's spec says, metadata can be used by driver to behave differently 18:11:35 enikanorov: it is more likely n:m - same profile may be provided by multiple drivers as well 18:11:52 mandeep: +1 18:11:58 enikanorov: my only concern about keeping current provider conf is there's no operator control 18:12:04 mandeep: Not if metadata is driver-specific 18:12:09 mandeep: that's more complex. not sure that would be easy with storing profiles in config 18:12:16 sbalukoff: that is just a special case 18:12:25 markmcclain: the control of what? 18:12:27 SumitNaiksatam: exactly 18:12:30 mandeep: oh really? if so, how is metadata passed - because that needs to be driver specific? 18:12:32 sbalukoff: mandeep’s suggestion for n:m includes that 18:12:36 which provider is selected 18:12:38 sbalukoff: n or m is 1! 18:12:52 markmcclain: how's it different from your proposal besides the fact that it is configured in conf, not by API? 18:13:14 the original reason we started with flavors months ago was the operator need for multi-vendor/multi-driver for same SLA 18:13:22 folks, sorry for interrupting 18:13:33 have we moved on from the user/tenant facing API discussion? 18:13:38 SumitNaiksatam: No, what I mean is, if the metadata in the profile is only meant to be interpreted by one driver, then that profile can only apply to one driver. Are y'all suggesting the metadata might be not driver-specific? 18:13:45 SumitNaiksatam: yes 18:13:46 sorry for repeating this over and over again 18:13:55 markmcclain: as we discussed, flavors associated with providers, which ae actually a driver profile 18:13:56 so I think we have agreement on user API 18:13:59 markmcclain: ok cool 18:14:05 sbalukoff: that was my question above as well... to me it seems n:1 18:14:07 mestery: can we summarize the agreement? 18:14:12 s3wong: I expect that common profiles (say providing cookie rewriting), will be implemented by multiple backends. That is whjat allows you to reschedule a tenant to a new backend transparently 18:14:13 SumitNaiksatam: yep, i think so as well 18:14:18 SumitNaiksatam: i think the only remaining question is driver in profile or not issue 18:14:25 enikanorov markmcclain: perhaps you can summarize 18:14:34 SumitNaiksatam: Yes, lets have enikanorov markmcclain summarize :) 18:14:52 so there's agreement that the user will select a flavor 18:15:01 that's for sure :) 18:15:05 :-) 18:15:12 flavor definition will include list of API extensions 18:15:33 the API extensions will be used to activate logic in teh server for configuring the logical model 18:15:46 not sure we need that... 18:15:56 markmcclain: the list of API extensions is in a user friendly form? 18:16:05 if API extension is not used for scheduling, then why have it? 18:16:12 SumitNaiksatam: about as friendly as our current /extensions endpoint :) 18:16:39 enikanorov: not all flavors will implement every API extension 18:16:44 markmcclain: ok may be i misunderstood that part, but i can go back to the spec 18:17:03 markmcclain: right, admin will need to write this in the description 18:17:19 markmcclain: extension list seems informational to me 18:17:31 enikanorov, garyduan: it is 18:17:31 that's the same as with API aspects 18:17:46 mainly because the extensions should be defined in our API spec 18:17:47 markmcclain: OK 18:18:05 markmcclain: also, the problem i see with this is the usage 18:18:18 ie the user knows that if TLS is enable these extra child resources are available for a service 18:18:32 enikanorov: what is the usage issue? 18:18:42 markmcclain: so say instance ID1 doesn't suport L7. user calls L7 on instance with ID1, API layer need to goo to DB and find out which extensions are enabled 18:18:59 to decide whether to forward rest call 18:19:04 or to reply with 404 or 400 18:19:36 if that's what you're proposing, then it's not easy to do. but if we're not doing this, then we don't need extension list as a separate attribute 18:19:45 enikanorov: yep for service extensions that will be required 18:20:02 not every backend may implement an extension 18:20:14 yep, just raise unimplemented 18:20:17 also if we don't do this how do vendor differentiate? 18:20:41 enikanorov: except that as an operator 18:20:43 how is a user going to call L7 on something that doesn't support it unless the operator has misconfigured their flavors/profiles? 18:20:44 they differentiate. on user-facing side, flavor descriptions are different 18:21:10 dougwig: well, user just calls... it should get reasonable error 18:21:22 'not implemented' seems reasonable to me 18:22:00 enikanorov: an operator may want to make a driver that offers more features to a flavor that offers no features 18:22:04 s/no/few/ 18:22:13 i'm saying that extension list as an attribute is not extendible, if we want to declare API aspects in the future 18:22:27 enikanorov: That's true... but I guess I'm still not following why markmcclain's proposal wouldn't be able to do that? What is the usage problem here? 18:22:28 enikanorov: it is extensible 18:22:58 markmcclain: As a generic neutron question, we have the same issue of exposing APIs exposed by a driver to the tenant (say for ML2), so should we be exposing API extensions from drivers in a generic way, not in a service flavor specific way? 18:23:00 "That's true" was meant to apply to the 'not implemented' error comment you said above. 18:23:24 i guess that's not about APIs exposed by drivers 18:23:33 it's about core service API that driver may not support 18:23:39 the operator ensures the deployed backends have support and then add extension to the list if they choose 18:24:01 anyway, flavor-based discpatching seems the complexity we would like to avoid 18:24:06 enikanorov: if we keep the core service API small then everyone should be able to support it 18:24:29 enikanorov: flavor based dispatching is not that difficult of a problem 18:24:54 i'd say it's not a step-1 task 18:25:00 mainly because the mechanics of dispatching usually involve retrieving teh flavor info 18:25:34 can we describe falvor info for one service say fw to understand heer? 18:26:01 firewall has no extensions, i guess 18:26:10 garyduan: is that so? 18:26:12 pgpus: mind if I talk lbaas example case? 18:26:13 OK lets take LB 18:26:15 no ext. 18:26:23 so is vpn, i guess 18:26:26 Well, there's also the problem of an extension "mostly" being supported: For example, if a particular implementation can support most of L7 in LBaaS, but there are one of two things it doesn't support within the L7 functionality, can it report that a given configuration is not implemented? 18:27:17 sbalukoff: right 18:27:58 sbalukoff: that may make sense for particular not supported attr. like unsupported cypher of certificate or something 18:28:03 pool, member, protocol say http supported but not https does it make sense? 18:28:17 Folks, where are we at here? We're at an hour, and I'd like to ensure we wrap this up at some point. :) 18:28:17 enikanorov: Yes 18:28:28 pgpus: there's not way with extension list to say 'i don't support https protocol' 18:28:38 OK so flavor can be L7LBsimplehttp types 18:29:00 mestery: Sorry for throwing a monkey-wrench into the clockwork. :P 18:29:05 pgpus: that goes down to a vervose description 18:29:21 We can't sit here all day discussing this, I'm sure most of us have backlogs that are huge at this point. :) 18:29:40 that's my point, extension list is not helping much, not to say dispatching based on it is not necessary 18:29:42 So moving forward, is there anything else that isn't agreed on? I lost track to be honest. :) 18:29:54 OK I am trying to understand flavor in terms of am I drinking a Darjeeling tea or a colombian cofee 18:29:58 how to map flavor to driver is the point of contention 18:30:00 mestery: that's still about user api 18:30:01 the last i remember, markmcclain was summarizing what we agreed on 18:30:01 can we get a merged proposal with examples to review? 18:30:05 but I really don't think it is that far off 18:30:10 mestery: I think we are still on APIs - since we have disagreement on extensions 18:30:19 markmcclain: let's do it the way you proposed 18:30:28 at least for now 18:30:34 it's hidden from user anyway 18:30:52 enikanorov: right and then we can add advance capabilities as follow up work 18:31:07 markmcclain: +1 18:31:11 enikanorov: +1 18:31:12 +1 18:31:12 this will also break the dependency bottleneck the adv services are experiencing 18:31:22 markmcclain: HUGE +1 18:31:24 Yes! 18:31:27 one more question 18:31:32 Damn. 18:31:35 ;) 18:31:37 meta data in profile 18:31:43 so the optimism of the other day was well founded :) 18:31:46