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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

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


Subject: [OASIS Issue Tracker] (TOSCA-220) get_artifact function


    [ https://issues.oasis-open.org/browse/TOSCA-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59349#comment-59349 ] 

Luc Boutier commented on TOSCA-220:
-----------------------------------

Hi Idan,

I just added the comment as we talked about this as a reference in yesterday call. But the goal of get_artifact is indeed to reference a TOSCA artifact. The path of the artifact may change depending of orchestrator implementation (where it copy things - how it manage repositories).

Actually I think that we may have a tosca node that reference an artifact on a public repo (internet) and the orchestrator moves it to a private repo before actually installing the application (because my production private cloud doesn't have internet access for sec reasons). If so I need the get_artifact to give me the internal private repo url that will override the default one from the node.

So to make it simple it's not the exact same thing as get_file, I'm going to elaborate a better description for get_artifact for tomorrow morning and I guess this is something we will discuss in next Simple Profile call.

Luc

> get_artifact function
> ---------------------
>
>                 Key: TOSCA-220
>                 URL: https://issues.oasis-open.org/browse/TOSCA-220
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: New Feature
>          Components: Profile-YAML
>            Reporter: Luc Boutier
>
> Currently the specification allows to define functions like get_attribute or get_input to be used as input parameters of an operation.
> Actually we may have scenarios where we want also to provide an artifact as an input:
> Let's consider that I want to host 2 database on a single RDBMS or 2 war on a container.
> I want to define a script that is generic so it can handle an artifact based on any location (let's consider the type is file). In order to do so I expect the orchestrator to provide me the actual location of the artifact "db_content" for example. Just like attribute of a node I should be able to access it through an environment variable set by the orchestrator.
> syntax is the same as get_attribute but the value set to the environment variable is the actual artifact location.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


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