OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [camp-comment] Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)


Devdatta,

Upon closer inspection, I found the bug you referenced in #1 below. It was an editorial omission. It's fixed in WD33.

Adrian

On Dec 5, 2013, at 1:22 PM, Adrian Otto <adrian.otto@RACKSPACE.COM> wrote:

> Devdatta,
> 
> On Dec 5, 2013, at 11:12 AM, devdatta kulkarni <devdatta.kulkarni@rackspace.com>
> wrote:
> 
>> Hi,
>> 
>> Recently I got an opportunity to go through the CAMP Version 1.1 Draft 32 (dated: 5 December 2013).
>> I had following comments/questions:
>> 
>> 1) I see that most of the labels in a DP are changed to lowercase_lowercase format,
>> except for "RequirementType". Just wondering if this is a typo?
> 
> That's a non-terminal, so it does not appear in any YAML file, or in any JSON resource. It is intentionally using camelCase to set it apart.
> 
> We will answer your other questions separately.
> 
> Adrian
> 
>> 2) Is there a reason why there should be two approaches to identify services in a DP?
>> Example 4 in Section 4.2.2.1 demonstrates one approach. In this the "service" section
>> is not explicitly called out. It is defined under the "fulfillment" section which 
>> is hidden under the "RequirementType" relation.
>> Example 5 demonstrates second approach. In this the "services" section is explicitly called out.
>> 
>> I feel that services should be a first class entity of a DP, and providing an abstraction to
>> explicitly identify them would make that status clear. Therefore, approach shown in example 5
>> is better than that in example 4, imo. Is there any reason to keep both approaches?
>> If not, can the spec be prescriptive about one approach (my vote is for approach in example 5).
>> 
>> 
>> 3) Would a DP for a Python artifact that contains a single python file 
>>  that prints "hello world" and which needs to be interpreted using Python 3.3 would look as follows:
>> 
>> 
>> Assume we have the following Python module:
>> helloworld/helloworld-code.py
>> 
>> --------
>> DP:
>> 
>> camp_version: CAMP 1.1
>> artifacts:
>>  artifact_type: pyc
>>  content: { href: helloworld } --> module name
>>  requirements:
>>     requirement_type: interpreted_by
>>     fulfillment: id:py3.3
>> 
>> services:
>>  id:py3.3
>>  characteristics:
>>     characteristic_type: python3.3 --> interpreter to use
>> --------
>> 
>> As an aside, while writing above example I realized that the "services" 
>> section may need to support multiple services. 
>> Does the current spec definition have provision for that?
>> 
>> Regards,
>> Devdatta
>> 
>> 
>> -----Original Message-----
>> From: "devdatta kulkarni" <devdatta.kulkarni@rackspace.com>
>> Sent: Thursday, September 26, 2013 6:28pm
>> To: camp-comment@lists.oasis-open.org
>> Subject: [camp-comment] Feedback on CAMP Version 1.1 Draft 03 (Dated: 31 July 2013)
>> 
>> Hello,
>> 
>> Recently I got an opportunity to go through the 
>> CAMP Version 1.1 Draft 03 (dated: 31 July 2013)
>> 
>> In case this draft is still receiving comments,
>> I would like to submit the following feedback to TC.
>> 
>> Best Regards,
>> Devdatta Kulkarni (Rackspace)
>> 
>> ----------------------------------------------------------
>> 
>> I have organized the feedback into two sections:
>> - conceptual questions / suggestions
>> - typos
>> 
>> A] Conceptual Questions / suggestions:
>> 
>> 1) The specification uses the word 'self-service' as part of definition of the API.
>> It is not clear what is exactly meant by the term self-service in the context of the API.
>> 
>> 2) Page 16, Figure 2.2, ApplicationComponentTemplate (ACT) box
>> I would assume that an ApplicationComponentTemplate (ACT) would typically be used by more than one
>> assembly templates. For instance, an ACT for database might be used by all the assembly templates
>> that depend on that database platform component. If TC agrees to this point of view, then
>> the suggestion would be to make the assemblyTemplate a LinkArray in the ACT box in Figure 2.2
>> 
>> 3) Page 16, Figure 2.2, ApplicationComponent (AC) box
>> Currently, the AC box does not have reference to the ACT box. Why is that?
>> Wouldn't it make sense for an AC to maintain a link to the ACT from which it has been derived?
>> 
>> 4) Page 20, Figure 2.6, Assembly box
>> The Assembly resource does not have direct link to Platform Component(s), but has an 
>> indirect link through Application Component. Why is that?
>> From an Assembly's point of view, isn't it true that an assembly depends on application components
>> and platform components, and so, wouldn't it make sense to have a link to platform components
>> also in an assembly. With the current model, if one has to use sensors on platform components 
>> that are being used by an assembly, one would have to navigate through the application components.
>> This can be potentially inefficient.
>> 
>> 5) Page 20, Figure 2.6
>> I feel that the organization of the boxes and the relationships between 
>> AssemblyTemplate, ApplicationComponentCapability, ApplicationComponentRequirement, and 
>> ApplicationComponentTemplate can be (should be?) redone.
>> I don't think it accurately captures the corresponding description in paragraph 6
>> on page 21 (para starting with "An Application Component can express .. ").
>> IMO, the english description is much clearer than the Figure.
>> 
>> 6) Page 21, top paragraph
>> I feel that the term "template" is used in two different ways in the specification.
>> One use of template is to mean a blueprint from which things are "created".
>> An example of this usage is the AssemblyTemplate and Assembly distinction.
>> The other use of template is to mean a blueprint that is used for "requirements resolution".
>> An example of this usage is discussion involving use of PlatformComponentTemplate to 
>> discover the desired platform components. The paragraph starting with "An Application Component
>> can express .. " is leading to this confusion in my mind.
>> May be this discussion could be rewritten?
>> 
>> 7) Page 21, Section 2.2
>> It is not clear why should it be possible to create an assembly template just from a deployment plan (DP).
>> An assembly template is by definition an 'uninstantiated' representation of an assembly.
>> An assembly by definition is a running application that includes application source code, db schemas, etc.
>> A DP by definition does not include application source code.
>> Therefore, it follows that an assembly template created from a DP cannot lead to an assembly.
>> So then the question becomes why should it be possible to use DP to create an assembly template?
>> IMO, creation of an assembly template should only be possible via a PDP.
>> 
>> 8) Page 30, Section 4.2
>> Is there any guidance wrt what should be an 'artifact' and what should be a 'service' in modeling an application?
>> 
>> 9) Page 30 and 31, Section 4.2
>> What do artifacts and services translate into, when a PDP is pushed to the platform? My guess is:
>> - artifacts map to application components / application component templates
>> - services map to platform components / platform component templates
>> If this high-level mapping is correct then the next question is whether they map to a component or 
>> a component template?
>> 
>> 10) Page 32, Example 4 and Page 33, Example 5
>> Having two different ways to specify the artifacts and services might be confusing.
>> I understand that the specification may not want to recommend one representation over other,
>> but, imo, representation in Example 5 is easier to follow (and understand) than that in Example 4.
>> 
>> 11) Page 33, Example 5
>> The specification does not specify any ordering on the artifact types. But such an ordering
>> would be needed in some situations. For instance, in Example 5, the SqlScript needs to executed before deploying
>> the war file so as to provide a 'good' experience to the end user.
>> If the specification is not going to require ordering in the artifacts, and assuming that 
>> such an order might be important in some cases, what can be done?
>> Is the 'extensions' mechanism useful for this?
>> 
>> 12) Page 98, D.5
>> It would be useful if 'operations' and 'sensors' are added to the representation of the 
>> Database resource
>> 
>> 
>> B] Typos:
>> 
>> 1) Page 18, line 3 from the top.
>> "are show" should be "are shown"
>> 
>> 2) Page 20, Figure 2.6, Platform box
>> "platformComponentCapabilities" is miss-spelt
>> 
>> 
>> 
>> 
>> --
>> 
>> This publicly archived list offers a means to provide input to the
>> 
>> OASIS Cloud Application Management for Platforms (CAMP) TC.
>> 
>> 
>> 
>> In order to verify user consent to the Feedback License terms and
>> 
>> to minimize spam in the list archive, subscription is required
>> 
>> before posting.
>> 
>> 
>> 
>> Subscribe: camp-comment-subscribe@lists.oasis-open.org
>> 
>> Unsubscribe: camp-comment-unsubscribe@lists.oasis-open.org
>> 
>> List help: camp-comment-help@lists.oasis-open.org
>> 
>> List archive: http://lists.oasis-open.org/archives/camp-comment/
>> 
>> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
>> 
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>> 
>> Committee: http://www.oasis-open.org/committees/camp
>> 
>> Join OASIS: http://www.oasis-open.org/join/
>> 
>> 
>> 
>> 
>> --
>> This publicly archived list offers a means to provide input to the
>> OASIS Cloud Application Management for Platforms (CAMP) TC.
>> 
>> In order to verify user consent to the Feedback License terms and
>> to minimize spam in the list archive, subscription is required
>> before posting.
>> 
>> Subscribe: camp-comment-subscribe@lists.oasis-open.org
>> Unsubscribe: camp-comment-unsubscribe@lists.oasis-open.org
>> List help: camp-comment-help@lists.oasis-open.org
>> List archive: http://lists.oasis-open.org/archives/camp-comment/
>> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>> Committee: http://www.oasis-open.org/committees/camp
>> Join OASIS: http://www.oasis-open.org/join/
>> 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]