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: [OASIS Issue Tracker] Commented: (CAMP-8) Support a hierarchical model of platform components at runtime (or typed relationships between such components)


    [ http://tools.oasis-open.org/issues/browse/CAMP-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31720#action_31720 ] 

Alex Heneveld commented on CAMP-8:
----------------------------------

Reason for closing is that now with custom attributes we have a way to do this -- as an extension essentially.
If we find it useful as something which should be standardized we can then make official attributes for this purpose.

> Support a hierarchical model of platform components at runtime (or typed relationships between such components)
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMP-8
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-8
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: New Feature
>          Components: Spec
>            Reporter: Anish Karmarkar
>
> It would be useful if PlatformComponents could have Set children at runtime, exposed through the API at runtime. For instance a notional ElasticWebCluster (platform component) could be built of an NginxComponent and multiple TomcatComponents (s/Tomcat/JBoss/Glassfish/etc) all of which are also platform components.
> This would support a hierarchical view of what the application is consuming, so a user can see a high-level model (e.g. just the tiers) then drill-down as needed to see the clusters for each tier in each location, then even the individual processes making up that cluster.
> This wouldn't be required, but to the extent the user wants to and the PaaS provider is willing to, this is quite a powerful and helpful capability, especially when debugging and working at scale.
> *Alternatively* a "typed relationship" model could be used, similar to that used in graphs, where "IS_PARENT_OF" is one common relationship but other relationships could be defined. This might have other benefits such as noting inter-component requirements and dependencies.
> This was raised by Alex Heneveld and was drupal issue # 1059

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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