[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,
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]