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)

XOS Component Relationship

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.

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
# vMME Service
service#vmme:
type: tosca.nodes.VMMEService
properties:
name: vmme
public_key: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDNMTMI8QNtq9TwJI4CGWvK0zPO7+7y3JXAa7H5o1VszoxQubmQ69xkPCyqhxtJiWszxsNkpTM0XOJLcpmTQkcLiOecpnoUh2FRIkVZxeKqSfFwD3/s/c+ZHoGk+0LjOJ0x99E0s9SGIM++rDtznJPiNGstyKpfYT7uxPT8fy2CSqz7jGQI/jbwVZWmf/C3xZgJdvF8b/2sQhDELP/wrtiS26lDNzgJBkqVrZugsjUSekQ98L+oRbPzGZvd962Kz+0M9XID/uONXUkbT0yJiH0UA0mUA/q3PJtARH5WSBtfHpl146fyd0X7uT1knaZJEb/kYEd5/Ti9mwMsp0sJlsniZ9lmdDBTxDdA+9J35GnuCG427MqDOc++M/T7FD4HT/L/ivmjDHoOzQlZFUmXEKVCZyQayStGDt2uegOtnkBolCaJG5UaSS6AuyKm3AcO6++fHiZkp49jtL9uLZOOmPNoJxKDLhyTtLWjD4FxoexQi6Qy39/7h9jYMRLYdMh4fkG/521cDoctYKtwigGPOF+REipu+K8o2DzJX2snzN78zE1u/HA/pWKudIPg+V2MvSKPNb1tfbc1dpX8R+rwOA8jMX9s1EWpVHufwsBTHeYvHw/iBbGEh0mLTLM1OxWT+s282bGidINIdJH2qe3FUhaX9apNc85iPDpp64zP0glG5w== CORD SSH client key for headnode
private_key_fn: /opt/xos/services/vmme/keys/mcord_rsa
artifacts:
pubkey: /opt/cord_profile/key_import/mcord_rsa.pub

mysite_vmme:
description: vMME Service Slice
type: tosca.nodes.Slice
properties:
name: mysite_vmme
default_isolation: vm
network: noauto
requirements:
- site:
node: mysite
relationship: tosca.relationships.BelongsToOne
- service:
node: service#vmme
relationship: tosca.relationships.BelongsToOne
- default_image:
node: image-oai
relationship: tosca.relationships.BelongsToOne
- default_flavor:
node: m1.medium
relationship: tosca.relationships.BelongsToOne

oai_mme:
type: tosca.nodes.VMMEVendor
properties:
name: oai_mme
requirements:
- image:
node: image-oai
relationship: tosca.relationships.BelongsToOne
- flavor:
node: m1.medium
relationship: tosca.relationships.BelongsToOne
vmme_network:
type: tosca.nodes.Network
properties:
name: vmme_network
subnet: 10.0.6.0/24
permit_all_slices: True
requirements:
- template:
node: flat_template
relationship: tosca.relationships.BelongsToOne
- owner:
node: mysite_vmme
relationship: tosca.relationships.BelongsToOne

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).

1
2
3
4
5
6
7
8
9
10
11
12
# OAI Service instances
serviceinstance#vMME_instance:
type: tosca.nodes.VMMETenant
properties:
name: vmme1
requirements:
- vmme_vendor:
node: oai_vmme
relationship: tosca.relationships.BelongsToOne
- owner:
node: service#vmme
relationship: tosca.relationships.BelongsToOne

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.

XOS interact with OpenStack

  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.