[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)
FYI. I will extract and put in to JIRA tomorrow.
Martin.
-----Original Message-----
From: devdatta kulkarni [mailto:devdatta.kulkarni@rackspace.com]
Sent: 05 December 2013 19:12
To: camp-comment@lists.oasis-open.org
Subject: [camp-comment] Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)
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?
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]