OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [camp] F2F Day 1 Chat Transcript



Hi folks,

Regrets that I've been unavailable.  Looks like very good progress.  Many thanks in particular for the detailed chat notes.

I'd welcome the chance to discuss the two issues that were deferred:

[16:13] Tobias Kunze (Red Hat) -- scribing: http://tools.oasis-open.org/issues/browse/CAMP-8 Support a hierarchical model of platform components at runtime (or typed relationships between such components)
[16:13] Tobias Kunze (Red Hat) -- scribing: Will hold off on issue until Cloudsoft is operative
[16:13] Tobias Kunze (Red Hat) -- scribing: http://tools.oasis-open.org/issues/browse/CAMP-9 Support sensors and effectors on components via API
[16:13] Tobias Kunze (Red Hat) -- scribing: will hold off as well so Alex can present

I'll be able to join for the start of tomorrow's meeting so could do it this?

In a nutshell:

CAMP-8:  MOSTLY ADDRESSED - by the shift to capabilities+requirements
However there are two minor concerns (maybe you've discussed these already):
(a) Where a component has a link to another component, can I find out what requirement(s) are being fulfilled by that link, or more generally what is the nature of that relationship?  ("is_parent_of", "is_child_of", "running_on_machine")
(b) Do we want a way to get a simple list of what constitutes an assembly?  Currently (as I understand it) the Assembly links to every component within it.  But it seems to me a useful and sufficient summary to have an API view which shows "MyApp" linking to just two components -- "WebCluster" and "ReplicatedDatabaseCluster".  Then e.g. "ReplicatedDatabaseCluster" links to Postgres and Rubyrep Components and they link to Machine platform components and a DDL application component.

CAMP-9:  OPEN - espeically on the effectors (operations) side
Attributes can be used for most types of metrics/sensors we want to expose.  (Though there is the risk we might miss intermediate values, that's a small point.)  But telling components to do things seems something we should include in the spec.  Also, advertising the operations (signatures) and attributes which are available.

Look forward to talking tomorrow.

Best,
Alex



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]