The OpenStack Service is responsible for instantiating OpenStack Networks and Compute resources. Compute resources are referred to as "Servers" in the OpenStack API. This documentation may refer to "Servers" and "VMs" interchangeably.
Note: The OpenStack service has not been tested with CORD 6.1.
The following models are supported by the OpenStack Service:
OpenStackService. Include parameters that are necessary for contacting a deployment of OpenStack.
auth_url. URL of the keystone endpoint.
admin_user. Username of the administrator.
admin_password. Password of the administrator.
admin_tenant. Project within which the administrator account resides.
TrustDomain. Trust domains logically group services and their resources together into a namespace where the resources can be found. A TrustDomain corresponds to a OpenStack
name. Name of the trust domain
owner. The service that is partitioned by this trust domain. For OpenStack trust domains, this will be an instance of the
Principal. Principals are entities that are able to perform operations on resources. A Principal corresponds to a OpenStack
name. Name of this principal.
trust_domain. TrustDomain in which this principal resides.
Flavor. Represents the class of resources that will be used to instantiate a server. Corresponds directly to an OpenStack flavor.
name. Name of the flavor.
Image. Images are virtual machine images that are used when instantiating servers.
name. Name of the image.
container_format. Format of the container. Usually set to
disk_format. Format of the disk image. Usually set to
path. URL where the image may be downloaded from.
Slice. A Slice is a collection of compute resources and can also be thought of as a controller for those compute resources, implementing logic that creates and destroys the compute resources as necessary. For OpenStack-based slices, this logic is usually located in XOS model_policies.
name. Name of this Slice.
site. Site that this Slice belongs to, used for administrative accountability.
trust_domain. TrustDomain in which this slice resides.
NetworkTemplate. Holds parameters that may be used for various classes of networks.
name. Name of network template.
description. Description of network template.
visibility. Whether or not the network is reachable externally. Set to
translation. Whether or not NATing is performed. Usually set to
vtn_kind. Passed to VTN to indicate the type of network. Choices are
VSG. Please see the VTN documentation for further details.
Network. Represents a network that may be used to connect servers to each other and/or externally.
name. Name of network.
owner. Relation to the
Sliceobject that owns this network.
template. Relation to a
subnet. Subnet, specified in CIDR notation. For example,
permit_all_slices. Set to True to permit all slices to connect to this network.
NetworkSlice. This model is used to connect a Slice to a Network.
network. Relation to the Network to be connected.
slice. Relation to the Slice to be connected.
Node. Used to represent an OpenStack compute node.
name. Hostname of node.
OpenStackServiceInstance. This model directly represents an OpenStack Server, implemented as a virtual machine.
name. Name of the server.
owner. Service that owns this
ServiceInstance, in this case, an instance of the
slice. Relation to the
Slicethat manages this server.
image. Relation to the
Imagethat is used by this server.
flavor. Relation to the
Flavorthat should be used when instantiating this server.
node. Relation to the
Nodethat this server should be instantiated on.
Network connectivity is typically achieved by attaching
Slices. Whenever an
OpenStackServiceInstance is instantiated, the Server created in OpenStack will inherit all Networks connected (via
NetworkSlice relations) to the
Slice that owns the
A typical workflow for establishing network connectivity is:
- Create a
- Create a
Networkthat should be attached to the
- Create one or more
OpenStackServiceInstanceowned by the
Example Python Workflow - Creating OpenStack Objects in XOS
An XOS Service can leverage the OpenStack Service to creates OpenStack resources on behalf of the XOS Service. To create an OpenStack Server, it's suggested you create the following XOS Objects:
It's often the case with most profiles, such as the
base-openstack profile, that several object will automatically be created for you:
Site. Usually that's one site named "mysite".
Flavor. Often there are a variety of flavors, "m1.small", "m1.medium", "m1.large", etc.
Node. Most profiles will create at least one usable compute node.
Below is a short example that will create an OpenStack server. This example uses the XOS python API and may be entered directly into
# Create a new Trust Domain t=TrustDomain(owner=OpenStackService.objects.first(), name="demo-trust") t.save() # Create a new Principal p=Principal(trust_domain=t, name="demo-user") p.save() # Create a new Slice, attached to the first Site. s=Slice(trust_domain=t, name="demo-slice", site=Site.objects.first()) s.save() # Attach the Slice to the Management Network. ns=NetworkSlice(slice=s, network=Network.objects.get(name="management")) ns.save() # Create an Image img=Image(name="cirros-0.3.5", container_format="BARE", disk_format="QCOW2", path="http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img") img.save() # Use the first Node defined in XOS. Assumes node already exists. node = Node.objects.first() # Use the m1.medium flavor flavor = Flavor.objects.get(name="m1.medium") # Create the Server i=OpenStackServiceInstance(slice=s, image=img, name="demo-instance", owner=OpenStackService.objects.first(), flavor=flavor, node=node) i.save()
Integration with other Services
The OpenStack service is an infrastructure service, providing support for several models (
Network, ...) that are declared in the XOS core.
ExampleService exists as an example of how to integrate with the OpenStack Service.
Transition from old to new OpenStack modeling
The OpenStack service is currently undergoing a transition from older modeling to newer modeling. The new models are currently in alpha status, and may have limited features and functionality. As work continues, it will soon be encouraged for new services to use the new models, which are described in this document.
The new models are primarily comprised of
Some older models such as
Instance may be removed at a future date.
Several models such as
Flavor are useful with both the older OpenStack modeling and the newer OpenStack modeling.
Model policies are implemented that create a variety of controller-based models when their primary model is created. For example, creating an
Image will automatically create a corresponding
ControllerImage object. It is then the
ControllerImage that is synchronized instead of the
Image. This particular implementation decision dates back to a requirement that resources be able to span multiple OpenStack deployments.
The following models are synchronized by using Ansible playbooks:
The following models are synchronized by using the OpenStack API directly:
Port. The Port syncstep implements both push and pull behavior, learning IP addresses from Neutron.