Open Stack

From: "Mooney, Sean K" <sean.k.mooney at intel.com<mailto:sean.k.mooney at intel.com>>
Date: Friday, May 13, 2016 at 2:14 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, Steven Dake <stdake at cisco.com<mailto:stdake at cisco.com>>, "devananda.vdv at gmail.com<mailto:devananda.vdv at gmail.com>" <devananda.vdv at gmail.com<mailto:devananda.vdv at gmail.com>>
Cc: "Mooney, Sean K" <sean.k.mooney at intel.com<mailto:sean.k.mooney at intel.com>>
Subject: [openstack-dev] [kolla] [bifrost] bifrost container poc update

Hi this is an  update on where I am with my poc of creating a bifost container for kolla.
As of  Wednesday evening I have reached my v0 poc goal

That goal was to demonstrate it was easy bifrost in a container with little to know changes.
This is further broken down as follows.

-        Create poc patch to split bifrost ironic install role into install, bootstrap and start phases

-        Use kolla build.py to build a container with all bifrost/ironic dependences installed by running
bifrost install phase as part of the docker build

-        Spawn an instance of the resulting container then bootstrap and start ironic by running bifrost install playbook  with only the bootstrap and run phases enabled

-        Enroll a physical node using the enroll-dynamic playbook

-        Deploy the default OS image to the physical node using the deploy-dynamic playbook

The attached file assume basic knowledge of how to build images with kola and documents how the command I
Ran to preform this poc.

Limitations of v0:


-        Only tested with centos source build

-        Fat container. Uses systemd as an init system in the container. (yes this works fine)

-        Requires privileged (required for networking and  mounting loopback devices)

-        Requires net=host (as an infrastructure container on the undercloud this shold be ok)

-        Requires /sys/fs/cgroups to be bind mounted for systemd

-        Requires /dev to be bind mounted  to allow building of Baremetal image

-        No integration with kola deploy playbooks or script to automate deployment (fix in v1)

-        No support for external config (fix in v1)

-        I wrote it in 12-18 hours so no comments or docs except the attachment

-        Ironic service done restart automatically on restarting container.( rerun install playbook with skip_boostrap=true and skip_install=true to fix)

Next steps:

Define scope of v1

-        Should I open a blueprint/spec/bug in kolla and or bifrost?

-        Kolla spec to cover container and ansible integration (https://github.com/SeanMooney/kolla/commit/bbbfc573dcd8e20ad912dedeecc0b3994832925f)

o   Support builds of bifrost container both source and binary with all 4 base OS

o   Support baremetal image customization via external config. (os,packages) and bring your own model to supply your own image.

o   Integrate with kolla deploy playbooks.

o   Add bifrost.rst to kolla docs

o   Thin containers or supervisord as a v2

-        Bifrost spec to cover ironic install  decomposition  (https://github.com/SeanMooney/bifrost/commit/e223f4fe73871b76ce87999470a1efc43862671e)

o   Split install ironic playbook into 3 phases (install,bootstarp,start)

§  possible solutions. Skip_* as in poc, separate roles or tags

o   Replace use of sed for fixing hostname as it fails in a container
(https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifrost-ironic-install/tasks/main.yml#L117-L123)

o   Introduce install_dib  to control if disk image build is installed of checking if the image should be built.

-        Testing: kolla ci job? Test in bifrost ci?

So this is the point I pause for feedback:
Does this sound like a reasonable next step?
Am I going in the wrong direction with this?
If I create spec or when I submit the code for review would anyone in particular like me to add them as reviewers?

Regards
Seán

Sean,

Nice job!

Kolla doesn't typically require specs for most work, and I believe this type of work would fall into the non-spec category.  A blueprint would do.

Thanks
-steve


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160514/99eb5f35/attachment.html>