From 95fe4eb9d55169f7830526c66ca2e8df57bc4e5c Mon Sep 17 00:00:00 2001 From: Nico Schottelius Date: Tue, 14 Jan 2020 14:47:22 +0100 Subject: [PATCH] openstack step 4 --- .../contents.lr | 2 +- .../contents.lr | 69 +++++++++++++++++++ .../contents.lr | 38 ---------- content/u/blog/uncloud-next | 8 ++- 4 files changed, 77 insertions(+), 40 deletions(-) create mode 100644 content/u/blog/how-to-build-an-openstack-alternative-step-4-adding-a-database/contents.lr delete mode 100644 content/u/blog/how-to-build-an-openstack-alternative-step-4-metadata/contents.lr diff --git a/content/u/blog/how-to-build-an-openstack-alternative-step-3-automating-mac-addresses/contents.lr b/content/u/blog/how-to-build-an-openstack-alternative-step-3-automating-mac-addresses/contents.lr index ce2c6b8..98cc1a6 100644 --- a/content/u/blog/how-to-build-an-openstack-alternative-step-3-automating-mac-addresses/contents.lr +++ b/content/u/blog/how-to-build-an-openstack-alternative-step-3-automating-mac-addresses/contents.lr @@ -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. diff --git a/content/u/blog/how-to-build-an-openstack-alternative-step-4-adding-a-database/contents.lr b/content/u/blog/how-to-build-an-openstack-alternative-step-4-adding-a-database/contents.lr new file mode 100644 index 0000000..e7fb65c --- /dev/null +++ b/content/u/blog/how-to-build-an-openstack-alternative-step-4-adding-a-database/contents.lr @@ -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. diff --git a/content/u/blog/how-to-build-an-openstack-alternative-step-4-metadata/contents.lr b/content/u/blog/how-to-build-an-openstack-alternative-step-4-metadata/contents.lr deleted file mode 100644 index 52017c1..0000000 --- a/content/u/blog/how-to-build-an-openstack-alternative-step-4-metadata/contents.lr +++ /dev/null @@ -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.! diff --git a/content/u/blog/uncloud-next b/content/u/blog/uncloud-next index 4e07b4f..97f8e1c 100644 --- a/content/u/blog/uncloud-next +++ b/content/u/blog/uncloud-next @@ -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!