summaryrefslogtreecommitdiffstats
path: root/tosca2heat/heat-translator/translator/tests/data/test_tosca_nfv_sample.yaml
blob: 5803bd2614fa34341b41772fdcdfe719d20f5aaf (plain) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0

description: Template for deploying a single server with predefined properties.

topology_template:
  node_templates:

    VDU1:
      type: tosca.nodes.nfv.VDU
      capabilities:
        host:
         properties:
           num_cpus: 1
           disk_size: 1 GB
           mem_size: 512 MB
        # Guest Operating System properties
        os:
          properties:
           # host Operating System image properties
            architecture: x86_64
            type: Linux
            distribution: RHEL
            version: 6.5
      requirements:
        - high_availability: VDU2
        - local_storage:
            node: BlockStorage
            relationship:
              type: tosca.relationships.AttachesTo
              properties:
                location: /dev/vdb1

    BlockStorage:
      type: tosca.nodes.BlockStorage
      properties:
        size: 1 GB

    VDU2:
      type: tosca.nodes.nfv.VDU
      capabilities:
        host:
         properties:
           num_cpus: 1
           disk_size: 1 GB
           mem_size: 512 MB
        # Guest Operating System properties
        os:
          properties:
           # host Operating System image properties
            architecture: x86_64
            type: Linux
            distribution: RHEL
            version: 6.5

    CP1:
      type: tosca.nodes.nfv.CP
      properties:
        ip_address: 192.168.0.55
      requirements:
        - virtualLink:
            node: VL1
#           relationship: tosca.relationships.nfv.VirtualLinksTo
        - virtualBinding:
            node: VDU1
            relationship: tosca.relationships.nfv.VirtualBindsTo

    CP2:
      type: tosca.nodes.nfv.CP
      properties:
        ip_address: 192.168.0.56
      requirements:
        - virtualLink:
            node: VL1
#           relationship: tosca.relationships.nfv.VirtualLinksTo
        - virtualBinding:
            node: VDU2
            relationship: tosca.relationships.nfv.VirtualBindsTo

    VL1:
      type: tosca.nodes.nfv.VL
      properties:
        vendor: ACME
        cidr: '192.168.0.0/24'
        start_ip: '192.168.0.50'
        end_ip: '192.168.0.200'
        gateway_ip: '192.168.0.1'
        network_name: test_net
        network_type: vxlan
        segmentation_id: 100
n> *create-reservation* """""""""""""""""""" This operation allows making a request to the reservation system to reserve resources. The operation takes the following input parameters: * start: start time of the requested reservation * end: end time of the requested reservation * capacity.instances: amount of instances to be reserved * capacity.cores: amount of cores to be reserved * capacity.ram: amount of ram in MB to be reserved Promise will check the available capacity in the given time window and in case sufficient capacity exists to meet the reservation request, will mark those resources "reserved" in its reservation map. *update-reservation* """""""""""""""""""" This operation allows to update the reservation details for an existing reservation. It can take the same input parameters as in *create-reservation* but in addition requires a mandatory reference to the *reservation-id* of the reservation that shall be updated. *cancel-reservation* """""""""""""""""""" This operation is used to cancel an existing reservation. The operation takes the following input parameter: * reservation-id (mandatory): identifier of the reservation to be canceled. *query-reservation* """"""""""""""""""" The operation queries the reservation system to return reservation(s) matching the specified query filter, e.g., reservations that are within a specified start/end time window. The operation takes the following input parameters to narrow down the query results: * without: excludes specified collection identifiers from the result * elements.some: query for ResourceCollection(s) that contain some or more of these element(s) * elements.every: query for ResourceCollection(s) that contain all of these element(s) * window.start: matches entries that are within the specified start/ * window.end: end time window * window.scope: if set to 'exclusive', only reservations with start AND end time within the time window are returned. Otherwise ('inclusive'), all reservation starting OR ending in the time windows are returned. * show-utilization: boolean value that specifies whether to also return the resource utilization in the queried time window or not Allocation management ^^^^^^^^^^^^^^^^^^^^^ *create-instance* """"""""""""""""" This operation is used to create an instance of specified resource(s) for immediate use utilizing capacity from the pool. *Create-instance* requests can be issued against an existing reservation, but also allocations without a reference to an existing reservation are allowed. In case the allocation request specifies a reservation identifier, Promise checks if a reservation with that ID exists, the reservation start time has arrived (i.e. the reservation is 'active'), and the required capacity for the requested flavor is within the available capacity of the reservation. If those conditions are met, Promise creates a record for the allocation (VMState="INITIALIZED") and update its databases. If no *reservation_id* was provided in the allocation request, Promise checks whether the required capacity to meet the request can be provided from the available, non-reserved capacity. If yes, Promise creates a record for the allocation with an unique *instance-id* and update its databases. In any other case, Promise rejects the *create-instance* request. In case the *create-instance* request is rejected, Promise responds with a "status=rejected" providing the reason of the rejection. This will help the Consumer to take appropriate actions, e.g., send an updated *create-instance* request. In case the *create-instance* request was accepted and a related allocation record has been created, the shim-layer issues a *createServer* request to the VIM Controller (i.e. Nova) providing all information to create the server instance. The operation takes the following input parameters: * name (mandatory): Assigned name for the instance to be created * image (mandatory): the image to be booted in the new instance * flavor (mandatory): the flavor of the requested server instance * networks: the list of network uuids of the requested server instance * provider-id: identifier of the provider where the instance shall be created * reservation-id: identifier of a resource reservation the *create-instance* The Euphrates implementation of Promise has the following limitations: * All create server instance requests shall pass through the Promise shim-layer such that Promise can keep track of all allocation requests. This is necessary as in the current release the sychronization between the VIM Controller and Promise on the available capacity is not yet implemented. * *Create-allocation* requests are limited to "simple" allocations, i.e., the current workflow only supports the Nova compute service and *create-allocation* requests are limited to creating one server instance at a time * Prioritization of reservations and allocations is yet not implemented. Future version may allow certain policy-based conflict resolution where, e.g., new allocation request with high priority can "forcefully" terminate lower priority allocations. *destroy-instance* """""""""""""""""" This operation request to destroy an existing server instance and release it back to the pool. The operation takes the following input parameter: * instance-id: identifier of the server instance to be destroyed Capacity management ^^^^^^^^^^^^^^^^^^^ The capacity management feature allows the Consumer or Administrator to do capacity planning, i.e. the capacity available to the reservation management can differ from the actual capacity in the registered provider(s). This feature can, e.g., be used to limit the available capacity for a given time window due to a planned downtime of some of the resources, or increase the capacity available to the reservation system in case of a planned upgrade of the available capacity. *increase/decrease-capacity* """""""""""""""""""""""""""" This operations allows to increase/decrease the total capacity that is made available to the Promise reservation service between a specified window in time. It does NOT increase the actual capacity of a given resource provider, but is used for capacity management inside Promise. This feature can be used in different ways, like * Limit the capacity available to the reservation system to a value below 100% of the available capacity in the VIM, e.g., in order to leave "buffer" in the actual NFVI to be used outside the Promise reservation service. * Inform the reservation system that, from a given time in the future, additional resources can be reserved, e.g., due to a planned upgrade of the available capacity of the provider. * Similarily, the "decrease-capacity" can be used to reduce the consumable resources in a given time window, e.g., to prepare for a planned downtime of some of the resources. * Expose multiple reservation service instances to different consumers sharing the same resource provider. The operation takes the following input parameters: * start: start time for the increased/decreased capacity * end: end time for the increased/decreased capacity * capacity.cores: Increased/decreased amount of cores * capacity.ram: Increased/decreased amount of RAM * capacity.instances: Increased/decreased amount of instances Note, increase/decreasing the capacity in Promise is completely transparent to the VIM. As such, when increasing the virtual capacity in Promise (e.g. for a planned upgrade of the capacity), it is in the responsibility of the Consumer/Administrator to ensure sufficient resources in the VIM are available at the appropriate time, in order to prevent allocations against reservations to fail due to a lack of resources. Therefore, this operations should only be used carefully. *query-capacity* """""""""""""""" This operation is used to query the available capacity information of the specified resource collection. A filter attribute can be specified to narrow down the query results. The current implementation supports the following filter criteria: * time window: returns reservations matching the specified window * window scope: if set to 'exclusive', only reservations with start AND end time within the time window are returned. Otherwise, all reservation starting OR ending in the time windows are returned. * metric: query for one of the following capacity metrics: * 'total': resource pools * 'reserved': reserved resources * 'usage': resource allocations * 'available': remaining capacity, i.e. neither reserved nor allocated .. _multi-provider: (Multi-)provider management ^^^^^^^^^^^^^^^^^^^^^^^^^^^ This API towards OpenStack allows a Consumer/Administrator to add and remove resource providers to Promise. Note, Promise supports a multi-provider configuration, however, for Euphrates, multi-provider support is not yet fully supported. *add-provider* """""""""""""" This operation is used to register a new resource provider into the Promise reservation system. Note, for Euphrates, the add-provider operation should only be used to register one provider with the Promise shim-layer. Further note that currently only OpenStack is supported as a provider. The operation takes the following input parameters: * provider-type = 'openstack': select a specific resource provider type. * endpoint : target URL endpoint for the resource provider. * username : name of the user * password : user password * user-domain-name : domain name of the user * project.name : name of the OpenStack project * project.domain-name : domain name of the OpenStack project .. [#f1] Promise requirement document, http://artifacts.opnfv.org/promise/docs/development_requirements/index.html .. [#f2] YangForge framework, http://github.com/opnfv/yangforge