Hi Luca,
My comments/opinions in-line:
From:
tosca@lists.oasis-open.org [ mailto:
tosca@lists.oasis-open.org ] On Behalf Of Luca Gioppo
Sent: Thursday, June 11, 2015 3:52 AM
To: TOSCA
Subject: [tosca] 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:
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)
As Matt indicated, the Endpoint.Admin credentials could be used for that. But more importantly, in cloud environments especially you may not always want to create a root password (and use SSH credentials instead for remote administration).
Based on that, I believe it would be a mistake to add a root password property.
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
Matt’s latest draft (I believe it is wd06 r2) includes an example of starting a compute node with a VM. That said, I don’t fully agree with Matt’s example. It models the VM as a component that is hosted on a Compute node (under the
assumption that the Compute node models the server). In my opinion, the Compute node models the Operating Environment rather than the server. If that’s the case, a VM isn’t hosted on a Compute node, but rather the VM would be the deployment artifact of the
Compute node and there is no need to model a VM separately. And, assuming the Compute node models the operating environment rather than a server, we could then deploy Compute on bare metal or on a hypervisor and application topology models would support both
scenarios.
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
If users need to be created, then I believe we should model a user as just another Node Type, and its lifecycle needs to get managed just like any other component. We could model users as properties of an OS, but I believe that would
be too limiting. It would also make it more difficult in scenarios where centralized directory services are used.
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
In Tosca, the relationship is from Port to Compute, not from Compute to Port: Compute has the “capability” to be bound to by one or more network ports. And yes, you could think of a Port as a NIC (physical or virtual) with one or
more addresses.
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)
Networks can absolutely be created, just like any other virtual resources. However, I think you’re pointing to a more general issue. Even in cloud environments, there might be a need to “connect” to legacy infrastructure that cannot
be orchestrated dynamically, but that might still need to get configured. Tosca should support these scenarios (either by extending the standard lifecycle operations with “connect and configure” semantics or by introducing a new Interface for just this purpose).
where do we configure the firewall and the opened ports in the Compute resource?
The question is not where to “configure” but where to “model”. In my opinion, security should get modeled at the application level. For example, SoftwareComponent nodes have an Endpoint that might include Access Control Lists for
the application. It is then up to the orchestrator to translate these application-level into whatever security mechanisms are supported by the underlying infrastructure (e.g. IP tables on linux hosts, or security groups, or configuration of physical firewalls
etc.)
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"
Yes, there are a large number of objects to model networking, but I believe all of them have a place. What’s needed is more examples of how these concepts are used and how application-level components (such as Endpoints) obtain network-specific
information from network infrastructure. Tosca has a “networking” ad-hoc group to discuss just these issues, but that ad-hoc group hasn’t had any meetings for a couple of months now. Are you interested in participating in this?
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?
Do you have specific use cases where you might need to create and initialize file systems?
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.
Not sure where you read this, but Storage is a whole sub-area that needs a lot more work and is definitely within scope.
Chris
-------------
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] }