From: MartinC [mailto:noreply@soaphub.org]
Sent: 08 November 2012 01:27
To: martin.chapman@oracle.com
Subject: oasis-camp: Chat Transcript - sent by: MartinC
Chat transcript from room: oasis-camp
2012-11-07 GMT-08:00
[09:14] Michael Behrens: Good Morning. FYI: I'm not able to attend full-time today (I'll be back later in the afternoon).
[09:20] Michael Behrens: Chair: The CompatibleOne leads are in town for the cloud expo. They have an implemented manifest/etc. They could come by today to provide a briefing (say around 4:30). Would that be acceptable to all (in terms of agenda)?
[09:36] jeffm: ping
[09:37] Anish Karmarkar asked for a victim, I choose... Prasad
[09:38] MartinC: https://oracleconferencing.webex.com/oracleconferencing/j.php?J=593156882&PW=NNTBiYjMyZDM2
[09:38] Prasad morphed into scribe
[09:39] scribe: TOPIC: Martin (TC Chair)calls the meeting to order (9:35am PST)
[09:40] scribe: Prasad (Software AG) is picked as scribing victim for the morning session
[09:40] scribe: Topic: Agenda review / reorder of agenda items
[09:43] scribe: Topic: Discussion of Major Arch. issues
[09:44] scribe: issue 1. Platform Deployment Package
[09:44] scribe: Gil driving the discussion
[09:45] Mark Carlson (Oracle): Michael - the guys in the room want to know more about what the Compatible One guys would present/demo. Can you summarize for us?
[09:46] scribe: discussing resource models & dependencies
[09:49] scribe: two models for the contents of the PDP
[09:49] MartinC: Gil's write up is here: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201211/msg00039.html
[09:50] Tobias Kunze (Red Hat) -- scribing morphed into Tobias Kunze (Red Hat)
[09:51] scribe: Mark: missing arroiws in the assembly model (in CAMP specific artifacts) to link CAMP artifacts with platform specific artifacts. Need to be able to corelate them
[09:53] scribe: Anish: We have not defined a format for the PDP. Need to spec a format that all must support
[09:53] scribe: .. slighttly different from the issue being discussed but need to address this
[09:56] scribe: PDP may not contain runtime attributes. You may need to ask some of these to be created by the platform and not serilaize all nodes and props from the assembly
[09:57] scribe: Tobias: Against the second version in Gil's proposal.
[09:58] scribe: ...Adamant #1 is right way to model PDP
[10:00] scribe: Ashok: Wanted to say the same thing as Tobias. Also, in the 2nd it is very abstract notation Do not know how to deal with it
[10:00] scribe: Gil: We need to define that
[10:00] Tobias Kunze (Red Hat): We need to describe what we have and what we need. This is the Application Components and our requirements. It *may* include Platform Components IFF we (the application authors/owners) happen to know what PC exist on a platform.
[10:04] scribe: Martin: People have different use cases in mind when they model these
[10:06] scribe: ..e.g. uploading a deployable app onto a platform with code artifact and deployment plan vs moving app from platfrom a to platform b
[10:06] scribe: the PDP form will be the same or different to address these two different usecase
[10:08] scribe: Adrian: Agree with Anish that PDP is different fromjust serialized resources . E.g. the files in there are not URLs that PDP needs
[10:09] Mark Carlson (Oracle): Every resource has a uri attribute, so serializing does allow you to hook the links in the resources to other serialized resources even if the export of a PDP does not change these in the serialization.
[10:10] scribe: There needs to be a way to express parameters in the PDP. E.g. when file is deployed there might be customization and such properties associated with it
[10:10] Mark Carlson (Oracle): We could also specify how to substitute unique identifiers for URIs in the serialization.
[10:11] Mark Carlson (Oracle): We also have this problem when exporting from an ADE to a CAMP cloud.
[10:12] scribe: Gil: Notion of familiar & unfamiliar platforms for developers of app / PDPs
[10:12] Adrian Otto (Rackspace): Can not express everything in API calls Agree that file based representations of resources are not straight serializations Ex: references to other resources are not URIs, they are relative file paths. Platform may not need to have a method to generate a PDP A tool may be provided by the service provider. Parameters Mappings Resources
[10:18] scribe: Prasad: Suggest we distinguish clearly in our use of the term CAMP as in the standard CAMP vs CAMP as in a specific PaaS. It is confusing to put this in context subjectively
[10:20] Tobias Kunze (Red Hat): Discussion appears to be about simplicity (desired) and not so much about whether or not accompany a PDP with meta information (which both scenarios envision)
[10:20] scribe: Mark: May be we should visit this issue when we have other pertinent issues resolved as Gil's proposal assumes certain things
[10:23] scribe: Anish: PDP is a PPDP protable PDP
[10:23] scribe: We should not insert any platform specific properties in PDP
[10:27] Mark Carlson (Oracle): How a provider does things internally can differ radically from what they expose through the CAMP interface. The whole idea of a standard is have something that can be mapped, not one that punts on any management at all.
[10:28] Mark Carlson (Oracle): There are resources in CAMP that are under the complete control of the application admin and ones that are under the complete control of the provider.
[10:28] Mark Carlson (Oracle): Have resources that are partially under control/instrumented-by both will lead to many of the issues we have open.
[10:34] scribe: Gil: If you have a specific platfrom related properties, you must include something like a target platfrom URI in the PDP. In that case it is not a PPDP
[10:42] scribe: Adrian: We do not have concept of dictionary or registry - we do not enable mapping resources, capabilities and requirements from platfrom to platform
[10:42] gilbert.pilz: ping
[10:43] scribe: When you from platform A to B , you may need to use the API to query the PDP, fiddle with it and create a new PDP specific to platfrom B
[10:44] Tobias Kunze (Red Hat): explained that we need to be able to express e.g. that our applications consists of parts {A, B} and that e.g. A needs {p, q} and B {r, s, t}. Now if platform X has magic middleware that provides {p, ..., t} in one single piece, it is free to run the app that way, but it still needs to expose A and B as different components. What this should illustrate is (1) that CAMP doesn't require any commitment to specific granularity; it's just that if the owner says she has {A, B}, they need to be visibile as such. This should also illustrate that (2) the meta information required could be as simple as p = "php", q = "java7" etc.
[10:45] scribe: Martin: summarizes the discussion. Close the discussion on the issue for the time (F2f). To be revisited later
[10:46] scribe: Break. Reconvene in 15 mins.
[10:46] Rich Miller (Cloudsoft): Thank you for the detailed notes in the Chat stream. Following on the phone has been a bit problematic.
[10:47] Rich Miller (Cloudsoft): I must drop off for another meeting between 11 am and 1pm / 1:30pm. I hope to rejoin then.
[10:50] Adrian Otto (Rackspace): In my last comment I mentioned that the spec has no dictionary, and there is no standalone registry of resources types. In the absence of these things, it may be difficult to move an application (assembly) from one PaaS to another. Portability will require either some common understanding of standard (specific) resource types, OR it requires a way for the individual (or tool) moving the application to make a mapping (relation) between what the application needs and what the target PaaS provides. Ideally this should be possible without significantly reconstructing the [P]PDP file. Ideally, some common types are known, or a mapping can me offered at the time the [P]PDP is created so that it will be deployable on the target PaaS.
[10:59] scribe: Resuming after the break..
[10:59] scribe: TOPIC: 6. Canonical Platform Services
[11:01] scribe: Mark Carlson presents on the topic..
[11:02] MartinC: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201211/msg00047.html
[11:04] scribe: Presentation raoad map: Platform Component Overview Types of Specialization Examples of Platform Component types What is a Platform points of management interoperability Issue: what do we take on as a group? Initial 1.0 release Adding over time
[11:05] scribe: Capability: abstraction of whats available on this platform Requirement: abstraction of what the application requires Template: represents concrete configurations or existing pools
[11:05] scribe: Subclassing - Platform Component (PC) resource types are meant to be specialized by sub-classing (initially) into a class for each type of platform component (service) offered by this platform The Platform Component types represent the platform offering - the more types, the richer the platform offering is from the application view Examples: DBaaS, MWaaS, IDaaS, firewalls, load balancers
[11:07] scribe: Parameterization - Each Platform Component type is then expected to be specialized by parameterization for specific sizes and configurations in one of two ways: Create a Platform Component directly and supply the attributes of the resource to get what you need Create a Platform Component using an already parameterized Template
[11:09] scribe: Why have multiple ways? Platform can be built using virtualization and multi-tenancy at various levels, and this will be reflected in how they need to expose the platform component resources VM per instance a machine image is used to create the component and may be parameterized Multi-tenant platform component resources carved out of existing shared pool
[11:12] scribe: Jacques: Different ways to implement a components on a platform. Does the component definition include how it is implemented
[11:14] scribe: Capability VM per instance Each application gets their own set of VMs running the platform components These can be parameterized at the infrastructure level (bigger VM) and service configuration level since it is dedicated The Platform Component Capability resource is ideal for representing all these choices as ranges of values that can be mapped to the VM configuration and the software running there
[11:18] scribe: Capability - Instrumented by the platform Contains all supported attributes for that type Contains value ranges for each attribute Serves as a service catalog of supported PCs on this platform Application admin can create a PC instance supplying any/all attributes with any value in the range (no need to first create a template)
[11:22] scribe: Jacques: This Capability model sems very simplistic
[11:23] scribe: you may have more constraints like this property cannot have this value with this other property etc.
[11:23] scribe: Template multi-tenant PC - Each Platform Component instance is provided isolation by the component software itself i.e. DB based on schema, multi-tenant JVM, etc. However, some configuration choices and combinations are not possible because the pools of resources are already provisioned Thus the Templates can be used to represent each pools configuration
[11:30] scribe: A given platform implementation may not allow all combinations of all values for attributes of a PC, so representing as a Capability is misleading A template can always be used to create an instance with attribute values that match what is in the template (modulo resource exhaustion)
[11:38] scribe: Martin - we need ways to describe what you need at deployement at runt-time etc.
[11:38] scribe: Requirement - When building an application off-platform how do you know what parameterizations of PC are available on the target platform? You could import the capability or templates from the platform, then link them as dependencies You can instead express which values of each attribute are acceptable to the application by creating a Requirement These are then used to find the best match when the application lands on a given platform
[11:47] scribe: Anish: A capability is a resource on the platform. When I do a GET on the resource, how do I know is a capability?
[11:48] scribe: Mark: If we have MIME type for it, we will be able to identify based on that
[11:50] scribe: Gil: Requirements & capabilities must match 1 to 1
[11:54] scribe: Anish: I found a better answer to my question. A way to know a resource is a capability w/o knowing the mIME type. When I traverse the platform graph, you get a set of URIs one of them is for an arra of capabilities. So, you know you are traversing a capability when you walk down that array chain
[11:55] scribe: Ashok: Why not generalize this. Capabilty & requirements are an objet type ...
[11:57] scribe: Jeff: I am not sure if that is that simple..
[11:57] scribe: If the ocabulary is defined outsid ethe standard, how can the standard talk about it?
[12:02] scribe: ISSUE: Should CAMP include some specific canonical PC types? Without these types, how much interoperability is possible? How similar are the services such as database that will be offered? Is it possible to abstract them for commonality of configuration and metrics yet?
[12:04] scribe: Which PC types first?
[12:05] scribe: Basic runtime container is key if the application admin is expected to use multiple container instances to scale out his application An application depends on its runtime environment and at a minimum it needs to be billed based on its usage of that container Other PC types might be too diverse to standardize around yet
[12:06] scribe: Martin: May works I have seen tried capabilities, requirements and matching them, that never worked. I do not want to rathole in this TC on the same thing
[12:07] scribe: Anish: If want to standardize this, I do not want it to be part of the core spec
[12:07] scribe: Martin: Even a container?
[12:07] scribe: Anish / Martin: Yes. Container, environment or whatever
[12:08] scribe: Anish: allow people to impliment and comply with CAMP even if they not agree pr align with capabilities and requirements
[12:09] scribe: Do not want to link conformance to CAMP to conformance to any platform component
[12:12] scribe: Adrian: Spec could be more specific and simpler. Too much freedom leads to complexity
[12:14] scribe: If we leave it all empty and not say anything also not good. Too much or too little does not lead to interoperability. Choose a middle groud.
[12:15] scribe: Dave: We do not want to build an API wrapper. Need to to have some semantic calue
[12:15] Tobias Kunze (Red Hat): Arguing strongly in favor of not dealing with functional interfaces and *specific* types and interoperability. Defining types might be relegated to a "best practices" document and held non-normative. I'd also like to point out that this is the approach that the TOSCA TC has chosen to follow. As a result, we'd be stepping on that TC's toes if we'd decide to define our own types
[12:15] scribe: s/calue/value/
[12:18] gilbert.pilz: does "Node.JS" == "node.js" ?
[12:20] MartinC: Jeff just said the F word
[12:23] scribe: Jeff: s/to to/to/
[12:23] scribe: s/Jeff://
[12:24] scribe: s/to to/to/g
[12:26] gilbert.pilz: http://www.walrusbucketsaga.com/
[12:26] Mark Carlson (Oracle): Mark will supply a concrete proposal associated with the Jira issue proposing a "Runtime Environment" Platform COmponent
[12:26] scribe: Martin: Conclusing discussionon this.
[12:27] gilbert.pilz: http://knowyourmeme.com/photos/26-lolrus
[12:27] scribe: >>>>>Breaking for lunch. Reconvene at 1:30pm <<<<<<
[12:28] scribe morphed into prasad
[12:29] gilbert.pilz: it's spelled "bukkit"
[13:40] MartinC: Just about to resume - phone bridge is open
[13:43] Zhexuan Song (Huawei) morphed into Zhexuan Song - scribe
[13:43] Zhexuan Song - scribe: Afternoon meeting starts at 1:43PM
[13:44] Zhexuan Song - scribe: Item: MIME Type
[13:46] Zhexuan Song - scribe: Adrian: one media type for multiple media types in response
[13:46] Zhexuan Song - scribe: or should we define it in specification
[13:47] MartinC: https://tools.oasis-open.org/issues/browse/CAMP-13
[13:48] Zhexuan Song - scribe: drawback for too many types is to register with IANA
[13:49] Zhexuan Song - scribe: potential solutions, check the issue page, URL above
[13:51] Zhexuan Song - scribe: Adrian's suggestion: solution #2
[13:51] Zhexuan Song - scribe: use application/json and an attribute in response body
[13:52] Zhexuan Song - scribe: Gil: +1 #2
[13:53] Zhexuan Song - scribe: Martin: need further explanation
[13:53] jeffm: Dinner - 7:00 pm - Hola! - reservation in my name - 1015 Alameda de las Pulgas , Belmont - 650-591-1735 http://holarestaurant.com/
[13:53] gilbert.pilz: HTTP/1.1 200 OK Date: Wed, 07 Nov 2012 21:52:17 GMT Content-Type: application/json;charset=ISO-8859-1 Content-Length: 427 { "type" : "Assembly" "uri" : "http://slc03lgx.us.oracle.com/campSrv/Assembly/13", "name" : "/staging", "description" : "nCAMP Staging Area",
[13:55] prasad: "type" : "Assembly" seems generic and applicable to other domians. Somehow CAMP context needs to be reflected in here
[13:56] Zhexuan Song - scribe: drawback: need to look at message body to identify type
[13:58] Zhexuan Song - scribe: if we have subtype, we need to parse body no matter what
[13:58] Zhexuan Song - scribe: above by MarkC
[14:03] Zhexuan Song - scribe: Anish: we are using #1 now, #3 does not give benefits, #4 need too many visits to IANA, like #2, value of type can be more complicated than string, and no need to register.
[14:03] prasad lowered your hand
[14:03] Zhexuan Song - scribe: Martin: we can define "type" in our spec, support #2
[14:04] Zhexuan Song - scribe: Anish: what is the advantage to put the information in header?
[14:04] Zhexuan Song - scribe: MarkC: can use header to filter response
[14:06] Zhexuan Song - scribe: Tobias: header should define format only
[14:09] Zhexuan Song - scribe: Martin: you need to parse to check validity anyway, should not be an issue
[14:10] Zhexuan Song - scribe: MarkC: can use header to pre-parsing and accelerate the handling process
[14:11] Zhexuan Song - scribe: Time to vote
[14:12] Zhexuan Song - scribe: Anish: we can eliminate 1 and 3
[14:13] Mark Carlson (Oracle): 1, 2, 3 or 4? (1) 1 (2) 2 (3) 3 (4) 4 This is a single choice vote.
[14:13] Jacques (Fujitsu)1: Jacques (Fujitsu)1 voted for: 2
[14:13] Mark Carlson (Oracle): Mark Carlson (Oracle) voted for: 2
[14:13] Tobias Kunze (Red Hat): Tobias Kunze (Red Hat) voted for: 2 - It's The Only Right Choice
[14:14] MartinC: 2
[14:14] Gilbert Pilz (Oracle): Gilbert Pilz (Oracle) voted for: 2
[14:14] Zhexuan Song - scribe: Zhexuan Song - scribe voted for: 2
[14:14] MartinC: MartinC voted for: 2
[14:15] Zhexuan Song - scribe: This vote is just to collect opinions
[14:16] Anish Karmarkar: Use option 2 (with an addition of moving the 'type' parameter into the json body) in Adrian's 1st comment on issue 13 as the direction for resolution of issue 13
[14:16] Anish Karmarkar: Anish Karmarkar voted for: 2
[14:16] Mark Carlson (Oracle): 1, 2, 3 or 4?| Tally Choice 0 1 7 2 0 3 0 4 0 Abstains
[14:16] Zhexuan Song - scribe: second by Tobias
[14:18] Zhexuan Song - scribe: Adrian: take into consideration: #2 has a side effect for version negotiation
[14:18] Zhexuan Song - scribe: UNAN
[14:20] Zhexuan Song - scribe: issue is assigned to Adrian, need further discussion on how to define type, MarkC, Anish are willing to help
[14:23] Zhexuan Song - scribe: ITEM: Extensibility
[14:25] Zhexuan Song - scribe: Anish introduced the idea, details in his write-up
[14:26] Michael Behrens5: I'll be able to call in in a little while. Here's a CompatibleOne Summary: It can be described as a cloud broker. It coordinates the installation of infrastructure and applications based on a manifest. It provides monitoring/measuring of the system(s). It is built using REST as the primary, if not the only protocol between it and the systems it manages. It can broker between Azure, OpenStack, OpenNebula, and others. url is: http://www.compatibleone.org
[14:27] MartinC: Anish's presenatation: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201211/msg00032.html
[14:31] Zhexuan Song - scribe: Martin: we are defining rules how to add new resources, but not new resources
[14:32] Zhexuan Song - scribe: MarkC: we do not have to say anything
[14:38] Zhexuan Song - scribe: Anish: explained potential extensibility points
[14:40] Zhexuan Song - scribe: important: how to discovery/query, indicate, and manage extensions
[14:43] Mark Carlson (Oracle): We need to back off and understand what the goal is here. I think it would be something like "allow basic interoperability, but allow for extensions that don't break that"
[14:43] Zhexuan Song - scribe: JeffM: difference between discovery and indication?
[14:43] Zhexuan Song - scribe: Anish: indication means a part is an extension and ready for discovery
[14:45] Zhexuan Song - scribe: JeffM: discover/query/indicate are the same thing, TC must do that
[14:46] Zhexuan Song - scribe: Anish: like to have a informal poll for opinions
[14:46] Zhexuan Song - scribe: s/a/an
[14:47] Zhexuan Song - scribe: Adrian: without extensibility, we are stuck with whatever we generate. We should allow community to extend as they like. OpenStack vs. CloudStack as an example
[14:48] Mark Carlson (Oracle): I would like us to focus on additional management functionality, and how to add that, both for future versions of CAMP, as well as for vendor specific needs.
[14:48] Zhexuan Song - scribe: Adrian: query is necessary if no registry exists
[14:52] Zhexuan Song - scribe: MarkC: focus on extensions where the spec will become incompatible
[14:53] Zhexuan Song - scribe: Jacques: setting up base rules how to extend
[14:55] Zhexuan Song - scribe: Gil: the group seems to agree with the proposal
[14:55] Mark Carlson (Oracle): X- has been deprecated
[14:55] Zhexuan Song - scribe: Anish: one example: use x- for extension
[14:57] Mark Carlson (Oracle): com.orgname.<AttributeName>
[14:57] Mark Carlson (Oracle): <AttributeName> can be further broken down and managed by orgname
[14:59] Zhexuan Song - scribe: related CAMP issues: 1, 10, 14
[15:01] Zhexuan Song - scribe: CAMP issue 10 -> Anish, Adrian will contribute
[15:03] Zhexuan Song - scribe: break for 15 minutes, until 3:20 PT
[15:29] Zhexuan Song - scribe: meeting resumes at 3:29
[15:30] MartinC: If anyone wants to dial in please shout and I will set up the bridge.
[15:31] Michael Behrens10: I'll dial in.
[15:31] MartinC: ok ill set it up
[15:35] Zhexuan Song - scribe: ITEM: simpler resource model
[15:37] MartinC: Gil's presentation: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201211/msg00040.html
[15:41] Zhexuan Song - scribe: Gil: explain the points he made in the document, URL above
[15:42] Zhexuan Song - scribe: Martin: agree with gil, no need for application components
[15:44] Zhexuan Song - scribe: Tobias: application components may have different requirements
[15:46] Michael Behrens10: UML diagram might be helpful to show relationships.
[15:49] MartinC: Michal I agree but there are a lot of uml doubters around here
[15:50] Zhexuan Song - scribe: Ashok: gave an example of application components
[15:55] Zhexuan Song - scribe: MarkC: spec says that we can just instantiate one application component for various applications, assembly components do not have this capability
[15:56] Zhexuan Song - scribe: Gil: make the things complicated
[15:58] Mark Carlson (Oracle): Here is the text in the current spec:
[15:58] Mark Carlson (Oracle): An application is composed of a set of Application Components that depend on one or more Platform Components. Examples of Application Components include Ruby gems, Java libraries, and PHP modules. Application Components may also include non-code artifacts such as datasets and collections of identity information. Application Components may also interact with other Application Components. Thus, an Application Component has two different sets of dependencies. It depends on the Components provided by the platform, and depends on services provided by other Application Components
[15:58] Zhexuan Song - scribe: Anish: application components are useless
[16:00] Zhexuan Song - scribe: as for now, no semantics linked with application components
[16:02] Zhexuan Song - scribe: Adrian: use case: a sql database for different version of applications, how to define this sql component
[16:07] Zhexuan Song - scribe: Martin: explain the relationship between assembly and application components
[16:10] Zhexuan Song - scribe: Adrian: is it possible to have components with different management in the same assembly
[16:10] Zhexuan Song - scribe: Tobias: not for now, but do have use cases for that
[16:10] Michael Behrens10: Has links (URLs) been discussed for components of an assembly?
[16:11] Zhexuan Song - scribe: Charlie: questions: do we allow application components running independently
[16:12] Zhexuan Song - scribe: Anish: should we allow assembly to have dependence on a platform component from different assembly? issue to figure out
[16:15] Zhexuan Song - scribe: Gil: application component represents management of a module, detailed hidden in CAMP. In this model, it is not an atomic thing.
[16:17] Zhexuan Song - scribe: Martin: application has no meaning as an independent thing
[16:21] Zhexuan Song - scribe: MarkC: this is a bug in spec, we should clearly define application components and their behavior
[16:21] Zhexuan Song - scribe: Only need it when we have different life cycle
[16:23] Zhexuan Song - scribe: Tobias: messy, assembly is just a group of things, always use assembly even with one component
[16:24] Zhexuan Song - scribe: lifecycle points to assembly only
[16:27] Zhexuan Song - scribe: Anish: this is not about management of things, should not be in spec
[16:29] Zhexuan Song - scribe: Ashok: we need application component, may have different lifecycle
[16:31] Zhexuan Song - scribe: JeffM: this discussion is meaningless.
[16:35] jeffm: not that the discussion is meaningless, but that constructing arguments based upon the parsing of the exact words in the DRAFT spec is somewhere between not useful and meaningless. Instead the argument should be what do we want the spec to do and the model to be
[16:35] Zhexuan Song - scribe: Martin: three solutions, 1) Tobias' option, assembly is just a collection of things; 2) assembly points to components but not include; 3) no difference between components and assembly;
[16:37] Zhexuan Song - scribe: for 2) lifecycle is on assembly; for 3) individual component has its own lifecycle
[16:38] jeffm: the Chair just hit the wrong button on the phone ? we are dialing back in
[16:38] Mark Carlson (Oracle): Sorry Michael we accidentally hung up
[16:38] Michael Behrens10: No worries. I have to get going now anyway. Thanks and have a good dinner.
[16:38] jeffm: conf line is back up
[16:39] prasad lowered your hand
[16:41] Zhexuan Song - scribe: Tobias: assembly should not point to platform components
[16:45] Zhexuan Song - scribe: MarkC: in this setting, application component is always needed
[16:46] gilbert.pilz: q=
[16:49] Zhexuan Song - scribe: Gil +1 Tobias
[17:05] Zhexuan Song - scribe: Tobias used a PHP example to explain the concept of assembly, components, etc.
[17:06] Zhexuan Song - scribe: Platform components may have different lifecycle
[17:09] Zhexuan Song - scribe: CAMP = {Assembly, C_application, C_platform, C_external, C_reference, Resources_External}
[17:10] Zhexuan Song - scribe: plus many templates
[17:12] Zhexuan Song - scribe: Gil: no decision, but a rough consensus on Q4
[17:13] Zhexuan Song - scribe: Martin: nothing from this discussion will lead to spec change, need more concrete issues that trigger spec changes
[17:16] Zhexuan Song - scribe: Configure injection discussion
[17:18] Zhexuan Song - scribe: Tobias: looks like an orchestration issue
[17:19] Zhexuan Song - scribe: Martin: raise an issue to investigate it, Adrian will open it
[17:25] Zhexuan Song - scribe: Martin: leave the discussion on lifecycle until tomorrow
[17:25] Zhexuan Song - scribe: Ashok/gil motion to adjourn, UNAN, 5:25PM
[17:25] Zhexuan Song - scribe: End of Day 2