[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,
I have logged this as a PR2 comment: https://tools.oasis-open.org/issues/browse/CAMP-163
Cheers,
Martin.
-----Original Message-----
From: devdatta kulkarni [mailto:devdatta.kulkarni@rackspace.com]
Sent: 19 February 2014 22:08
To: Adrian Otto
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)
Hi Adrian,
Recently I got a chance to take a look at CAMP working draft 39 (dated February 3, 2014).
I was specifically looking to see how the issue filed here
https://tools.oasis-open.org/issues/browse/CAMP-153
has been resolved.
Upon reading through the comments on the issue, I am not sure I agree to the
justification given to keep two different service specification formats.
If I understand the justification correctly, it is saying that
the 'in-line' format of service specification is useful for the use case when multiple artifacts *don't*
want to share services. In such situations, the required services can be specified
'in-line' with each artifact, whereas, if multiple artifacts need to share a service (same instance of it) then such a
service specification should be defined in the services section.
I still think that one could achieve both these use cases by having a single
way of defining required services in a separate top-level services section.
Having two different formats will lead to model interpreter complexity
without providing significant gain.
If, however, the TC wants to keep two different formats then one suggestion that I would like to make
is to enforce the distinction through the specification.
Currently the 'in-line' format is still exactly same as the 'out-of-line' format,
the specification does not explicitly restrict/enforce when to use one over the other.
One way to enforce this would be to remove the 'id' field from the 'in-line' definition of a service.
That way, it won't even be possible to reference an in-line defined service from outside
the defining artifact's scope. (to be concrete: remove 'id' from being a child of 'fulfillment' node
on line 14 of page 31).
In case this is not an option then another suggestion would be to at least explicitly call out
in the specification the need for providing two different ways to specify services and to suggest when
one format should be used over the other.
Regards,
Devdatta
-----Original Message-----
From: "Adrian Otto" <adrian.otto@rackspace.com>
Sent: Wednesday, December 11, 2013 3:07pm
To: "Devdatta Kulkarni" <devdatta.kulkarni@RACKSPACE.COM>
Cc: "<camp-comment@lists.oasis-open.org>" <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 1:12 PM, devdatta kulkarni <devdatta.kulkarni@rackspace.com<mailto: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?
Answered in https://lists.oasis-open.org/archives/camp-comment/201312/msg00005.html
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).
We opened an issue for this: https://tools.oasis-open.org/issues/browse/CAMP-153
I own this issue and will be submitting a proposal to only refer to services as a top level node. If implementers want to support a nested alternative, that may be done as an extension. The resolution to this issue will simplify the spec.
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?
Yes, you can list multiple services. Here is an example that lists three different services:
# Adrian's Example 3 (EX3) - Make a 3-Tier web application, with 3 load balanced nodes
camp_version: CAMP 1.1
artifacts:
-
artifact_type: solum_docker_image
content { solum_glance_id: 12345-67899-33093-4328437 }
requirements:
-
requirement_type: solum_app_pool
fulfillment: id:my_pool # See "App Server Pool" in services section below
-
requirement_type: solum_load_balancer
fulfillment: id:my_load_balancer # See "Load Balancer" in services section below
-
requirement_type: solum_db
fulfillment: id:my_db # See "Trove Database" in services section below
services:
-
name: Load Balancer
id: my_load_balancer
characteristics:
-
characteristic_type: solum_small_load_balancer
-
name: App Server Pool
id: my_pool
characteristics:
-
characteristic_type: solum_small_container # Select the small container size
solum_node_count: 3 # Make three of these nodes in a pool
solum_load_balancer: id:my_load_balancer # connect these nodes to "my_load_balancer"
-
name: Trove Database
id: my_db
characteristics:
-
characteristic_type: solum_trove_database
Regards,
Adrian
Regards,
Devdatta
-----Original Message-----
From: "devdatta kulkarni" <devdatta.kulkarni@rackspace.com<mailto:devdatta.kulkarni@rackspace.com>>
Sent: Thursday, September 26, 2013 6:28pm
To: camp-comment@lists.oasis-open.org<mailto: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<mailto:camp-comment-subscribe@lists.oasis-open.org>
Unsubscribe: camp-comment-unsubscribe@lists.oasis-open.org<mailto:camp-comment-unsubscribe@lists.oasis-open.org>
List help: camp-comment-help@lists.oasis-open.org<mailto: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<mailto:camp-comment-subscribe@lists.oasis-open.org>
Unsubscribe: camp-comment-unsubscribe@lists.oasis-open.org<mailto:camp-comment-unsubscribe@lists.oasis-open.org>
List help: camp-comment-help@lists.oasis-open.org<mailto: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]