1. General:

- One interesting use case from Austin meetup is SAP use case. They are trying to move their legacy app (HANA) on the top of OpenStack, using CloudFoundry as a PaaS solution.

- Kubernetes has the biggest percentage in usage of docker container management tool.

- The OpenStack acceptance is mostly in commercial and financial aspects. In fact, the usage of OpenStack has not too many use cases, especially in Europe. Except some use cases of moving legacy infrastructure onto OpenStack of Walmart, Netflix, etc. others still trust on public cloud solutions such as AWS, GoogleCloud.

- The biggest OpenStack based public cloud vendor is Rackspace.

- Motto: Collaborate or die.

2. Cloud Migraion aaS (Coriolis)

Overview:

- The main goal is migrating VM (vm-centric), other infrastructure features such as volume, network, etc. will be implemeted in the future. In case thee migration fails, the vm is not deleted on the source.

- The problem is vendor lock-in so that we need to migrate the work load to another cloud environment. Somehow this is the battle of openstack and vendor lock-in.

- It migrates all the cloud workloads between cloud environments.

Features:

- Architecture of Coriolis is microservice: fault-tolerant, scalable.

- It is managed via keystone, it should be a bigtent of OpenStack.

- Barbican is used for storing and accesing secrets.

- In the real use cases, it has multiple workers that connect to the barbican. Each worker runs on each cloud environment.

- It has 2 process, importing the vms from the source cloud and exporting it onto the destination cloud environment.

- The first importing process, it is nothing else just preparing process for disk migration.

- The second process of exporting includes multiple processes, one of them of removing the source OS-lockin dependencies.

- It needs to store the vm disk on the worker so that it needs the enough cappacity for each worker to store the vm disk. Hence in this case, the numbers of worker increases is a good solution.

3. File shrare, manila

Overview:

- Netapp is the founder of manila. Nowaday, it is an active OpenStack project.

- Manila supports multiple protocols of file system (NFS, etc.)

Why Manila: 65 % store is sold for the purpose of shared file system. There are so many apps that need file system storage.

- It is simple to see that if we use cinder for storage, up to now each volume is only used for 1 vm (there is a spec for multiple use of volume in vanila OpenStack). If using share, it can be used among multiple Vms.

- It has support of other actions like taking snapshots, backups, etc.

- Manila has so many features such as replicas, sanpshot, backups, consistency group, etc. One of the most advanced features of manila is replication. It is useful to replicate manila shares from some zones to others. It is useful for DR.

- Storage backends support for manila: NFS storage, Netapp, Hitachi, Ceph.

Usecases:

- In Bigdata: Integrates with sahara. This is an usecase that has so many interests in the collaboration of OpenStack and Hadoop.

- DbaaS : Integrates with trove.

- Entrprise app: SAP Hana integrates with Manila. Cinder is used for volume booted vms. The shares are mounted on the compute nodes called Hana nodes. The vms access to the Hana features (Hana data, hana logs, etc.) – They are actually are shares of manila that provide the fuctionalitiies of Hana app.

- Dutch Telecom for file shared system for the NFV telco cloud.

- Cross-tenant sharing, hybrid cloud.

4. Kuryr

Overview:

- It brings the neutron network to the Docker container.

- The containere challenges:

- Reeinventing the networking abstracton.

- There is no the solution for tenant isolation for container networking.

- No solution for networking infrastructure, it means no solution for all Vms, containers, baremetal running on the same infrastructure.

Main Features:

- It integrets with different container orchestraion engines such as mesos, swarm, kubernetes.

- It provides the contrainer networking by talking with neutron. It is actually an abstraction layer laying between and maps container networking to neutron.

- It supports libnetwork that is a library supporting for creating, managing networking stacks for container.

- It use VIF to bind the docker libnetwork remote network (actually container namespace) to the neutron port.

- It supports baremetal deployments and nested container deployment.

K8s use case:

- In kubernetes, there are master and worker nodes. Master nodes will talk with neutron through k8s API. And kuryr container cluster is running on the worker nodes under the cluster management of k8s.

- What if we have a vms running on compute nodes and nested container deployment. Solution is MidoNet, DragonFlow, OVS. Those solutions are nothing else but abstraction solutions that supports for OpenStack networking infrastructure and container networking solution.

- Enhances with heat template and magnum.

Budapest 6-6-2016,

VietStack Team