Hi Devdatta-
Thanks for the great comments. A few responses from me.
1) +1 to calling it "requirement_type"
2) (re nested vs separate services) My experience is that often
it is more natural to use a nested notation in some places, ie
when the dependent service is subordinate to the place it is
nested. In that case you don't have to give the dependent service
an ID and refer to it separately. (One of the considerations in
plan schema design was making it relatively easy to read and write
by hand, as well as by machine. If it were machine generated then
I agree with you it is natural to have all services in a list with
fulfillment using id-references.)
3) YAML looks good, except that "services" takes a list of service
specs not a single such spec (as you noted that it should). If we
accidentally indicated the contrary somewhere I'm sorry and please
let us know!
Best
Alex
On 09/12/2013 09:11, Gilbert Pilz wrote:
Hi Devdatta,
Your Plan looks good to me. My only critique is the values of
your artifact_type, requirement_type, and characteristic_type
nodes. Values like "pyc, "interpreted_by" are likely to collide
with other PaaS implementations that may not assign the same
semantics to those values. Section 4.2.1 of the CAMP spec
actually mentions this specifically:
To promote portability, both
providers and consumers
of the CAMP API are encouraged to namespace-qualify the
types that they use.
For example, if a PaaS provider supports a requirement type
that expresses the
relationship “deploy on a Spring container”, the value
“com.paas-r-us.spring.DeployOn” is preferable to the value
“DeployOn”, as the
latter is likely to collide with similar types.
So values like "org.openstack.interpreted_by" would be
preferable to "interpreted_by". Note that there is an assumption
that, as these things mature, implementations and organizations
will coalesce around certain definitions and their values. For
example, one day there might be an "officially blessed" version
of "pyc" called "org.python.pyc" that adopts the semantics
originally defined by Solum.
~ gp
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/
|