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: RE: dangling requirements


Hi Shitao,

 

That’s a good question. I’ve been experimenting with TOSCA models to represent IaaS clouds (such as AWS or OpenStack). Those models could be used to “onboard” cloud resources in the orchestrator’s inventory, and they could potentially provide the capabilities required by VDU.Compute nodes.

 

I’m not yet 100% sure that that is the right approach, but perhaps we can discuss this use case when we talk more about dangling requirements in the TOSCA Language Ad-Hoc meetings.

 

Chris

 

From: Lishitao [mailto:lishitao@huawei.com]
Sent: Wednesday, July 17, 2019 12:52 AM
To: Chris Lauwers <lauwers@ubicity.com>; arturo.martin-de-nicolas@ericsson.com; Calin Curescu (calin.curescu@ericsson.com) <calin.curescu@ericsson.com>; Priya T G (priya.g@netcracker.com) <priya.g@netcracker.com>; gabor.marton@nokia.com; 'Nguyenphu, Thinh (Nokia - US/Irving)' (thinh.nguyenphu@nokia.com) <thinh.nguyenphu@nokia.com>
Cc: tosca@lists.oasis-open.org
Subject: re: dangling requirements

 

Hi Chris

 

I missed the call yesterday. Thanks for sharing this discussion in the email list. I think your analysis make sense. Regarding a particular use case, for example the one I posted on the TOSCA website about the VDU design, which option do you think can be considered to be used?

https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/65469

 

tosca_definitions_version: tosca_simple_yaml_1_2

..

dsl_definitions:

  virtual_compute_filter: &virtual_compute_filter

    capabilities:

      - virtual_compute:

          properties:

            - virtual_memory:

                - equal:

                    virtual_mem_size: 8192 MiB

            - virtual_cpu:

                - equal:

                    cpu_architecture: x86

                    num_virtual_cpu: 2

                    virtual_cpu_clock: 1800 MHz

 

topology_template:

  ..

 

  node_templates:

    dbBackend:

      type: tosca.nodes.nfv.Vdu.Compute

      properties:

      ..

      requirements:

        - virtual_compute:

            node_filter: *virtual_compute_filter

 

    ServiceNode:

      type: tosca.nodes.nfv.Vdu.Compute

      properties:

      ..

      requirements:

        - virtual_compute:

            node_filter: *virtual_compute_filter

 

 

    ..

 

Regards

shitao

 

发件人: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] 代表 Chris Lauwers
发送时间: 2019717 9:09
收件人: arturo.martin-de-nicolas@ericsson.com; Calin Curescu (calin.curescu@ericsson.com) <calin.curescu@ericsson.com>; Priya T G (priya.g@netcracker.com) <priya.g@netcracker.com>; gabor.marton@nokia.com; 'Nguyenphu, Thinh (Nokia - US/Irving)' (thinh.nguyenphu@nokia.com) <thinh.nguyenphu@nokia.com>
抄送: tosca@lists.oasis-open.org
主题: [tosca] dangling requirements

 

I’d like to continue the discussion we started during our Tuesday meeting about dangling requirements. I believe we can all agree that the current specification isn’t very clear about how requirements are intended to be used, and specifically about how dangling requirements are supposed to be ‘fulfilled’.

 

In my opinion, an orchestrator has 4 options for fulfilling dangling requirements in node templates. It can obtain a target node for the requirement as follows:

 

1.       Using a node that is “orchestrated” from a node template in the same service template.

2.       Using a node that is “orchestrated” on-demand from a node template in a different service template (note that this would require instantiating the entire service that contains the desired target node).

3.       Using an already-existing node that was created as part of orchestrating a different service. Presumably, the orchestrator would use an “active inventory” that allows it to find such nodes.

4.       Using a node that represents an available resource. This presumes that TOSCA is used to model resources (as well as orchestrated entities) and that the orchestrator uses an “available inventory” that allows it to find such resource nodes.

 

In my opinion, only 3 and 4 are valuable options:

 

-          Option nr. 1 isn’t very useful. If a service template includes both the node with the (dangling) requirement as well as the target node for that requirement, then why not model the relationship directly, rather than using a dangling requirement. If multiple options must be supported, one of which must be selected at deployment time, then using substitution mapping to address this requirement is a better way to go.

-          Option nr. 2 is not practical (and in my opinion not implementable). If an orchestrator needs to deploy a service just to create a node that can fulfill a requirement, then where will the input values come from that are needed by this service? Also, how do node filters fit into this scenario? Node filters represent a “query” against some inventory of available options. I’m not sure how we would run a “query” against a set of templates from which to choose.

 

Options 3 and 4 represent the only viable options in my opinion:

 

-          Orchestrators keep an “active and available inventory” that stores representations of all the entities that already exist (either because they represent resource that have been made available to the orchestrator or because they represent services that were previously created by that orchestrator)

-          A node filter represents the “query” that is used by the orchestrator to retrieve valid options from the available and active inventory.

 

Please let me know if you have differing opinions.

 

Thanks,

 

Chris

 



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