How XOS interact with OpenStack

How XOS interact with OpenStack

This post describe when user (or administrator) push TOSCA file to XOS, things will happen in XOS and how XOS create Network, Port, Instance on OpenStack.

XOS components

First, I will introduce XOS’s components, XOS composed by many containers, but only xos-core, xos-tosca and xos-db will involve in provision VM procedure:

  • XOS Core (xos-core): contain all model definations
  • XOS TOSCA API interface (xos-tosca): TOSCA northbound interface
  • XOS GUI (xos-gui)
  • XOS Web Socket (xos-ws)
  • XOS chameleon (chameleon)
  • XOS Database (xos-db): Save models information
  • XOS Redis (xos-redis)

For more information about XOS’s component, click here.

TOSCA YAML file

Every VMs, Networks created by XOS need to be defined in TOSCA, following comes an example about create service and service’s network.

Meanwhile, we still don’t create service instance (or called Tenant) yet, In M-CORD 5.0, VM will be created by vepc-service automatically, we will not explain vepc-service here, if you’re interested, you can find source code in GitHub – epc-service.

Here is a TOSCA snippet code continued previous code, it created a VM (Service Instance) named vmme1, this code will be extracted by XOS TOSCA Container, and xos-tosca send model information to xos-core via [GRPC](https://en.wikipedia.org/wiki/GRPC).

VM Provisioning

Let us start with this illustration, it tells the workflow from TOSCA YAML file to actually create VM instance. I will explain each steps later.

  1. administrator/user POST YAML file to xos-tosca by simple HTTP request.
  2. xos-tosca pass information to xos-core via xos-core.
  3. xos-core store data in xos-db.
  4. In xos-db, we have several models about OpenStack VM, services will share these models.
  5. openstack-synchronizer observe on Network, Port, Instance, Image models, and when these models have new data come in, openstack-synchronizer will get notified.
  6. openstack-synchronizer create Network, VM by calling Ansible script.

Synchronizer

In synchronizer, we have 2 types code: SyncStep and ModelPolicy.

We can say SyncStep will going to do something about service, e.g. Provisioning new VM on OpenStack, Install apache on target machine, create user, … etc.

And ModelPolicy is much different from SyncStep, it is responsible for maintaining models, for example, create a new VM in Instance model, modify Instance model information, delete VM from model … etc, will be done by ModelPolicy.

If the explaination still confused you, you may take a look at OpenStack Synchronizer – ModelPolicy for instance and OpenStack Synchronizer – SyncStep for instance.

you can find another file named sync_instances.yaml in same folder as sync_instances.py, this file defined VM create script in Ansible YAML format.

Conclusion

ModelPolicy have some default action.

As a result, ModelPolicy will create model’s content in handle_update, and SyncStep have no default action, it’s all defined in service by developer.

Leave a Reply

Your email address will not be published. Required fields are marked *