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: Compute node comments


I've tryed to compile a complete Cumpute node description collecting stuff from spec and trying to fill in the blanks where I did not found any example.
Will create a specific issue for all points as soon as my Jira account gets activated.
 
My concerns are:
1) we are missing the root_user password definition (probably demanding the task to the templates in the Cloud, but we need to get the password from the end user and not keep the standard one from the cloud)
2) There is no example on using an ISO and not trying to find a template that matches the os requirement; the two should be mutually exclusive
3) we are not creating users in the SO as the description in the standard goes we are having just the root user with the default password no other thins are there and we are hiding the creation of the users in the creation of the components (MySQL create one and we do not need to declare in the template of course) but we could need to create new users and we are missing the proper syntax
4) all VMs are created with at least the guest network BUT no public IP unless we require to the cloud (and this is tipically done using another APi call) the Compute should declare an array tosca.nodes.network.Port as a capability representing the fact that we want a set of NIC (if I understood well the port should represent a NIC even if the "port" name suggest a single port and in the description of the node there is nothing that describe a PORT); in the end here in the compute we need a list of NIC that are linked to the network and in my opinion transforming this "node" into a capability of the Compute should be easier ... but I'm sure that I'm missing something here :D
5) We need to address the things that could already be present in the environment: logacally a node in the template should represent something that needs to be created, a network could not be created, but just refered to (that is the guest network or the public one). If, as in the example, I specify the network I'm expecting to issue a create API commend to the cloud to create the network and than do the stuff; while that is possible and we need the standard I also needs the chance to declare that I'm using the existing resource (the problem apply also to pre-exisiting DB or other things we do not create but provide the reference to establish a relation)
6) where do we configure the firewall and the opened ports in the Compute resource?
7) once we acquire a public IP (something that is not an attribute of the VM) how we declare the port mapping? All that part on the network has too many declarations to be easy to understand we have: tosca.nodes.network.Port, tosca.nodes.network.Network, tosca.capabilities.Endpoint, tosca.datatypes.network.PortSpec, tosca.datatypes.network.PortDef, tosca.datatypes.network.PortInfo, tosca.datatypes.network.NetworkInfo but I have big difficulty in understanding how to declare the fact that I want a Compute resource than a public IP resource and I need to add rules to map port 80 of the eth0 in the Compute to the 80 on the public IP also the public IP usually is shared by many Compute resources so probably is the only good reason to keep it as a node but I would change its nome to "Acquired_IP"
8) do we care about the file system on the storage? Better do we care about the file system used in the Compute or we keep the default coming from the VM template?
9) I've red that we do not case about mounting a network share in the Compute ... but are we sure about this? no clustering and ... low real enterprise scaling without it; here we need a node that (as pointed out before) is NOT_TO_CREATE (do not want to use abstract but it could be an attribute to a ROOT node) that means do not create it just know that there has to be a resource and maybe we need some way to get the dynamicinfo about it; this obviously reduce portability of the template and link it to the need of an existing environment but it could be interesting at least to start thinking it asking info to an external topology (the orchestrator should manage to get the info or give the warning that you have to deploy before application_x so that you get the needed feature in place.
-------------
tosca_definitions_version: tosca_simple_yaml_1_0_0

description: >
  TOSCA simple profile that just defines a single compute instance. Note, this example does not include default values on inputs properties.
 
topology_template:
  inputs:
    cpus:
      type: integer
      description: Number of CPUs for the server.
      constraints:
        - valid_values: [ 1, 2, 4, 8 ]
    storage_size:
      type: scalar-unit.size
      description: Size of the storage to be created.
      default: 1 GB
    storage_snapshot_id:
      type: string
      description: >
        Optional identifier for an existing snapshot to use when creating storage.    
    storage_location:
      type: string
      description: Block storage mount point (filesystem path).
    network_name:
      type: string
      description: Network name
    root_pwd:
      type: string
      description: Root password for >Host.
    
  node_templates:
    my_server:
      type: Compute
      capabilities:
        host:
          properties:
            disk_size: 10 GB
            num_cpus: {  get_input: cpus  }
            mem_size: 4 MB
        os:
          properties:
            architecture: x86_64
            type: Linux
            distribution: ubuntu
            version: 12.04
      requirements:
        - attachment:
            node: my_storage
            relationship:
              type: AttachesTo
              properties:
                location: { get_input: storage_location }
      artifacts:
        - my_image: ubuntu.iso
            type: tosca.artifacts.Deployment.Image.VM.ISO
      interfaces:
        Standard:
          create:
            description: Standard lifecycle create operation.
            implementation: my_image
            inputs:
              root_password: { get_input: root_pwd }            
          configure:
            description: Standard lifecycle configure operation.
          start:
            description: Standard lifecycle start operation.
          stop:
            description: Standard lifecycle stop operation.
          delete:
            description: Standard lifecycle delete operation.
          
    my_storage:
      type: BlockStorage
      properties:
        size: { get_input: storage_size }
        snapshot_id: { get_input: storage_snapshot_id }
        
    my_network:
      type: tosca.nodes.network.Network
      properties:
        network_name: { get_input: network_name }
        ip_version: 4
        cidr: '192.168.0.0/24'
        start_ip: '192.168.0.50'
        end_ip: '192.168.0.200'
        gateway_ip: '192.168.0.1'

    my_port:
      type: tosca.nodes.network.Port
      requirements:
        - binding: my_server
        - link: my_network        
        
  outputs:
    private_ip:
      description: The private IP address of the deployed server instance.
      value: { get_attribute: [my_server, private_address] }
    volume_id:
      description: The volume id of the block storage instance.
      value: { get_attribute: [my_storage, volume_id] }


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