[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [camp-comment] Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)
-----Original Message-----
From: Martin Chapman
Sent: 06 December 2013 16:24
To: Adrian Otto; Devdatta Kulkarni
Cc: <camp-comment@lists.oasis-open.org>
Subject: RE: [camp-comment] Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)
I have logged 2) and 3) for tracking purposes:
https://tools.oasis-open.org/issues/browse/CAMP-153 Two approaches to identify services in a DP?
https://tools.oasis-open.org/issues/browse/CAMP-154 python atrifact
-----Original Message-----
From: Adrian Otto [mailto:adrian.otto@rackspace.com]
Sent: 05 December 2013 19:22
To: Devdatta Kulkarni
Cc: <camp-comment@lists.oasis-open.org>
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/
>
-- 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]