Re: Service Composition / Substitution Mapping

[DeWayne Filppi]

It occurs that it might be useful to be able to tag service templates with
arbitrary meta-data.  Perhaps at one level carried forward from a CSAR
manifest, but also user definable.  This would allow inter-service
references to be definitive, if desired.  This could be implicitly defined
as a capability by the orchestrator, but some kind of special requirement
type(s) would be needed to utilize it.  This way, external repos could be
used safely and directly without the separate load step.

On Tue, Aug 1, 2017 at 12:43 PM, Tal Liron  wrote:

> Thanks for the kudos. :)
>
> This topic was discussed on this list a while ago. It's indeed tricky to
> get right, because TOSCA leaves a lot of room for the orchestrator to
> implement.
>
> I'm thinking of it working something like this:
>
> 1. The reqs-and-caps engine by default will always look for satisfiable
> capabilities within the currently instantiated service. HOWEVER, if such a
> capability is not present, the option is there to look for another
> instantiated service that exposes the capabilities in substitution
> mappings.
>
> 2. If we DON'T have another instantiated service, but DO have a service
> template that could fit the bill, perhaps we need to instantiate that other
> service first. One obvious option is to do this automatically. But I feel
> like this can create unforeseen consequences -- for example, some dummy
> test template that someone happened to have in the database might get
> instantiated by mistake. Also, it might need to trigger multiple install
> workflows at once... a big mess. So I suggest that instead we provide a
> very detailed validation error here saying that the requirement cannot be
> satisfied, HOWEVER there exist service templates A, B, and C that can
> substitute for us, so maybe the nice user would like to instantiate them
> first? This seems very reasonable to me.
>
> 3. If indeed another service satisfies this, a special node is added to the
> current service (with the correct type -- but without a service template
> foreign key), which serves as a proxy of the other service template. I'm
> not sure how we would mark this exactly. We can't use the service_fk field,
> because it's still in our current service. So perhaps there's need of a new
> fk field, maybe substituted_service_fk?
>
> The above might be "sensible defaults," but it seems to me that users
> really need control over this. So I propose to add a new aria.Composition
> policy that would let you provide hints for this mechanism. For example,
> you might want to "filter" the target service by service template name and
> even by metadata in the service template. For example, you might want to
> require version 1.2.2 of a specific service, no less.
>
> Those are some quick thoughts. Exactly how such a policy would look with
> require more thought...
>
>
> On Tue, Aug 1, 2017 at 2:20 PM, Avia Efrat  wrote:
>
> > Hello all,
> >
> > I'm starting to work on a full implementation of substitution_mapping,
> > which will lead to the ability of service composition.
> >
> > For those unacquainted with substitution mapping, here are some quick
> > resources:
> > *From the spec
> >  > YAML/v1.0/TOSCA-Simple-Profile-YAML-v1.0.html>,
> > sections:*
> > 2.10
> >  > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#_Toc471725208>,
> > 2.11
> >  > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#_Toc471725209>
> > (theory and examples)
> > 3.8.1, 3.8.2 (grammar)
> > *From Tal's amazing lecture on TOSCA
> > :*
> > 00:00 until 12:30.
> >
> > If anyone wishes to:
> > * ask questions regarding this feature
> > * suggest real-life use cases
> > * offer their insight about vague parts of the spec
> > * anything else about substitution mapping and service composition
> > Then please, feel encouraged to leave your feedback!
> >
>

Re: Service Composition / Substitution Mapping

[Tal Liron]

Thanks for the kudos. :)

This topic was discussed on this list a while ago. It's indeed tricky to
get right, because TOSCA leaves a lot of room for the orchestrator to
implement.

I'm thinking of it working something like this:

1. The reqs-and-caps engine by default will always look for satisfiable
capabilities within the currently instantiated service. HOWEVER, if such a
capability is not present, the option is there to look for another
instantiated service that exposes the capabilities in substitution mappings.

2. If we DON'T have another instantiated service, but DO have a service
template that could fit the bill, perhaps we need to instantiate that other
service first. One obvious option is to do this automatically. But I feel
like this can create unforeseen consequences -- for example, some dummy
test template that someone happened to have in the database might get
instantiated by mistake. Also, it might need to trigger multiple install
workflows at once... a big mess. So I suggest that instead we provide a
very detailed validation error here saying that the requirement cannot be
satisfied, HOWEVER there exist service templates A, B, and C that can
substitute for us, so maybe the nice user would like to instantiate them
first? This seems very reasonable to me.

3. If indeed another service satisfies this, a special node is added to the
current service (with the correct type -- but without a service template
foreign key), which serves as a proxy of the other service template. I'm
not sure how we would mark this exactly. We can't use the service_fk field,
because it's still in our current service. So perhaps there's need of a new
fk field, maybe substituted_service_fk?

The above might be "sensible defaults," but it seems to me that users
really need control over this. So I propose to add a new aria.Composition
policy that would let you provide hints for this mechanism. For example,
you might want to "filter" the target service by service template name and
even by metadata in the service template. For example, you might want to
require version 1.2.2 of a specific service, no less.

Those are some quick thoughts. Exactly how such a policy would look with
require more thought...


On Tue, Aug 1, 2017 at 2:20 PM, Avia Efrat  wrote:

> Hello all,
>
> I'm starting to work on a full implementation of substitution_mapping,
> which will lead to the ability of service composition.
>
> For those unacquainted with substitution mapping, here are some quick
> resources:
> *From the spec
>  YAML/v1.0/TOSCA-Simple-Profile-YAML-v1.0.html>,
> sections:*
> 2.10
>  YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#_Toc471725208>,
> 2.11
>  YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#_Toc471725209>
> (theory and examples)
> 3.8.1, 3.8.2 (grammar)
> *From Tal's amazing lecture on TOSCA
> :*
> 00:00 until 12:30.
>
> If anyone wishes to:
> * ask questions regarding this feature
> * suggest real-life use cases
> * offer their insight about vague parts of the spec
> * anything else about substitution mapping and service composition
> Then please, feel encouraged to leave your feedback!
>

Service Composition / Substitution Mapping

[Avia Efrat]

Hello all,

I'm starting to work on a full implementation of substitution_mapping,
which will lead to the ability of service composition.

For those unacquainted with substitution mapping, here are some quick
resources:
*From the spec
,
sections:*
2.10
,
2.11

(theory and examples)
3.8.1, 3.8.2 (grammar)
*From Tal's amazing lecture on TOSCA
:*
00:00 until 12:30.

If anyone wishes to:
* ask questions regarding this feature
* suggest real-life use cases
* offer their insight about vague parts of the spec
* anything else about substitution mapping and service composition
Then please, feel encouraged to leave your feedback!

Re: Aria Backlog

[Thomas Nadeau]

Fantastic. Thanks!

> On Aug 1, 2017:2:59 PM, at 2:59 PM, Avia Efrat  wrote:
> 
> In the view you linked to, the issues are listed in a numerical order (only
> issues that are not resolved/closed are shown there).
> You can see their priority by the small icon to the right of the issue name.
> 
> Personally, I don't use this view. I use:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARIA%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)
> 
> There, you can easily sort and search the issues.
> 
> On Tue, Aug 1, 2017 at 9:33 PM, Thomas Nadeau 
> wrote:
> 
>> 
>>Forgive me for asking a dumb question here, but is the backlog as
>> listed here groomed?
>> That is, are the stories/epics listed in priority order or just
>> numerically?
>> 
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?
>> rapidView=150=ARIA=planning.nodetail <
>> https://issues.apache.org/jira/secure/RapidBoard.jspa?
>> rapidView=150=ARIA=planning.nodetail>
>> 
>>—Tom
>> 
>> 

Re: Aria Backlog

[Avia Efrat]

In the view you linked to, the issues are listed in a numerical order (only
issues that are not resolved/closed are shown there).
You can see their priority by the small icon to the right of the issue name.

Personally, I don't use this view. I use:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARIA%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)

There, you can easily sort and search the issues.

On Tue, Aug 1, 2017 at 9:33 PM, Thomas Nadeau 
wrote:

>
> Forgive me for asking a dumb question here, but is the backlog as
> listed here groomed?
> That is, are the stories/epics listed in priority order or just
> numerically?
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?
> rapidView=150=ARIA=planning.nodetail <
> https://issues.apache.org/jira/secure/RapidBoard.jspa?
> rapidView=150=ARIA=planning.nodetail>
>
> —Tom
>
>

Aria Backlog

[Thomas Nadeau]

Forgive me for asking a dumb question here, but is the backlog as 
listed here groomed?
That is, are the stories/epics listed in priority order or just numerically?

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=150=ARIA=planning.nodetail
 


—Tom

Re: Query on operation inputs

[Avia Efrat]

Quick update on this issue:
We merged the relevant pull request:
https://github.com/apache/incubator-ariatosca/pull/187
Now inputs behave as expected.


On Tue, Jul 11, 2017 at 5:39 AM, D Jayachandran  wrote:

> Hi Avia,
>
> Thanks for the detailed explanation. Finally we have better clarity and
> are in the same page.
>
> Regards,
> DJ
>
> -Original Message-
> From: Avia Efrat [mailto:a...@gigaspaces.com]
> Sent: Tuesday, July 11, 2017 3:42 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Query on operation inputs
>
> Here is the Jira issue:
> https://issues.apache.org/jira/browse/ARIA-313
>
> On Tue, Jul 11, 2017 at 12:44 AM, Ran Ziv  wrote:
>
> > Avia, could you please create a JIRA issue for this?
> >
> >
> > On Mon, Jul 10, 2017 at 5:12 PM, Avia Efrat  wrote:
> >
> > > Hello DJ,
> > >
> > > I ran the example you provided: https://github.com/djay8887/Ar
> > > ia-operationInputs [It should be noted that you can't just parse the
> > > service template kubernetes-deployment.yaml as is. I needed to
> > > create a folder named type and place kubernetes_type.yaml in there,
> > > as the import: section in your service templates contains `-
> > > *types*/kubernetes_type.yaml`]
> > >
> > > *Short answer:*
> > > You are correct, the example should pass, and we will change the
> > > code accordingly.
> > >
> > > *Longer answer + explanations:*
> > > I will separate my answer into three parts. I will repeat some of
> > > what
> > was
> > > said before me, but I think it will help clear the situation.
> > > 1. The result of my run.
> > > 2. Why do we currently get this error.
> > > 3. Our revised understanding of the TOSCA spec regarding the
> > > required
> > field
> > > of node type operation inputs.
> > >
> > > *1.* *The result of my run:*
> > > The commands I ran were:
> > > aria plugins install sample-1.0.0-py27-none-any.wgn aria
> > > service-templates store kubernetes-deployment.yaml dj aria services
> > > create -t dj dj aria executions start -s dj install after running
> > > the last command I got:
> > > Declared parameters "labels" have not been provided values
> > >
> > > *2.* *Why do we currently get this error:* First, let my just
> > > clarify, that this error has no relation whatsoever to the contents
> > > of the inputs section under topology_template.
> > > We are dealing here only with the inputs section of an operation,
> > > which
> > is
> > > section 3.5.13 Operation Definition .
> > > Currently, when we execute a workflow (aria executions start ...),
> > > we
> > check
> > > the inputs of each operation in the following manner (ignoring
> > > interface inputs for now):
> > > we check that every input defined in the input section of the node
> > template
> > > operation, whether the input is required or not has a value, has a
> value.
> > > This check is done in the merge_parameters_value function, inside
> > > aria/modelling/utils, so you can check the logic yourself.
> > >
> > > Anyway, these values can be supplied directly from the service
> > > template,
> > or
> > > in an indirect way via execution inputs, or programmatically when
> > creating
> > > workflow tasks. The latter method shouldn't concern us now, as we
> > > are dealing with the operation inputs that were provided in the
> > > inputs
> > section
> > > of the operation.
> > >
> > > So, in conclusion, we get this error since the labels input is not
> > assigned
> > > a value in the inputs section of the operation inside the node
> template.
> > > This happens even if the input is defined as required: false in the
> > inputs
> > > section of the operation inside the node *type*.
> > >
> > > *3. **Our revised understanding of the TOSCA spec regarding the
> > > required field operation definition inputs:* After rechecking the
> > > spec, we feel that an operation input that has
> > > required:
> > > false  indeed allows it not to be defined in the corresponding
> > > operation
> > in
> > > the service template. We base this on section 3.5.13.1 Operation
> > Definition
> > > keyname . This section clearly state the node
> > type
> > > operation inputs are of type property definitions (3.5.8)
> > >  > > YAML/v1.0/os/TOSCA-Simple-Profile-YAML-v1.0-os.html#
> > > DEFN_ELEMENT_PROPERTY_DEFN>
> > > .
> > >
> > > Therefore, the required field of a node type operation input is the
> > > same
> > as
> > > the required field in a node type property.
> > >
> > > So, just as you can omit in a node template property that has required:
> > > false in its corresponding node type property, you can omit a node
> > template
> > > operation input that has required: false in its corresponding node
> > > type operation input.
> > >
> > >
> > >
> > >
> > > On Mon, Jul 3, 2017 at 10:17 PM, Tal Liron  wrote:
> > >
> > > > Oops, it seems your 

Re: Contribution to aria

[Thomas Nadeau]

I think people here are pretty welcoming with contributions or figuring 
things out.  
At least the ones I’ve spoken with have been. 8)

As for what to work on, you can look here at the backlog for unassigned 
issues here:

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=150=ARIA=planning.nodetail
 


—Tom



> On Aug 1, 2017:9:44 AM, at 9:44 AM, yuval yaari  wrote:
> 
> Hi,
> I was participating on your two days tosca/cloudify course at AT in
> israel.
> You have talked about aria and i was wondering if and how i can contribute
> some code.
> Im not really a python developer (have almost 6 years java experience) and
> one of my goals is to improve my python skills by contributing to open
> source projects.
> Is there any easy/low hanging fruits bugs or mini features that you think i
> can help with as a starting point?
> How do i get started with open source?
> 
> Any help will be much appreciated,
> 
> Thanks,
> Yuval

Contribution to aria

[yuval yaari]

Hi,
I was participating on your two days tosca/cloudify course at AT in
israel.
You have talked about aria and i was wondering if and how i can contribute
some code.
Im not really a python developer (have almost 6 years java experience) and
one of my goals is to improve my python skills by contributing to open
source projects.
Is there any easy/low hanging fruits bugs or mini features that you think i
can help with as a starting point?
How do i get started with open source?

Any help will be much appreciated,

Thanks,
Yuval

Re: Inputs and Node object context for python and shell scripts

[Maxim Orlov]

Sorry for the broken email, it seems my markup translator has some funky
behavior. The code block is:

from aria import operation

@operation
def samplemethod(ctx=None, **inputs):
  print "ctx -->",ctx
  print "inputs -->",inputs
  ctx.node.attributes['test'] = "abc"


On Tue, Aug 1, 2017 at 1:48 PM Maxim Orlov  wrote:

> Oh, i see. For each method which represents an operation, you should use
> the @operation decorator. Thus samplemethod would look like this:
>
> from aria import operation
> @operation
>
> def samplemethod(ctx=None, **inputs):
> print "ctx -->",ctx
> print "inputs -->",inputs
> ctx.node.attributes['test'] = "abc"
>
> It is actually this decorator which wraps the attribute model for you.
>
> p.s.
> the ctx comes with its own logger, thus using ctx.logger.info("ctx -->
> {0}".format(ctx)) instead of print "ctx -->", ctx. This will persist your
> logs, and in case of remote execution, print your logs to the local
> terminal.
> ​
>
> On Tue, Aug 1, 2017 at 11:30 AM D Jayachandran <
> d.jayachand...@ericsson.com> wrote:
>
>> Hi Max,
>>
>> I have a service template with just node templates web_app and database
>> with a depends on Relationship. Both use the same custom node type derived
>> from "tosca:Root".
>> I just have the create operation defined where the implementation points
>> to a plugin module. Am trying to set the attribute value in the plugin.
>> Please find below service template and node types
>>
>> SERVICE TEMPLATE
>>
>> tosca_definitions_version: tosca_simple_yaml_1_0
>>
>> imports:
>>   - types/kubernetes_type.yaml
>>   - aria-1.0
>>
>> topology_template:
>>
>> inputs:
>> web_app_name:
>> type: string
>> value: tosca-webapp
>>
>> web_app_image:
>> type: string
>> value: kuber-master:5000/webwithdbinput
>>
>> web_app_port:
>> type: integer
>> value: 80
>>
>> db_name:
>> type: string
>> value: tosca-database
>>
>> db_image:
>> type: string
>> value: kuber-master:5000/dbforweb
>>
>> db_port:
>> type: integer
>> value: 3306
>>
>>
>> policies:
>>   testplugin:
>> type: aria.Plugin
>> description: policy_description
>> properties:
>> version: 1.2.0
>> enabled: true
>>
>> node_templates:
>> web_app:
>> type: nodes.Container.Application.Kubernetes
>> properties:
>> name: { get_input: web_app_name }
>> image: { get_input: web_app_image }
>> port: { get_input: web_app_port }
>> attributes:
>> test: abc
>> requirements:
>> - dependency:
>>   node: database
>>   relationship:
>>   type: tosca.relationships.DependsOn
>> interfaces:
>> Standard:
>> inputs:
>> name: { get_property: [ web_app, name] }
>> image: { get_property: [ web_app, image] }
>> exposed_port: { get_property: [ web_app, port] }
>> target_host: { get_property: [ database, name] }
>> target_port: { get_property: [ database, port] }
>> isService: true
>> create:
>> inputs:
>> name: { get_property: [ web_app, name] }
>> image: { get_property: [ web_app, image] }
>> exposed_port: { get_property: [ web_app,
>> port] }
>> target_host: { get_property: [ database,
>> name] }
>> #target_port: { get_property: [ database,
>> port] }
>> target_port: 
>> isService: false
>>
>> database:
>> type: nodes.Container.Application.Kubernetes
>> properties:
>> name: { get_input: db_name }
>> image: { get_input: db_image }
>> port: { get_input: db_port }
>> interfaces:
>> Standard:
>> inputs:
>> name: { get_property: [ database, name] }
>> image: { get_property: [ database, image] }
>> exposed_port: { get_property: [ database, port] }
>> isService: true
>> create:
>> inputs:
>> name: { get_property: [ database, name] }
>> image: { get_property: [ database, image] }
>> exposed_port: { get_property: [ database,
>> port] }
>> isService: true
>>
>> NODE TYPES
>>

Re: Inputs and Node object context for python and shell scripts

[Maxim Orlov]

Oh, i see. For each method which represents an operation, you should use
the @operation decorator. Thus samplemethod would look like this:

from aria import operation
@operationdef samplemethod(ctx=None, **inputs):
print "ctx -->",ctx
print "inputs -->",inputs
ctx.node.attributes['test'] = "abc"

It is actually this decorator which wraps the attribute model for you.

p.s.
the ctx comes with its own logger, thus using ctx.logger.info("ctx -->
{0}".format(ctx)) instead of print "ctx -->", ctx. This will persist your
logs, and in case of remote execution, print your logs to the local
terminal.
​

On Tue, Aug 1, 2017 at 11:30 AM D Jayachandran 
wrote:

> Hi Max,
>
> I have a service template with just node templates web_app and database
> with a depends on Relationship. Both use the same custom node type derived
> from "tosca:Root".
> I just have the create operation defined where the implementation points
> to a plugin module. Am trying to set the attribute value in the plugin.
> Please find below service template and node types
>
> SERVICE TEMPLATE
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
> imports:
>   - types/kubernetes_type.yaml
>   - aria-1.0
>
> topology_template:
>
> inputs:
> web_app_name:
> type: string
> value: tosca-webapp
>
> web_app_image:
> type: string
> value: kuber-master:5000/webwithdbinput
>
> web_app_port:
> type: integer
> value: 80
>
> db_name:
> type: string
> value: tosca-database
>
> db_image:
> type: string
> value: kuber-master:5000/dbforweb
>
> db_port:
> type: integer
> value: 3306
>
>
> policies:
>   testplugin:
> type: aria.Plugin
> description: policy_description
> properties:
> version: 1.2.0
> enabled: true
>
> node_templates:
> web_app:
> type: nodes.Container.Application.Kubernetes
> properties:
> name: { get_input: web_app_name }
> image: { get_input: web_app_image }
> port: { get_input: web_app_port }
> attributes:
> test: abc
> requirements:
> - dependency:
>   node: database
>   relationship:
>   type: tosca.relationships.DependsOn
> interfaces:
> Standard:
> inputs:
> name: { get_property: [ web_app, name] }
> image: { get_property: [ web_app, image] }
> exposed_port: { get_property: [ web_app, port] }
> target_host: { get_property: [ database, name] }
> target_port: { get_property: [ database, port] }
> isService: true
> create:
> inputs:
> name: { get_property: [ web_app, name] }
> image: { get_property: [ web_app, image] }
> exposed_port: { get_property: [ web_app, port]
> }
> target_host: { get_property: [ database, name]
> }
> #target_port: { get_property: [ database,
> port] }
> target_port: 
> isService: false
>
> database:
> type: nodes.Container.Application.Kubernetes
> properties:
> name: { get_input: db_name }
> image: { get_input: db_image }
> port: { get_input: db_port }
> interfaces:
> Standard:
> inputs:
> name: { get_property: [ database, name] }
> image: { get_property: [ database, image] }
> exposed_port: { get_property: [ database, port] }
> isService: true
> create:
> inputs:
> name: { get_property: [ database, name] }
> image: { get_property: [ database, image] }
> exposed_port: { get_property: [ database,
> port] }
> isService: true
>
> NODE TYPES
>
> node_types:
> nodes.Container.Application.Kubernetes:
> derived_from: tosca.nodes.Root
> #derived_from: tosca:Root
> properties:
> name:
>   type: string
>   required: true
> image:
>   type: string
>   required: true
> port:
>   type: integer
>   required: false
> attributes:
> test:
>   type: string
> 

RE: Inputs and Node object context for python and shell scripts

[D Jayachandran]

Hi Max,

I have a service template with just node templates web_app and database with a 
depends on Relationship. Both use the same custom node type derived from 
"tosca:Root".
I just have the create operation defined where the implementation points to a 
plugin module. Am trying to set the attribute value in the plugin. Please find 
below service template and node types

SERVICE TEMPLATE

tosca_definitions_version: tosca_simple_yaml_1_0

imports:
  - types/kubernetes_type.yaml 
  - aria-1.0

topology_template:

inputs:
web_app_name:
type: string
value: tosca-webapp

web_app_image:
type: string
value: kuber-master:5000/webwithdbinput

web_app_port:
type: integer
value: 80

db_name:
type: string
value: tosca-database

db_image:
type: string
value: kuber-master:5000/dbforweb

db_port:
type: integer
value: 3306


policies:
  testplugin: 
type: aria.Plugin 
description: policy_description
properties:
version: 1.2.0 
enabled: true

node_templates:
web_app:
type: nodes.Container.Application.Kubernetes
properties:
name: { get_input: web_app_name }
image: { get_input: web_app_image }
port: { get_input: web_app_port }
attributes:
test: abc
requirements:
- dependency:
  node: database
  relationship:
  type: tosca.relationships.DependsOn
interfaces:
Standard:
inputs: 
name: { get_property: [ web_app, name] }
image: { get_property: [ web_app, image] }
exposed_port: { get_property: [ web_app, port] }
target_host: { get_property: [ database, name] }
target_port: { get_property: [ database, port] }
isService: true
create: 
inputs:
name: { get_property: [ web_app, name] }
image: { get_property: [ web_app, image] }
exposed_port: { get_property: [ web_app, port] }
target_host: { get_property: [ database, name] }
#target_port: { get_property: [ database, port] }
target_port:  
isService: false 

database:
type: nodes.Container.Application.Kubernetes
properties:
name: { get_input: db_name }
image: { get_input: db_image }
port: { get_input: db_port }
interfaces:
Standard:
inputs: 
name: { get_property: [ database, name] }
image: { get_property: [ database, image] }
exposed_port: { get_property: [ database, port] }
isService: true
create:
inputs: 
name: { get_property: [ database, name] }
image: { get_property: [ database, image] }
exposed_port: { get_property: [ database, port] }
isService: true

NODE TYPES

node_types:
nodes.Container.Application.Kubernetes:
derived_from: tosca.nodes.Root
#derived_from: tosca:Root 
properties:
name:
  type: string
  required: true
image:
  type: string
  required: true
port:
  type: integer
  required: false
attributes:
test:
  type: string
interfaces:
Standard:
type: tosca.interfaces.node.lifecycle.Standard
inputs: 
name:
type: string
required: true
image:
type: string
required: true
exposed_port:
type: integer
required: false
target_port:
type: integer
required: false
default: 8080
target_host:
type: string
required: false
default: None
labels:
type: string
required: false
default: test