openstack step 4

This commit is contained in:
Nico Schottelius 2020-01-14 14:47:22 +01:00
parent 6189b30cb4
commit 95fe4eb9d5
4 changed files with 77 additions and 40 deletions

View file

@ -40,7 +40,7 @@ According to [Michael
Stapelberg](https://michael.stapelberg.ch/posts/2012-11-21-kvm_best_practices_2012/)
the **f6** prefix can be used due to the second lowest bit set to 1.
Checking with [wikipedia](https://en.wikipedia.org/wiki/MAC_address),
Checking with [Wikipedia](https://en.wikipedia.org/wiki/MAC_address),
this bit indeed specifies whether or not a mac address is locally or
universally administrated.

View file

@ -0,0 +1,69 @@
title: How to build an OpenStack alternative: Step 4, adding a database
---
pub_date: 2020-01-14
---
author: ungleich virtualisation team
---
twitter_handle: ungleich
---
_hidden: yes
---
_discoverable: yes
---
abstract:
Data begins to accumulate
---
body:
This time we describe how to
store information in a database.
The previous time we described
[how to generate MAC
addresses(../how-to-build-an-openstack-alternative-step-3-automating-mac-addresses/),
a key element of uncloud.
## More Data
We know have a couple of running VMs, we want to remember which VMs
are running and also add more information. Who owns a VM? And later
also where is the VM running.
## Database
We decided to use [etcd](https://etcd.io/) as our primary database.
The main reason for it is that we don't want to add a single point of
failure into uncloud and we don't need guarantees provided by
standard SQL.
An alternative we still consider to etcd is postgresql, which also
supports storing JSON and has quite a sophisticated messaging system.
## Refactoring: phasing in a database
So far we used a couple of python and shell scripts to create the base
of uncloud. Now that things become a bit more serious, we needed to
refactor our code. Shell and python scripts are cleaned up and
become python a proper python module, which we lovely call
`uncloud.hack`.
## Python, ETCD and JSON
We decided to use [python-etcd3](https://python-etcd3.readthedocs.io/)
to access etcd from the python world, as it supports the API version
3.
For the data format we decided to use JSON, as it is easy to read.
Each VM is identified by a random UUID, so we don't need to store a
counter for VMs.
## Status
At this point uncloud can create VMs and the VMs are registered
in etcd as the database. So while we don't have logic yet for
(automatic) VM migration, the information about VMs is already stored
in a distributed database.
So if one of our hosts vanishes, we can in theory already redeploy the
existing VMs.

View file

@ -1,38 +0,0 @@
title: How to build an OpenStack alternative: Step 4, the metadata service
---
pub_date: 2020-01-14
---
author: ungleich virtualisation team
---
twitter_handle: ungleich
---
_hidden: yes
---
_discoverable: yes
---
abstract:
Passing meta information into the VM
---
body:
This time we describe how to pass information to the virtual machines
in uncloud.
The previous time we described
[how to generate MAC
addresses(../how-to-build-an-openstack-alternative-step-3-automating-mac-addresses/),
a key element of uncloud.
## Metadata
## Status
While being a small and very specific tool, the mac address generator
is actually a key element of creating a virtualisation
framework. Without it, it is practically impossible to spawn a dynamic
amount of virtual machines.
With our prototype, a secured network and the mac address generator we
are not far from being able to migrate some test VMs to uncloud.!

View file

@ -1,4 +1,10 @@
- metadata!
- step 4 = database!
- metadata
- for getting keys
- user authentication
- otp or ldap or plain file
- for registering keys
- for creating VMs
- automating
- trigger / postgres / etcd
- building vm images!