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