Question

Hi everyone.

Following up on my AR from the kolla host repository session
https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo
I started working on creating a kolla bifrost container.

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.
In particular the install playbook both installs the ironic dependencies and configure and runs the services.

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the
Infrastructure services (mysql,rabbit ...) without a running init system which is not present during the docker build.

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran
Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

This leave me with 3 paths forward.

1. I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2. I can use the kolla build system to build only part of the image

a. the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b. After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c. I can then connect to this running container and run the bifrost install script unmodified.

d. Once it is finished I can stop the container and export it to an image "bifros-postinstall".

e. This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

1. I can skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.
Docker really was not designed to run systemd as part of docker build.

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have
Is should I use the kolla build system to make the base image or not.

If anyone else has suggestion on how I can progress please let me know but currently I am leaning towards option 2.

The only other option I see would be to not use a container and either install biforst on the host or in a vm.
These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered
Quite well as part of the bifrost project.

Regards
Sean.

---

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hi everyone.

 

Following up on my AR from the kolla host repository session

https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo

I started working on creating a kolla bifrost container.

 

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.

In particular the install playbook both installs the ironic dependencies and configure and runs the services.

 

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the

Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

 

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran

Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

 

 

This leave me with 3 paths forward.

 

1.       I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2.       I can use the kolla build system to build only part of the image

a.        the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b.      After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c.       I can then connect to this running container and run the bifrost install script unmodified.

d.      Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e.      This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

3.       I can  skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

 

 

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.

Docker really was not designed to run systemd as part of docker build.

 

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have

Is should I use the kolla build system to make the base image or not.

 

If anyone else has suggestion on how I can progress  please let me know but currently I am leaning towards option 2.

 

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered

Quite well as part of the bifrost project.

 

Regards

Sean.

 

Answer 1

Sean,

Thanks for taking this on :) I didn't know you had such an AR :)

From: "Mooney, Sean K" sean.k.mooney@intel.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

Following up on my AR from the kolla host repository session
https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo
I started working on creating a kolla bifrost container.

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.
In particular the install playbook both installs the ironic dependencies and configure and runs the services.

What I'd do here is ignore the install playbook and duplicate what it installs. We don't want to install at run time, we want to install at build time. You weren't clear if that is what your doing.

The reason we would ignore the install playbook is because it runs the services. We need to run the services in a different way. This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok. I'd recommend not using systemd, as that will break systemd systems badly. Instead use a different init system, such as supervisord.

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the
Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran
Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

This leave me with 3 paths forward.

1. I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2. I can use the kolla build system to build only part of the image

a. the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b. After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c. I can then connect to this running container and run the bifrost install script unmodified.

d. Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e. This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

1. I can skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

4.
Make a supervisord set of init scripts and make the docker file do what it was intended – install the files. This is kind of a mashup of your 1-3 ideas. Good thinking :)

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.
Docker really was not designed to run systemd as part of docker build.

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have
Is should I use the kolla build system to make the base image or not.

If anyone else has suggestion on how I can progress please let me know but currently I am leaning towards option 2.

If you have questions about my suggestion to use supervisord, hit me up on IRC. Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would. Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.

Regards
-steve

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies. I'd like to keep that part of Kolla intact :)

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered
Quite well as part of the bifrost project.

Regards
Sean.

---

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Sean,

Thanks for taking this on :)  I didn't know you had such an AR :)

From: "Mooney, Sean K" <sean.k.mooney@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

 

Following up on my AR from the kolla host repository session

https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo

I started working on creating a kolla bifrost container.

 

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.

In particular the install playbook both installs the ironic dependencies and configure and runs the services.

 

What I'd do here is ignore the install playbook and duplicate what it installs.  We don't want to install at run time, we want to install at build time.  You weren't clear if that is what your doing.

The reason we would ignore the install playbook is because it runs the services.  We need to run the services in a different way.  This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok.  I'd recommend not using systemd, as that will break systemd systems badly.  Instead use a different init system, such as supervisord.

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the

Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

 

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran

Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

 

 

This leave me with 3 paths forward.

 

1.       I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2.       I can use the kolla build system to build only part of the image

a.        the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b.      After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c.       I can then connect to this running container and run the bifrost install script unmodified.

d.      Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e.      This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

3.       I can  skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

4.

Make a supervisord set of init scripts and make the docker file do what it was intended – install the files.  This is kind of a mashup of your 1-3 ideas.  Good thinking :)

 

 

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.

Docker really was not designed to run systemd as part of docker build.

 

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have

Is should I use the kolla build system to make the base image or not.

 

If anyone else has suggestion on how I can progress  please let me know but currently I am leaning towards option 2.

 

If you have questions about my suggestion to use supervisord, hit me up on IRC.  Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would.  Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.

Regards

-steve

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies.  I'd like to keep that part of Kolla intact :)

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered

Quite well as part of the bifrost project.

 

Regards

Sean.

 

Answer 2

Another option, should the install playbook be enhanced to support simply skipping the steps that wouldn't apply to building in the container?

Seems to me, all the ironic stuff could just be done with the kolla ironic container, so no systemd stuff should be needed.

Thanks,
Kevin

---

From: Mooney, Sean K [sean.k.mooney@intel.com]
Sent: Friday, May 06, 2016 10:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

Following up on my AR from the kolla host repository session
https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo
I started working on creating a kolla bifrost container.

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.
In particular the install playbook both installs the ironic dependencies and configure and runs the services.

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the
Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran
Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

This leave me with 3 paths forward.

1. I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2. I can use the kolla build system to build only part of the image

a. the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b. After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c. I can then connect to this running container and run the bifrost install script unmodified.

d. Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e. This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

1. I can skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.
Docker really was not designed to run systemd as part of docker build.

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have
Is should I use the kolla build system to make the base image or not.

If anyone else has suggestion on how I can progress please let me know but currently I am leaning towards option 2.

The only other option I see would be to not use a container and either install biforst on the host or in a vm.
These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered
Quite well as part of the bifrost project.

Regards
Sean.

---

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Another option, should the install playbook be enhanced to support simply skipping the steps that wouldn't apply to building in the container?

Seems to me, all the ironic stuff could just be done with the kolla ironic container, so no systemd stuff should be needed.

Thanks,
Kevin

---

From: Mooney, Sean K [sean.k.mooney@intel.com]
Sent: Friday, May 06, 2016 10:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

 

Following up on my AR from the kolla host repository session

https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo

I started working on creating a kolla bifrost container.

 

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.

In particular the install playbook both installs the ironic dependencies and configure and runs the services.

 

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the

Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

 

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran

Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

 

 

This leave me with 3 paths forward.

 

1.       I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2.       I can use the kolla build system to build only part of the image

a.        the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b.      After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c.       I can then connect to this running container and run the bifrost install script unmodified.

d.      Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e.      This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

3.       I can  skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

 

 

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.

Docker really was not designed to run systemd as part of docker build.

 

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have

Is should I use the kolla build system to make the base image or not.

 

If anyone else has suggestion on how I can progress  please let me know but currently I am leaning towards option 2.

 

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered

Quite well as part of the bifrost project.

 

Regards

Sean.

 

Answer 3

From: Steven Dake (stdake) [mailto:stdake@cisco.com]
Sent: Friday, May 6, 2016 6:56 PM
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

Sean,

Thanks for taking this on :) I didn't know you had such an AR :)
[Mooney, Sean K] well if other want to do the work that ok with me too but I was planning on deploying bifrost
At home again anyway so I taught I might as well try to automate the process while im at it.

From: "Mooney, Sean K" sean.k.mooney@intel.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

Following up on my AR from the kolla host repository session
https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo
I started working on creating a kolla bifrost container.

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.
In particular the install playbook both installs the ironic dependencies and configure and runs the services.

What I'd do here is ignore the install playbook and duplicate what it installs. We don't want to install at run time, we want to install at build time. You weren't clear if that is what your doing.
[Mooney, Sean K] that is certainly an option but bifrost is an installer for ironic and its supporting service. Not using its installation scripts significantly reduces the value of
Integrating with bifrost vs fixing the existing ironic support in kolla and using that to provision the undercloud.

The reason we would ignore the install playbook is because it runs the services. We need to run the services in a different way. This will (as we discussed at ODS) be a fat container on the underlord cloud - which I guess is ok. I'd recommend not using systemd, as that will break systemd systems badly. Instead use a different init system, such as supervisord.
[Mooney, Sean K] if we don't use the bifrost install playbook then yes supervisord would be a good choice for the init system.
Looking at the official centos docker image https://hub.docker.com/_/centos/ they do provided instruction for running systemd containers tough I have had issues with this in the past.

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the
Infrastructure services (mysql,rabbit ...) without a running init system which is not present during the docker build.

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran
Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

This leave me with 3 paths forward.

1. I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2. I can use the kolla build system to build only part of the image

a. the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b. After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c. I can then connect to this running container and run the bifrost install script unmodified.

d. Once it is finished I can stop the container and export it to an image "bifros-postinstall".

e. This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

1. I can skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

4.
Make a supervisord set of init scripts and make the docker file do what it was intended - install the files. This is kind of a mashup of your 1-3 ideas. Good thinking :)

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.
Docker really was not designed to run systemd as part of docker build.

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have
Is should I use the kolla build system to make the base image or not.

If anyone else has suggestion on how I can progress please let me know but currently I am leaning towards option 2.

If you have questions about my suggestion to use supervisord, hit me up on IRC. Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would. Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.
[Mooney, Sean K] I have briefly used supervisord before for a pet project https://github.com/SeanMooney/docker-devstack to create a container for running devstack so it did hot pollute my host.
supervisord is a nice tool. Im just about to head home for the weekend but I might grab you on irc on Monday to follow up.

Regards
-steve

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

GROAN - one advantage containers provide us is not mucking up the host OS with a bajillion dependencies. I'd like to keep that part of Kolla intact :)
[Mooney, Sean K] yes I would prefer not to break that too. This was basically the option of we don't actually do the integration and instead just tell
The user how to use bifrost to do the deployment but leave it up to them do decide how to install it. so for me that was plan Z so we have a couple of letter
Go through first.

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered
Quite well as part of the bifrost project.

Regards
Sean.

---

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 

 

From: Steven Dake (stdake) [mailto:stdake@cisco.com]
Sent: Friday, May 6, 2016 6:56 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

Sean,

 

Thanks for taking this on :)  I didn't know you had such an AR :)

[Mooney, Sean K] well if other want to do the work that ok with me too but I was planning on deploying bifrost

At home again anyway so I taught I  might as well try to automate the process while im at it.

 

From: "Mooney, Sean K" <sean.k.mooney@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

 

Hi everyone.

 

Following up on my AR from the kolla host repository session

https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo

I started working on creating a kolla bifrost container.

 

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.

In particular the install playbook both installs the ironic dependencies and configure and runs the services.

 

 

What I'd do here is ignore the install playbook and duplicate what it installs.  We don't want to install at run time, we want to install at build time.  You weren't clear if that is what your doing.

[Mooney, Sean K] that is certainly an option but bifrost is an installer for ironic and its supporting service. Not using its installation scripts significantly reduces the value of

Integrating with bifrost vs fixing the existing ironic support in kolla and using that to provision the undercloud.

 

The reason we would ignore the install playbook is because it runs the services.  We need to run the services in a different way.  This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok.  I'd recommend not using systemd, as that will break systemd systems badly.  Instead use a different init system, such as supervisord.

[Mooney, Sean K] if we don’t use the  bifrost install playbook then yes supervisord would be a good choice for the init system.

Looking at the official centos docker image https://hub.docker.com/_/centos/  they do provided instruction for running systemd containers tough I have had issues with this in the past.

 

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the

Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

 

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran

Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

 

 

This leave me with 3 paths forward.

 

1.       I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2.       I can use the kolla build system to build only part of the image

a.        the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b.      After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c.       I can then connect to this running container and run the bifrost install script unmodified.

d.      Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e.      This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

3.       I can  skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

 

4.

Make a supervisord set of init scripts and make the docker file do what it was intended – install the files.  This is kind of a mashup of your 1-3 ideas.  Good thinking :)

 

 

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.

Docker really was not designed to run systemd as part of docker build.

 

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have

Is should I use the kolla build system to make the base image or not.

 

If anyone else has suggestion on how I can progress  please let me know but currently I am leaning towards option 2.

 

 

If you have questions about my suggestion to use supervisord, hit me up on IRC.  Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would.  Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.

[Mooney, Sean K]  I have briefly used supervisord before for a pet project https://github.com/SeanMooney/docker-devstack to create a container for running devstack so it did hot pollute my host.

supervisord  is a nice tool. Im just about to head home for the weekend but I might grab you on irc on Monday to follow up.

 

 

Regards

-steve

 

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

 

GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies.  I'd like to keep that part of Kolla intact :)

[Mooney, Sean K]  yes I would prefer not to break that too. This was basically the option of we don’t actually do the integration and instead just tell

The user how to use bifrost to do the deployment but leave it up to them do decide how to install it. so for me that was plan Z so we have a couple of letter

Go through first.

 

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered

Quite well as part of the bifrost project.

 

Regards

Sean.

 

Answer 4

I was under the impression bifrost was 2 things, one, an installer/configurator of ironic in a stand alone mode, and two, a management tool for getting machines deployed without needing nova using ironic.

The first use case seems like it should just be handled by enhancing kolla's ironic container stuff to directly to handle the use case, doing things the kolla way. This seems much cleaner to me. Doing it at runtime looses most of the benefits of doing it in a container at all.

The second adds a lot of value I think, and thats what the bifrost container should be?

Thanks,
Kevin

---

From: Mooney, Sean K [sean.k.mooney@intel.com]
Sent: Friday, May 06, 2016 12:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

From: Steven Dake (stdake) [mailto:stdake@cisco.com]
Sent: Friday, May 6, 2016 6:56 PM
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

Sean,

Thanks for taking this on :) I didn't know you had such an AR :)
[Mooney, Sean K] well if other want to do the work that ok with me too but I was planning on deploying bifrost
At home again anyway so I taught I might as well try to automate the process while im at it.

From: "Mooney, Sean K" sean.k.mooney@intel.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

Following up on my AR from the kolla host repository session
https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo
I started working on creating a kolla bifrost container.

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.
In particular the install playbook both installs the ironic dependencies and configure and runs the services.

What I'd do here is ignore the install playbook and duplicate what it installs. We don't want to install at run time, we want to install at build time. You weren't clear if that is what your doing.
[Mooney, Sean K] that is certainly an option but bifrost is an installer for ironic and its supporting service. Not using its installation scripts significantly reduces the value of
Integrating with bifrost vs fixing the existing ironic support in kolla and using that to provision the undercloud.

The reason we would ignore the install playbook is because it runs the services. We need to run the services in a different way. This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok. I'd recommend not using systemd, as that will break systemd systems badly. Instead use a different init system, such as supervisord.
[Mooney, Sean K] if we don’t use the bifrost install playbook then yes supervisord would be a good choice for the init system.
Looking at the official centos docker image https://hub.docker.com/_/centos/ they do provided instruction for running systemd containers tough I have had issues with this in the past.

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the
Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran
Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

This leave me with 3 paths forward.

1. I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2. I can use the kolla build system to build only part of the image

a. the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b. After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c. I can then connect to this running container and run the bifrost install script unmodified.

d. Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e. This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

1. I can skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

4.
Make a supervisord set of init scripts and make the docker file do what it was intended – install the files. This is kind of a mashup of your 1-3 ideas. Good thinking :)

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.
Docker really was not designed to run systemd as part of docker build.

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have
Is should I use the kolla build system to make the base image or not.

If anyone else has suggestion on how I can progress please let me know but currently I am leaning towards option 2.

If you have questions about my suggestion to use supervisord, hit me up on IRC. Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would. Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.
[Mooney, Sean K] I have briefly used supervisord before for a pet project https://github.com/SeanMooney/docker-devstack to create a container for running devstack so it did hot pollute my host.
supervisord is a nice tool. Im just about to head home for the weekend but I might grab you on irc on Monday to follow up.

Regards
-steve

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies. I'd like to keep that part of Kolla intact :)
[Mooney, Sean K] yes I would prefer not to break that too. This was basically the option of we don’t actually do the integration and instead just tell
The user how to use bifrost to do the deployment but leave it up to them do decide how to install it. so for me that was plan Z so we have a couple of letter
Go through first.

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered
Quite well as part of the bifrost project.

Regards
Sean.

---

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I was under the impression bifrost was 2 things, one, an installer/configurator of ironic in a stand alone mode, and two, a management tool for getting machines deployed without needing nova using ironic.

The first use case seems like it should just be handled by enhancing kolla's ironic container stuff to directly to handle the use case, doing things the kolla way. This seems much cleaner to me. Doing it at runtime looses most of the benefits of doing it in a container at all.

The second adds a lot of value I think, and thats what the bifrost container should be?

Thanks,
Kevin

---

From: Mooney, Sean K [sean.k.mooney@intel.com]
Sent: Friday, May 06, 2016 12:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

 

From: Steven Dake (stdake) [mailto:stdake@cisco.com]
Sent: Friday, May 6, 2016 6:56 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

Sean,

 

Thanks for taking this on :)  I didn't know you had such an AR :)

[Mooney, Sean K] well if other want to do the work that ok with me too but I was planning on deploying bifrost

At home again anyway so I taught I  might as well try to automate the process while im at it.

 

From: "Mooney, Sean K" <sean.k.mooney@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

 

Hi everyone.

 

Following up on my AR from the kolla host repository session

https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo

I started working on creating a kolla bifrost container.

 

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.

In particular the install playbook both installs the ironic dependencies and configure and runs the services.

 

 

What I'd do here is ignore the install playbook and duplicate what it installs.  We don't want to install at run time, we want to install at build time.  You weren't clear if that is what your doing.

[Mooney, Sean K] that is certainly an option but bifrost is an installer for ironic and its supporting service. Not using its installation scripts significantly reduces the value of

Integrating with bifrost vs fixing the existing ironic support in kolla and using that to provision the undercloud.

 

The reason we would ignore the install playbook is because it runs the services.  We need to run the services in a different way.  This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok.  I'd recommend not using systemd, as that will break systemd systems badly.  Instead use a different init system, such as supervisord.

[Mooney, Sean K] if we don’t use the  bifrost install playbook then yes supervisord would be a good choice for the init system.

Looking at the official centos docker image https://hub.docker.com/_/centos/  they do provided instruction for running systemd containers tough I have had issues with this in the past.

 

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the

Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

 

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran

Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

 

 

This leave me with 3 paths forward.

 

1.       I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2.       I can use the kolla build system to build only part of the image

a.        the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b.      After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c.       I can then connect to this running container and run the bifrost install script unmodified.

d.      Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e.      This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

3.       I can  skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

 

4.

Make a supervisord set of init scripts and make the docker file do what it was intended – install the files.  This is kind of a mashup of your 1-3 ideas.  Good thinking :)

 

 

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.

Docker really was not designed to run systemd as part of docker build.

 

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have

Is should I use the kolla build system to make the base image or not.

 

If anyone else has suggestion on how I can progress  please let me know but currently I am leaning towards option 2.

 

 

If you have questions about my suggestion to use supervisord, hit me up on IRC.  Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would.  Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.

[Mooney, Sean K]  I have briefly used supervisord before for a pet project https://github.com/SeanMooney/docker-devstack to create a container for running devstack so it did hot pollute my host.

supervisord  is a nice tool. Im just about to head home for the weekend but I might grab you on irc on Monday to follow up.

 

 

Regards

-steve

 

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

 

GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies.  I'd like to keep that part of Kolla intact :)

[Mooney, Sean K]  yes I would prefer not to break that too. This was basically the option of we don’t actually do the integration and instead just tell

The user how to use bifrost to do the deployment but leave it up to them do decide how to install it. so for me that was plan Z so we have a couple of letter

Go through first.

 

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered

Quite well as part of the bifrost project.

 

Regards

Sean.

 

Answer 5

Hi

If we choose to use bifrost to deploy ironic standalone I think combining kevins previous
suggestion of modifying the bifrost install playbook with Steve Dake's suggestion of creating a series
of supervisord configs for running each of the service is a reasonable approch.

I am currently look to scope how much effort would be required to split the main task in the bifrost-ironic-install role
https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifrost-ironic-install/tasks/main.yml
into 3 files which would be included in the main.yml:
Installcomponets.yml (executed when skipinstall is not defiend)
Bootstrapcomponents.yml (executed when skipbootstrap is not defiend)
Startcomponents.yml (executed when skipstart is not defiend)
By default all three would be executed maintain the current behavior of bifrost today,.

During the kolla build of the biforst image the https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml would be in
run with skipbootstrap and skipstart defined as true so only Install_componets.yml will be executed by the main task.
This would install all software components of bifrost/ironic without preforming configuration or starting the services.

At deployment time during the bootstrap phase we would spawn an instance of the biforst-base container and invoke
https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with skipinstall and skipstart defined executing Bootstrap_components.yml

Bootstrap_components.yml would encapsulate all logic related to creating the ironic db(running migration scripts) and generating the configuration
Files for the biforst components.

Finally in the start phase we have 3 options

a) Spawn an instance of the bifrost-supervisor container and use supervisord to run the bifrost/ironic services (fat container)

b) Spawn an instance of the bifrost-base container and Invoke https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with
skipinstall and skipbootstrap and allow biforst to star the services.(fat container)

c) Spawn a series of containers each running a single service sharing the required volumes to allow them to communicate (app containers)

I would welcome any input for the bifrost community on this especially related to the decomposition of the main.yml into 3 phases.
Im hoping to do a quick poc this week to see how easy it is to do this decomposition.

I would also like to call out upfront that depending on the scope of this item I may have to withdraw from contributing to it.
I work in intel's network platforms group so enabling baremetal installation is somewhat outside the standard
Work our division undertakes. If we can reuse bifrost to do most of the heavy lifting of creating the bifrost container and deploying ironic then
The scope of creating the bifrost container is small enough that I can justify spending some of my time working on it. if it requires
Significant changes to bifrost or rework of kolla's ironic support then I will have to step back and focus more on feature that are closer aligned to
Our teams core networking and orchestration focus such as enhancing kolla to be able to deploy ovs with dpdk and/or opendaylight which are
Also items I would like to contribute to this cycle. I don't want to commit to delivering this feature unless I know I will have the time to work on
It but am happy to help where I can.

@kevin some replies to your questions inline.

Regards
Sean.

From: Fox, Kevin M [mailto:Kevin.Fox@pnnl.gov]
Sent: Friday, May 6, 2016 9:17 PM
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

I was under the impression bifrost was 2 things, one, an installer/configurator of ironic in a stand alone mode, and two, a management tool for getting machines deployed without needing nova using ironic.
[Mooney, Sean K] yes this is correct, bifrost does provide both install playbooks for deploying ironic in standalone mode and a series of playbooks for dynamically enrolling node in ironic and dynamically deploy imanges to host
Without requiring nova. Bifrost also provides intergration with Disk image builder to generate machine images if desired.

The first use case seems like it should just be handled by enhancing kolla's ironic container stuff to directly to handle the use case, doing things the kolla way. This seems much cleaner to me. Doing it at runtime looses most of the benefits of doing it in a container at all.
[Mooney, Sean K] I was not suggestiong doing the installation at runtime. Option 2 and 3 suggested spawning a container as part of the build in which the install playbook would be run.
That container would then be stopped and exported to form the base image for the bifrost continer(s). The base image (bifrost-postinstall) would either be use to create a fat containter using an init system such as supervisord to run each of the services
or be used as the base image for a set of bifrost container each of which ran a single component.

The second adds a lot of value I think, and thats what the bifrost container should be?
[Mooney, Sean K] yes it does and I think it can be reused regarless or how we decide to deploy ironic.

Thanks,
Kevin

---

From: Mooney, Sean K [sean.k.mooney@intel.com]
Sent: Friday, May 06, 2016 12:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

From: Steven Dake (stdake) [mailto:stdake@cisco.com]
Sent: Friday, May 6, 2016 6:56 PM
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

Sean,

Thanks for taking this on :) I didn't know you had such an AR :)
[Mooney, Sean K] well if other want to do the work that ok with me too but I was planning on deploying bifrost
At home again anyway so I taught I might as well try to automate the process while im at it.

From: "Mooney, Sean K" sean.k.mooney@intel.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

Following up on my AR from the kolla host repository session
https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo
I started working on creating a kolla bifrost container.

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.
In particular the install playbook both installs the ironic dependencies and configure and runs the services.

What I'd do here is ignore the install playbook and duplicate what it installs. We don't want to install at run time, we want to install at build time. You weren't clear if that is what your doing.
[Mooney, Sean K] that is certainly an option but bifrost is an installer for ironic and its supporting service. Not using its installation scripts significantly reduces the value of
Integrating with bifrost vs fixing the existing ironic support in kolla and using that to provision the undercloud.

The reason we would ignore the install playbook is because it runs the services. We need to run the services in a different way. This will (as we discussed at ODS) be a fat container on the underlord cloud - which I guess is ok. I'd recommend not using systemd, as that will break systemd systems badly. Instead use a different init system, such as supervisord.
[Mooney, Sean K] if we don't use the bifrost install playbook then yes supervisord would be a good choice for the init system.
Looking at the official centos docker image https://hub.docker.com/_/centos/ they do provided instruction for running systemd containers tough I have had issues with this in the past.

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the
Infrastructure services (mysql,rabbit ...) without a running init system which is not present during the docker build.

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran
Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

This leave me with 3 paths forward.

1. I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2. I can use the kolla build system to build only part of the image

a. the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b. After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c. I can then connect to this running container and run the bifrost install script unmodified.

d. Once it is finished I can stop the container and export it to an image "bifros-postinstall".

e. This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

1. I can skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

4.
Make a supervisord set of init scripts and make the docker file do what it was intended - install the files. This is kind of a mashup of your 1-3 ideas. Good thinking :)

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.
Docker really was not designed to run systemd as part of docker build.

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have
Is should I use the kolla build system to make the base image or not.

If anyone else has suggestion on how I can progress please let me know but currently I am leaning towards option 2.

If you have questions about my suggestion to use supervisord, hit me up on IRC. Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would. Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.
[Mooney, Sean K] I have briefly used supervisord before for a pet project https://github.com/SeanMooney/docker-devstack to create a container for running devstack so it did hot pollute my host.
supervisord is a nice tool. Im just about to head home for the weekend but I might grab you on irc on Monday to follow up.

Regards
-steve

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

GROAN - one advantage containers provide us is not mucking up the host OS with a bajillion dependencies. I'd like to keep that part of Kolla intact :)
[Mooney, Sean K] yes I would prefer not to break that too. This was basically the option of we don't actually do the integration and instead just tell
The user how to use bifrost to do the deployment but leave it up to them do decide how to install it. so for me that was plan Z so we have a couple of letter
Go through first.

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered
Quite well as part of the bifrost project.

Regards
Sean.

---

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hi

 

If we choose to use bifrost to deploy ironic standalone I think combining kevins previous

suggestion of modifying the bifrost install playbook with Steve Dake’s suggestion of creating a series

of supervisord configs for running each of the service is a reasonable approch.

 

I am currently look to scope how much effort would be required to split  the main task in the bifrost-ironic-install role

https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifrost-ironic-install/tasks/main.yml

into 3 files which would be included in the main.yml:

Install_componets.yml (executed when skip_install is not defiend)

Bootstrap_components.yml (executed when skip_bootstrap is not defiend)

Start_components.yml  (executed when skip_start is not defiend)

By default all three would be executed maintain the current behavior of bifrost today,.

 

During the kolla build of the biforst image the https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml would be in

run with skip_bootstrap and skip_start defined as true so only Install_componets.yml will be executed by the main task.

This would install all software components of bifrost/ironic without preforming configuration or starting the services.

 

At deployment time during the bootstrap phase we would spawn an instance of the biforst-base container and invoke

https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with skip_install and skip_start defined executing Bootstrap_components.yml

 

Bootstrap_components.yml would encapsulate all logic related to creating the ironic db(running migration scripts) and generating the configuration

Files for the biforst components.

 

Finally in the start phase we have 3 options

a)      Spawn an instance of the bifrost-supervisor container and use supervisord to run the bifrost/ironic services (fat container)

b)      Spawn an instance of the bifrost-base container and Invoke https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with
skip_install and skip_bootstrap and allow biforst to star the services.(fat container)

c)       Spawn a series of containers each running a single service sharing the required volumes to allow them  to communicate (app containers)

 

 

I would welcome any input for the bifrost community on this especially related to the decomposition of the main.yml into 3 phases.

Im hoping to do a quick poc this week to see how easy it is to do this decomposition.

 

I would also like to call out upfront that depending on the scope of this item I may have to withdraw from contributing to it.

I work in intel’s network platforms group so enabling baremetal installation is somewhat outside the standard

Work our division undertakes.  If we can reuse bifrost to do most of the heavy lifting of creating the bifrost container and deploying ironic then

The scope of creating the bifrost container is small enough that I can justify spending some of my time working on it. if it requires

Significant changes to bifrost or rework of kolla’s ironic support then I will have to step back and focus more on feature that are closer aligned to

Our teams core networking and orchestration focus such as enhancing kolla to be able to deploy ovs with dpdk  and/or opendaylight which are

Also items I would like to contribute to this cycle. I don’t want to commit to delivering this feature unless I know I will have the time to work on

It but am happy to help where I can.

 

@kevin some replies to your questions inline.

 

Regards

Sean.

 

 

From: Fox, Kevin M [mailto:Kevin.Fox@pnnl.gov]
Sent: Friday, May 6, 2016 9:17 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

I was under the impression bifrost was 2 things, one, an installer/configurator of ironic in a stand alone mode, and two, a management tool for getting machines deployed without needing nova using ironic.

[Mooney, Sean K] yes this is correct, bifrost does provide both install playbooks for deploying ironic in standalone mode and a series of playbooks for dynamically enrolling node in ironic and dynamically deploy imanges to host

Without requiring nova. Bifrost also provides intergration with Disk image builder to generate machine images if desired.

The first use case seems like it should just be handled by enhancing kolla's ironic container stuff to directly to handle the use case, doing things the kolla way. This seems much cleaner to me. Doing it at runtime looses most of the benefits of doing it in a container at all.

[Mooney, Sean K] I was not suggestiong doing the installation at runtime. Option 2 and 3   suggested spawning a container as part of the build in which the install playbook would be run.

That container would then be stopped and exported to form the base image for the bifrost continer(s). The base image (bifrost-postinstall)  would either be use to create  a fat containter using an init system such as supervisord to run each of the services

or be used as the base image for a set of bifrost container each of which ran a single component.

The second adds a lot of value I think, and thats what the bifrost container should be?

[Mooney, Sean K]  yes it does and I think it can be reused regarless or how we decide to deploy ironic.

 

Thanks,
Kevin

---

From: Mooney, Sean K [sean.k.mooney@intel.com]
Sent: Friday, May 06, 2016 12:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

 

From: Steven Dake (stdake) [mailto:stdake@cisco.com]
Sent: Friday, May 6, 2016 6:56 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

Sean,

 

Thanks for taking this on :)  I didn't know you had such an AR :)

[Mooney, Sean K] well if other want to do the work that ok with me too but I was planning on deploying bifrost

At home again anyway so I taught I  might as well try to automate the process while im at it.

 

From: "Mooney, Sean K" <sean.k.mooney@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

 

Hi everyone.

 

Following up on my AR from the kolla host repository session

https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo

I started working on creating a kolla bifrost container.

 

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.

In particular the install playbook both installs the ironic dependencies and configure and runs the services.

 

 

What I'd do here is ignore the install playbook and duplicate what it installs.  We don't want to install at run time, we want to install at build time.  You weren't clear if that is what your doing.

[Mooney, Sean K] that is certainly an option but bifrost is an installer for ironic and its supporting service. Not using its installation scripts significantly reduces the value of

Integrating with bifrost vs fixing the existing ironic support in kolla and using that to provision the undercloud.

 

The reason we would ignore the install playbook is because it runs the services.  We need to run the services in a different way.  This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok.  I'd recommend not using systemd, as that will break systemd systems badly.  Instead use a different init system, such as supervisord.

[Mooney, Sean K] if we don’t use the  bifrost install playbook then yes supervisord would be a good choice for the init system.

Looking at the official centos docker image https://hub.docker.com/_/centos/  they do provided instruction for running systemd containers tough I have had issues with this in the past.

 

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the

Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

 

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran

Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

 

 

This leave me with 3 paths forward.

 

1.       I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2.       I can use the kolla build system to build only part of the image

a.        the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b.      After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c.       I can then connect to this running container and run the bifrost install script unmodified.

d.      Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e.      This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

3.       I can  skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

 

4.

Make a supervisord set of init scripts and make the docker file do what it was intended – install the files.  This is kind of a mashup of your 1-3 ideas.  Good thinking :)

 

 

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.

Docker really was not designed to run systemd as part of docker build.

 

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have

Is should I use the kolla build system to make the base image or not.

 

If anyone else has suggestion on how I can progress  please let me know but currently I am leaning towards option 2.

 

 

If you have questions about my suggestion to use supervisord, hit me up on IRC.  Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would.  Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.

[Mooney, Sean K]  I have briefly used supervisord before for a pet project https://github.com/SeanMooney/docker-devstack to create a container for running devstack so it did hot pollute my host.

supervisord  is a nice tool. Im just about to head home for the weekend but I might grab you on irc on Monday to follow up.

 

 

Regards

-steve

 

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

 

GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies.  I'd like to keep that part of Kolla intact :)

[Mooney, Sean K]  yes I would prefer not to break that too. This was basically the option of we don’t actually do the integration and instead just tell

The user how to use bifrost to do the deployment but leave it up to them do decide how to install it. so for me that was plan Z so we have a couple of letter

Go through first.

 

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered

Quite well as part of the bifrost project.

 

Regards

Sean.

 

Answer 6

Hi folks,

It's a shame that etherpad was down during the ODS kolla/bifrost session. My
recollection is that we agreed not to re-invent it Bifrost in containers,
but to just stick with running it in a VM (as it is today) because that is
the quickest path, and allows the Kolla community to leverage the work that
the Ironic/Bifrost community is already doing.

I'd like to respond to several of the emails in this thread and, hopefully,
clear up some misunderstandings. Pardon the coming series of responses, but
it's easier than trying to respond to one email.

--Deva

On Mon, May 9, 2016 at 11:06 AM Mooney, Sean K sean.k.mooney@intel.com
wrote:

Hi

If we choose to use bifrost to deploy ironic standalone I think combining
kevins previous

suggestion of modifying the bifrost install playbook with Steve Dake’s
suggestion of creating a series

of supervisord configs for running each of the service is a reasonable
approch.

I am currently look to scope how much effort would be required to split
the main task in the bifrost-ironic-install role

https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifrost-ironic-install/tasks/main.yml

into 3 files which would be included in the main.yml:

Installcomponets.yml (executed when skipinstall is not defiend)

Bootstrapcomponents.yml (executed when skipbootstrap is not defiend)

Startcomponents.yml (executed when skipstart is not defiend)

By default all three would be executed maintain the current behavior of
bifrost today,.

During the kolla build of the biforst image the
https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml
would be in

run with skipbootstrap and skipstart defined as true so only
Install_componets.yml will be executed by the main task.

This would install all software components of bifrost/ironic without
preforming configuration or starting the services.

At deployment time during the bootstrap phase we would spawn an instance
of the biforst-base container and invoke

https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml
with skipinstall and skipstart defined executing Bootstrap_components.yml

Bootstrap_components.yml would encapsulate all logic related to creating
the ironic db(running migration scripts) and generating the configuration

Files for the biforst components.

Finally in the start phase we have 3 options

a) Spawn an instance of the bifrost-supervisor container and use
supervisord to run the bifrost/ironic services (fat container)

b) Spawn an instance of the bifrost-base container and Invoke
https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml
with
skipinstall and skipbootstrap and allow biforst to star the
services.(fat container)

c) Spawn a series of containers each running a single service
sharing the required volumes to allow them to communicate (app containers)

I would welcome any input for the bifrost community on this especially
related to the decomposition of the main.yml into 3 phases.

Im hoping to do a quick poc this week to see how easy it is to do this
decomposition.

I would also like to call out upfront that depending on the scope of this
item I may have to withdraw from contributing to it.

I work in intel’s network platforms group so enabling baremetal
installation is somewhat outside the standard

Work our division undertakes. If we can reuse bifrost to do most of the
heavy lifting of creating the bifrost container and deploying ironic then

The scope of creating the bifrost container is small enough that I can
justify spending some of my time working on it. if it requires

Significant changes to bifrost or rework of kolla’s ironic support then I
will have to step back and focus more on feature that are closer aligned to

Our teams core networking and orchestration focus such as enhancing kolla
to be able to deploy ovs with dpdk and/or opendaylight which are

Also items I would like to contribute to this cycle. I don’t want to
commit to delivering this feature unless I know I will have the time to
work on

It but am happy to help where I can.

@kevin some replies to your questions inline.

Regards

Sean.

From: Fox, Kevin M [mailto:Kevin.Fox@pnnl.gov]
Sent: Friday, May 6, 2016 9:17 PM

To: OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

I was under the impression bifrost was 2 things, one, an
installer/configurator of ironic in a stand alone mode, and two, a
management tool for getting machines deployed without needing nova using
ironic.

[Mooney, Sean K] yes this is correct, bifrost does provide both install
playbooks for deploying ironic in standalone mode and a series of playbooks
for dynamically enrolling node in ironic and dynamically deploy imanges to
host

Without requiring nova. Bifrost also provides intergration with Disk
image builder to generate machine images if desired.

The first use case seems like it should just be handled by enhancing
kolla's ironic container stuff to directly to handle the use case, doing
things the kolla way. This seems much cleaner to me. Doing it at runtime
looses most of the benefits of doing it in a container at all.

[Mooney, Sean K] I was not suggestiong doing the installation at runtime.
Option 2 and 3 suggested spawning a container as part of the build in
which the install playbook would be run.

That container would then be stopped and exported to form the base image
for the bifrost continer(s). The base image (bifrost-postinstall) would
either be use to create a fat containter using an init system such as
supervisord to run each of the services

*or be used as the base image for a set of bifrost container each of which
ran a single component. *

The second adds a lot of value I think, and thats what the bifrost
container should be?

[Mooney, Sean K] yes it does and I think it can be reused regarless or
how we decide to deploy ironic.

Thanks,
Kevin

---

From: Mooney, Sean K [sean.k.mooney@intel.com]
Sent: Friday, May 06, 2016 12:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

From: Steven Dake (stdake) [mailto:stdake@cisco.com stdake@cisco.com]
Sent: Friday, May 6, 2016 6:56 PM
To: OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

Sean,

Thanks for taking this on :) I didn't know you had such an AR :)

*[Mooney, Sean K] well if other want to do the work that ok with me too
but I was planning on deploying bifrost *

At home again anyway so I taught I might as well try to automate the
process while im at it.

*From: *"Mooney, Sean K" sean.k.mooney@intel.com
*Reply-To: *"OpenStack Development Mailing List (not for usage
questions)" openstack-dev@lists.openstack.org
*Date: *Friday, May 6, 2016 at 10:14 AM
*To: *"OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
*Subject: *[openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

Following up on my AR from the kolla host repository session

https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo

I started working on creating a kolla bifrost container.

Are some initial success it have hit a roadblock with the current install
playbook provided by bifrost.

In particular the install playbook both installs the ironic dependencies
and configure and runs the services.

What I'd do here is ignore the install playbook and duplicate what it
installs. We don't want to install at run time, we want to install at
build time. You weren't clear if that is what your doing.

*[Mooney, Sean K] that is certainly an option but bifrost is an installer
for ironic and its supporting service. Not using its installation scripts
significantly reduces the value of *

*Integrating with bifrost vs fixing the existing ironic support in kolla
and using that to provision the undercloud. *

The reason we would ignore the install playbook is because it runs the
services. We need to run the services in a different way. This will (as
we discussed at ODS) be a fat container on the underlord cloud – which I
guess is ok. I'd recommend not using systemd, as that will break systemd
systems badly. Instead use a different init system, such as supervisord.

*[Mooney, Sean K] if we don’t use the bifrost install playbook then yes
supervisord would be a good choice for the init system. *

Looking at the official centos docker image
https://hub.docker.com/_/centos/ https://hub.docker.com/_/centos/ they
do provided instruction for running systemd containers tough I have had
issues with this in the past.

The installation of ironic and its dependencies would not be a problem but
the ansible service module is not cable able of starting the

Infrastructure services (mysql,rabbit …) without a running init system
which is not present during the docker build.

When I created a biforst container in the past is spawned a Ubuntu upstart
container then docker exec into the container and ran

Bifrost install script. This works because the init system is running and
the service module could test and start the relevant services.

This leave me with 3 paths forward.

1. I can continue to try and make the bifrost install script work
   with the kolla build system by using sed to modify the install playbook or
   try start systemd during the docker build.

2. I can use the kolla build system to build only part of the image

a. the bifrost-base image would be build with the kolla build
system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system
such as adding headers/footers to be used.

b. After the base image is built by kolla I can spawn an instance of
bifrost-base with systemd running

c. I can then connect to this running container and run the bifrost
install script unmodified.

d. Once it is finished I can stop the container and export it to an
image “bifros-postinstall”.

e. This can either be used directly (fat container) or as the base
image for other container that run each of the ironic services (thin
containers)

1. I can skip the kolla build system entirely and create a
   script/playbook that will build the bifrost container similar to 2.

4.

Make a supervisord set of init scripts and make the docker file do what it
was intended – install the files. This is kind of a mashup of your 1-3
ideas. Good thinking :)

While option 1 would fully use the kolla build system It is my least
favorite as it is both hacky and complicated to make work.

Docker really was not designed to run systemd as part of docker build.

For option 2 and 3 I can provide a single playbook/script that will fully
automate the build but the real question I have

Is should I use the kolla build system to make the base image or not.

If anyone else has suggestion on how I can progress please let me know
but currently I am leaning towards option 2.

If you have questions about my suggestion to use supervisord, hit me up on
IRC. Ideally we would also contribute these init scripts back into bifrost
code base assuming they want them, which I think they would. Nobody will
run systemd in a container, and we all have an interest in seeing BiFrost
as the standard bare metal deployment model inside or outside of containers.

[Mooney, Sean K] I have briefly used supervisord before for a pet
project https://github.com/SeanMooney/docker-devstack
https://github.com/SeanMooney/docker-devstack to create a container for
running devstack so it did hot pollute my host.

supervisord is a nice tool. Im just about to head home for the weekend
but I might grab you on irc on Monday to follow up.

Regards

-steve

The only other option I see would be to not use a container and either
install biforst on the host or in a vm.

GROAN – one advantage containers provide us is not mucking up the host OS
with a bajillion dependencies. I'd like to keep that part of Kolla intact
:)

[Mooney, Sean K] yes I would prefer not to break that too. This was
basically the option of we don’t actually do the integration and instead
just tell

The user how to use bifrost to do the deployment but leave it up to them
do decide how to install it. so for me that was plan Z so we have a couple
of letter

Go through first.

These would essentially be a no op for kolla as we would simply have to
document how to install bifrost which is covered

Quite well as part of the bifrost project.

Regards

Sean.

---

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

---

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hi folks,

It's a shame that etherpad was down during the ODS kolla/bifrost session. My recollection is that we agreed *not* to re-invent it Bifrost in containers, but to just stick with running it in a VM (as it is today) because that is the quickest path, and allows the Kolla community to leverage the work that the Ironic/Bifrost community is already doing.

I'd like to respond to several of the emails in this thread and, hopefully, clear up some misunderstandings. Pardon the coming series of responses, but it's easier than trying to respond to one email.

--Deva

On Mon, May 9, 2016 at 11:06 AM Mooney, Sean K <sean.k.mooney@intel.com> wrote:

Hi

 

If we choose to use bifrost to deploy ironic standalone I think combining kevins previous

suggestion of modifying the bifrost install playbook with Steve Dake’s suggestion of creating a series

of supervisord configs for running each of the service is a reasonable approch.

 

I am currently look to scope how much effort would be required to split  the main task in the bifrost-ironic-install role

https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifrost-ironic-install/tasks/main.yml

into 3 files which would be included in the main.yml:

Install_componets.yml (executed when skip_install is not defiend)

Bootstrap_components.yml (executed when skip_bootstrap is not defiend)

Start_components.yml  (executed when skip_start is not defiend)

By default all three would be executed maintain the current behavior of bifrost today,.

 

During the kolla build of the biforst image the https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml would be in

run with skip_bootstrap and skip_start defined as true so only Install_componets.yml will be executed by the main task.

This would install all software components of bifrost/ironic without preforming configuration or starting the services.

 

At deployment time during the bootstrap phase we would spawn an instance of the biforst-base container and invoke

https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with skip_install and skip_start defined executing Bootstrap_components.yml

 

Bootstrap_components.yml would encapsulate all logic related to creating the ironic db(running migration scripts) and generating the configuration

Files for the biforst components.

 

Finally in the start phase we have 3 options

a)      Spawn an instance of the bifrost-supervisor container and use supervisord to run the bifrost/ironic services (fat container)

b)      Spawn an instance of the bifrost-base container and Invoke https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with
skip_install and skip_bootstrap and allow biforst to star the services.(fat container)

c)       Spawn a series of containers each running a single service sharing the required volumes to allow them  to communicate (app containers)

 

 

I would welcome any input for the bifrost community on this especially related to the decomposition of the main.yml into 3 phases.

Im hoping to do a quick poc this week to see how easy it is to do this decomposition.

 

I would also like to call out upfront that depending on the scope of this item I may have to withdraw from contributing to it.

I work in intel’s network platforms group so enabling baremetal installation is somewhat outside the standard

Work our division undertakes.  If we can reuse bifrost to do most of the heavy lifting of creating the bifrost container and deploying ironic then

The scope of creating the bifrost container is small enough that I can justify spending some of my time working on it. if it requires

Significant changes to bifrost or rework of kolla’s ironic support then I will have to step back and focus more on feature that are closer aligned to

Our teams core networking and orchestration focus such as enhancing kolla to be able to deploy ovs with dpdk  and/or opendaylight which are

Also items I would like to contribute to this cycle. I don’t want to commit to delivering this feature unless I know I will have the time to work on

It but am happy to help where I can.

 

@kevin some replies to your questions inline.

 

Regards

Sean.

 

 

From: Fox, Kevin M [mailto:Kevin.Fox@pnnl.gov]
Sent: Friday, May 6, 2016 9:17 PM

To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

I was under the impression bifrost was 2 things, one, an installer/configurator of ironic in a stand alone mode, and two, a management tool for getting machines deployed without needing nova using ironic.

[Mooney, Sean K] yes this is correct, bifrost does provide both install playbooks for deploying ironic in standalone mode and a series of playbooks for dynamically enrolling node in ironic and dynamically deploy imanges to host

Without requiring nova. Bifrost also provides intergration with Disk image builder to generate machine images if desired.

The first use case seems like it should just be handled by enhancing kolla's ironic container stuff to directly to handle the use case, doing things the kolla way. This seems much cleaner to me. Doing it at runtime looses most of the benefits of doing it in a container at all.

[Mooney, Sean K] I was not suggestiong doing the installation at runtime. Option 2 and 3   suggested spawning a container as part of the build in which the install playbook would be run.

That container would then be stopped and exported to form the base image for the bifrost continer(s). The base image (bifrost-postinstall)  would either be use to create  a fat containter using an init system such as supervisord to run each of the services

or be used as the base image for a set of bifrost container each of which ran a single component.

The second adds a lot of value I think, and thats what the bifrost container should be?

[Mooney, Sean K]  yes it does and I think it can be reused regarless or how we decide to deploy ironic.

 

Thanks,
Kevin

---

From: Mooney, Sean K [sean.k.mooney@intel.com]
Sent: Friday, May 06, 2016 12:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

 

From: Steven Dake (stdake) [mailto:stdake@cisco.com]
Sent: Friday, May 6, 2016 6:56 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

Sean,

 

Thanks for taking this on :)  I didn't know you had such an AR :)

[Mooney, Sean K] well if other want to do the work that ok with me too but I was planning on deploying bifrost

At home again anyway so I taught I  might as well try to automate the process while im at it.

 

From: "Mooney, Sean K" <sean.k.mooney@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

 

Hi everyone.

 

Following up on my AR from the kolla host repository session

https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo

I started working on creating a kolla bifrost container.

 

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.

In particular the install playbook both installs the ironic dependencies and configure and runs the services.

 

 

What I'd do here is ignore the install playbook and duplicate what it installs.  We don't want to install at run time, we want to install at build time.  You weren't clear if that is what your doing.

[Mooney, Sean K] that is certainly an option but bifrost is an installer for ironic and its supporting service. Not using its installation scripts significantly reduces the value of

Integrating with bifrost vs fixing the existing ironic support in kolla and using that to provision the undercloud.

 

The reason we would ignore the install playbook is because it runs the services.  We need to run the services in a different way.  This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok.  I'd recommend not using systemd, as that will break systemd systems badly.  Instead use a different init system, such as supervisord.

[Mooney, Sean K] if we don’t use the  bifrost install playbook then yes supervisord would be a good choice for the init system.

Looking at the official centos docker image https://hub.docker.com/_/centos/  they do provided instruction for running systemd containers tough I have had issues with this in the past.

 

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the

Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

 

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran

Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

 

 

This leave me with 3 paths forward.

 

1.       I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2.       I can use the kolla build system to build only part of the image

a.        the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b.      After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c.       I can then connect to this running container and run the bifrost install script unmodified.

d.      Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e.      This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

3.       I can  skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

 

4.

Make a supervisord set of init scripts and make the docker file do what it was intended – install the files.  This is kind of a mashup of your 1-3 ideas.  Good thinking :)

 

 

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.

Docker really was not designed to run systemd as part of docker build.

 

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have

Is should I use the kolla build system to make the base image or not.

 

If anyone else has suggestion on how I can progress  please let me know but currently I am leaning towards option 2.

 

 

If you have questions about my suggestion to use supervisord, hit me up on IRC.  Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would.  Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.

[Mooney, Sean K]  I have briefly used supervisord before for a pet project https://github.com/SeanMooney/docker-devstack to create a container for running devstack so it did hot pollute my host.

supervisord  is a nice tool. Im just about to head home for the weekend but I might grab you on irc on Monday to follow up.

 

 

Regards

-steve

 

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

 

GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies.  I'd like to keep that part of Kolla intact :)

[Mooney, Sean K]  yes I would prefer not to break that too. This was basically the option of we don’t actually do the integration and instead just tell

The user how to use bifrost to do the deployment but leave it up to them do decide how to install it. so for me that was plan Z so we have a couple of letter

Go through first.

 

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered

Quite well as part of the bifrost project.

 

Regards

Sean.

 

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Answer 7

On Fri, May 6, 2016 at 10:56 AM, Steven Dake (stdake) stdake@cisco.com
wrote:

Sean,

Thanks for taking this on :) I didn't know you had such an AR :)

From: "Mooney, Sean K" sean.k.mooney@intel.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

Following up on my AR from the kolla host repository session

https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo

I started working on creating a kolla bifrost container.

Are some initial success it have hit a roadblock with the current install
playbook provided by bifrost.

In particular the install playbook both installs the ironic dependencies
and configure and runs the services.

What I'd do here is ignore the install playbook and duplicate what it
installs. We don't want to install at run time, we want to install at
build time. You weren't clear if that is what your doing.

That's going to be quite a bit of work. The bifrost-install playbook does a
lot more than just install the ironic services and a few system packages;
it also installs rabbit, mysql, nginx, dnsmasq and configures all of
these in a very specific way. Re-inventing all of this is basically
re-inventing Bifrost.

The reason we would ignore the install playbook is because it runs the
services. We need to run the services in a different way.

Do you really need to run them in a different way? If it's just a matter of
"use a different init system", I wonder how easily that could be
accomodated within the Bifrost project itself.... If there's another
reason, please elaborate.

This will (as we discussed at ODS) be a fat container on the underlord
cloud – which I guess is ok. I'd recommend not using systemd, as that will
break systemd systems badly. Instead use a different init system, such as
supervisord.

The installation of ironic and its dependencies would not be a problem but
the ansible service module is not cable able of starting the

Infrastructure services (mysql,rabbit …) without a running init system
which is not present during the docker build.

When I created a biforst container in the past is spawned a Ubuntu upstart
container then docker exec into the container and ran

Bifrost install script. This works because the init system is running and
the service module could test and start the relevant services.

This leave me with 3 paths forward.

1. I can continue to try and make the bifrost install script work
   with the kolla build system by using sed to modify the install playbook or
   try start systemd during the docker build.

2. I can use the kolla build system to build only part of the image

a. the bifrost-base image would be build with the kolla build
system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system
such as adding headers/footers to be used.

b. After the base image is built by kolla I can spawn an instance of
bifrost-base with systemd running

c. I can then connect to this running container and run the bifrost
install script unmodified.

d. Once it is finished I can stop the container and export it to an
image “bifros-postinstall”.

e. This can either be used directly (fat container) or as the base
image for other container that run each of the ironic services (thin
containers)

1. I can skip the kolla build system entirely and create a
   script/playbook that will build the bifrost container similar to 2.

4.
Make a supervisord set of init scripts and make the docker file do what it
was intended – install the files. This is kind of a mashup of your 1-3
ideas. Good thinking :)

While option 1 would fully use the kolla build system It is my least
favorite as it is both hacky and complicated to make work.

Docker really was not designed to run systemd as part of docker build.

For option 2 and 3 I can provide a single playbook/script that will fully
automate the build but the real question I have

Is should I use the kolla build system to make the base image or not.

If anyone else has suggestion on how I can progress please let me know
but currently I am leaning towards option 2.

If you have questions about my suggestion to use supervisord, hit me up on
IRC. Ideally we would also contribute these init scripts back into bifrost
code base assuming they want them, which I think they would. Nobody will
run systemd in a container, and we all have an interest in seeing BiFrost
as the standard bare metal deployment model inside or outside of containers.

Regards
-steve

The only other option I see would be to not use a container and either
install biforst on the host or in a vm.

GROAN – one advantage containers provide us is not mucking up the host OS
with a bajillion dependencies. I'd like to keep that part of Kolla intact
:)

Right - don't install it on the host, but what's the problem with running
it in a VM?

FWIW, I already run Bifrost quite successfully in a VM in each of my
environments.

--Deva

---

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

On Fri, May 6, 2016 at 10:56 AM, Steven Dake (stdake) <stdake@cisco.com> wrote:

Sean,

Thanks for taking this on :)  I didn't know you had such an AR :)

From: "Mooney, Sean K" <sean.k.mooney@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

 

Following up on my AR from the kolla host repository session

https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo

I started working on creating a kolla bifrost container.

 

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.

In particular the install playbook both installs the ironic dependencies and configure and runs the services.

 

What I'd do here is ignore the install playbook and duplicate what it installs.  We don't want to install at run time, we want to install at build time.  You weren't clear if that is what your doing.

That's going to be quite a bit of work. The bifrost-install playbook does a lot more than just install the ironic services and a few system packages; it also installs rabbit, mysql, nginx, dnsmasq *and* configures all of these in a very specific way. Re-inventing all of this is basically re-inventing Bifrost.

 

 

The reason we would ignore the install playbook is because it runs the services.  We need to run the services in a different way.

Do you really need to run them in a different way? If it's just a matter of "use a different init system", I wonder how easily that could be accomodated within the Bifrost project itself.... If there's another reason, please elaborate.

 

 This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok.  I'd recommend not using systemd, as that will break systemd systems badly.  Instead use a different init system, such as supervisord.

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the

Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

 

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran

Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

 

 

This leave me with 3 paths forward.

 

1.       I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2.       I can use the kolla build system to build only part of the image

a.        the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b.      After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c.       I can then connect to this running container and run the bifrost install script unmodified.

d.      Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e.      This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

3.       I can  skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

4.

Make a supervisord set of init scripts and make the docker file do what it was intended – install the files.  This is kind of a mashup of your 1-3 ideas.  Good thinking :)

 

 

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.

Docker really was not designed to run systemd as part of docker build.

 

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have

Is should I use the kolla build system to make the base image or not.

 

If anyone else has suggestion on how I can progress  please let me know but currently I am leaning towards option 2.

 

If you have questions about my suggestion to use supervisord, hit me up on IRC.  Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would.  Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.

Regards

-steve

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies.  I'd like to keep that part of Kolla intact :)

Right - don't install it on the host, but what's the problem with running it in a VM?

FWIW, I already run Bifrost quite successfully in a VM in each of my environments.

--Deva

Answer 8

From: Devananda van der Veen devananda.vdv@gmail.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Monday, May 9, 2016 at 1:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

On Fri, May 6, 2016 at 10:56 AM, Steven Dake (stdake) stdake@cisco.com wrote:
Sean,

Thanks for taking this on :) I didn't know you had such an AR :)

From: "Mooney, Sean K" sean.k.mooney@intel.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

Following up on my AR from the kolla host repository session
https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo
I started working on creating a kolla bifrost container.

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.
In particular the install playbook both installs the ironic dependencies and configure and runs the services.

What I'd do here is ignore the install playbook and duplicate what it installs. We don't want to install at run time, we want to install at build time. You weren't clear if that is what your doing.

That's going to be quite a bit of work. The bifrost-install playbook does a lot more than just install the ironic services and a few system packages; it also installs rabbit, mysql, nginx, dnsmasq and configures all of these in a very specific way. Re-inventing all of this is basically re-inventing Bifrost.

Sean's latest proposal was splitting this one operation into three smaller decomposed steps.

The reason we would ignore the install playbook is because it runs the services. We need to run the services in a different way.

Do you really need to run them in a different way? If it's just a matter of "use a different init system", I wonder how easily that could be accomodated within the Bifrost project itself.... If there's another reason, please elaborate.

To run in a container, we cannot use systemd. This leaves us with supervisord, which certainly can and should be done in the context of upstream bifrost.

This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok. I'd recommend not using systemd, as that will break systemd systems badly. Instead use a different init system, such as supervisord.

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the
Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran
Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

This leave me with 3 paths forward.

1. I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2. I can use the kolla build system to build only part of the image

a. the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b. After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c. I can then connect to this running container and run the bifrost install script unmodified.

d. Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e. This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

1. I can skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

4.
Make a supervisord set of init scripts and make the docker file do what it was intended – install the files. This is kind of a mashup of your 1-3 ideas. Good thinking :)

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.
Docker really was not designed to run systemd as part of docker build.

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have
Is should I use the kolla build system to make the base image or not.

If anyone else has suggestion on how I can progress please let me know but currently I am leaning towards option 2.

If you have questions about my suggestion to use supervisord, hit me up on IRC. Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would. Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.

Regards
-steve

The only other option I see would be to not use a container and either install biforst on the host or in a vm.
GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies. I'd like to keep that part of Kolla intact :)

Right - don't install it on the host, but what's the problem with running it in a VM?

FWIW, I already run Bifrost quite successfully in a VM in each of my environments.

There isn't a super specific problem with running it in a VM other than Kolla is about containers not VMs. OpenStack can obviously be run in a VM – our major reason for wanting containers is upgradability which Vms don't offer atomically.

That said, we could run in a VM initially and over time port to run in a container. What we are after long term is a container–based approach to bifrost in upstream bifrost, not replicating or duplicating a bunch of work.

I believe Sean's approach of splitting out the 3 separate steps makes logical sense (to me) in the sense that the one major installation step is broken into the separate build & deploy steps that Kolla uses.

Hope that helps

Regards
-steve

--Deva

---

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

From: Devananda van der Veen <devananda.vdv@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: Monday, May 9, 2016 at 1:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

On Fri, May 6, 2016 at 10:56 AM, Steven Dake (stdake) <stdake@cisco.com> wrote:

Sean,

Thanks for taking this on :)  I didn't know you had such an AR :)

From: "Mooney, Sean K" <sean.k.mooney@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

 

Following up on my AR from the kolla host repository session

https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo

I started working on creating a kolla bifrost container.

 

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.

In particular the install playbook both installs the ironic dependencies and configure and runs the services.

 

What I'd do here is ignore the install playbook and duplicate what it installs.  We don't want to install at run time, we want to install at build time.  You weren't clear if that is what your doing.

That's going to be quite a bit of work. The bifrost-install playbook does a lot more than just install the ironic services and a few system packages; it also installs rabbit, mysql, nginx, dnsmasq *and* configures all of these in a very specific way. Re-inventing all of this is basically re-inventing Bifrost.

 

 

Sean's latest proposal was splitting this one operation into three smaller decomposed steps.

The reason we would ignore the install playbook is because it runs the services.  We need to run the services in a different way.

Do you really need to run them in a different way? If it's just a matter of "use a different init system", I wonder how easily that could be accomodated within the Bifrost project itself.... If there's another reason, please elaborate.

To run in a container, we cannot use systemd.  This leaves us with supervisord, which certainly can and should be done in the context of upstream bifrost.

 

 This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok.  I'd recommend not using systemd, as that will break systemd systems badly.  Instead use a different init system, such as supervisord.

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the

Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

 

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran

Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

 

 

This leave me with 3 paths forward.

 

1.       I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2.       I can use the kolla build system to build only part of the image

a.        the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b.      After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c.       I can then connect to this running container and run the bifrost install script unmodified.

d.      Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e.      This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

3.       I can  skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

4.

Make a supervisord set of init scripts and make the docker file do what it was intended – install the files.  This is kind of a mashup of your 1-3 ideas.  Good thinking :)

 

 

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.

Docker really was not designed to run systemd as part of docker build.

 

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have

Is should I use the kolla build system to make the base image or not.

 

If anyone else has suggestion on how I can progress  please let me know but currently I am leaning towards option 2.

 

If you have questions about my suggestion to use supervisord, hit me up on IRC.  Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would.  Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.

Regards

-steve

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies.  I'd like to keep that part of Kolla intact :)

Right - don't install it on the host, but what's the problem with running it in a VM?

FWIW, I already run Bifrost quite successfully in a VM in each of my environments.

There isn't a super specific problem with running it in a VM other than Kolla is about containers not VMs.  OpenStack can obviously be run in a VM – our major reason for wanting containers is upgradability which Vms don't offer atomically.

That said, we could run in a VM initially and over time port to run in a container.  What we are after long term is a container–based approach to bifrost in upstream bifrost, not replicating or duplicating a bunch of work.

I believe Sean's approach of splitting out the 3 separate steps makes logical sense (to me) in the sense that the one major installation step is broken into the separate build & deploy steps that Kolla uses.

Hope that helps

Regards

-steve

--Deva

Answer 9

From: Devananda van der Veen devananda.vdv@gmail.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Monday, May 9, 2016 at 1:05 PM
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi folks,

It's a shame that etherpad was down during the ODS kolla/bifrost session. My recollection is that we agreed not to re-invent it Bifrost in containers, but to just stick with running it in a VM (as it is today) because that is the quickest path, and allows the Kolla community to leverage the work that the Ironic/Bifrost community is already doing.

We absolutely want to use upstream Bifrost and not duplicate a bunch of work already done. That said, I don't recall any discussion or agreement about sticking to running it in a VM. If we choose that path in the short term, it would be my hope that long term there was a viable path to full containerization of Bifrost in a systematic baby steps iterative approach.

This email is about sorting out what those first baby steps involve :)

Regards
-steve

I'd like to respond to several of the emails in this thread and, hopefully, clear up some misunderstandings. Pardon the coming series of responses, but it's easier than trying to respond to one email.

--Deva

On Mon, May 9, 2016 at 11:06 AM Mooney, Sean K sean.k.mooney@intel.com wrote:
Hi

If we choose to use bifrost to deploy ironic standalone I think combining kevins previous
suggestion of modifying the bifrost install playbook with Steve Dake’s suggestion of creating a series
of supervisord configs for running each of the service is a reasonable approch.

I am currently look to scope how much effort would be required to split the main task in the bifrost-ironic-install role
https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifrost-ironic-install/tasks/main.yml
into 3 files which would be included in the main.yml:
Installcomponets.yml (executed when skipinstall is not defiend)
Bootstrapcomponents.yml (executed when skipbootstrap is not defiend)
Startcomponents.yml (executed when skipstart is not defiend)
By default all three would be executed maintain the current behavior of bifrost today,.

During the kolla build of the biforst image the https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml would be in
run with skipbootstrap and skipstart defined as true so only Install_componets.yml will be executed by the main task.
This would install all software components of bifrost/ironic without preforming configuration or starting the services.

At deployment time during the bootstrap phase we would spawn an instance of the biforst-base container and invoke
https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with skipinstall and skipstart defined executing Bootstrap_components.yml

Bootstrap_components.yml would encapsulate all logic related to creating the ironic db(running migration scripts) and generating the configuration
Files for the biforst components.

Finally in the start phase we have 3 options

a) Spawn an instance of the bifrost-supervisor container and use supervisord to run the bifrost/ironic services (fat container)

b) Spawn an instance of the bifrost-base container and Invoke https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with
skipinstall and skipbootstrap and allow biforst to star the services.(fat container)

c) Spawn a series of containers each running a single service sharing the required volumes to allow them to communicate (app containers)

I would welcome any input for the bifrost community on this especially related to the decomposition of the main.yml into 3 phases.
Im hoping to do a quick poc this week to see how easy it is to do this decomposition.

I would also like to call out upfront that depending on the scope of this item I may have to withdraw from contributing to it.
I work in intel’s network platforms group so enabling baremetal installation is somewhat outside the standard
Work our division undertakes. If we can reuse bifrost to do most of the heavy lifting of creating the bifrost container and deploying ironic then
The scope of creating the bifrost container is small enough that I can justify spending some of my time working on it. if it requires
Significant changes to bifrost or rework of kolla’s ironic support then I will have to step back and focus more on feature that are closer aligned to
Our teams core networking and orchestration focus such as enhancing kolla to be able to deploy ovs with dpdk and/or opendaylight which are
Also items I would like to contribute to this cycle. I don’t want to commit to delivering this feature unless I know I will have the time to work on
It but am happy to help where I can.

@kevin some replies to your questions inline.

Regards
Sean.

From: Fox, Kevin M [mailto:Kevin.Fox@pnnl.gov]
Sent: Friday, May 6, 2016 9:17 PM

To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

I was under the impression bifrost was 2 things, one, an installer/configurator of ironic in a stand alone mode, and two, a management tool for getting machines deployed without needing nova using ironic.
[Mooney, Sean K] yes this is correct, bifrost does provide both install playbooks for deploying ironic in standalone mode and a series of playbooks for dynamically enrolling node in ironic and dynamically deploy imanges to host
Without requiring nova. Bifrost also provides intergration with Disk image builder to generate machine images if desired.

The first use case seems like it should just be handled by enhancing kolla's ironic container stuff to directly to handle the use case, doing things the kolla way. This seems much cleaner to me. Doing it at runtime looses most of the benefits of doing it in a container at all.
[Mooney, Sean K] I was not suggestiong doing the installation at runtime. Option 2 and 3 suggested spawning a container as part of the build in which the install playbook would be run.
That container would then be stopped and exported to form the base image for the bifrost continer(s). The base image (bifrost-postinstall) would either be use to create a fat containter using an init system such as supervisord to run each of the services
or be used as the base image for a set of bifrost container each of which ran a single component.

The second adds a lot of value I think, and thats what the bifrost container should be?
[Mooney, Sean K] yes it does and I think it can be reused regarless or how we decide to deploy ironic.

Thanks,
Kevin

---

From: Mooney, Sean K [sean.k.mooney@intel.com]
Sent: Friday, May 06, 2016 12:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

From: Steven Dake (stdake) [mailto:stdake@cisco.com]
Sent: Friday, May 6, 2016 6:56 PM
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

Sean,

Thanks for taking this on :) I didn't know you had such an AR :)
[Mooney, Sean K] well if other want to do the work that ok with me too but I was planning on deploying bifrost
At home again anyway so I taught I might as well try to automate the process while im at it.

From: "Mooney, Sean K" sean.k.mooney@intel.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

Following up on my AR from the kolla host repository session
https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo
I started working on creating a kolla bifrost container.

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.
In particular the install playbook both installs the ironic dependencies and configure and runs the services.

What I'd do here is ignore the install playbook and duplicate what it installs. We don't want to install at run time, we want to install at build time. You weren't clear if that is what your doing.
[Mooney, Sean K] that is certainly an option but bifrost is an installer for ironic and its supporting service. Not using its installation scripts significantly reduces the value of
Integrating with bifrost vs fixing the existing ironic support in kolla and using that to provision the undercloud.

The reason we would ignore the install playbook is because it runs the services. We need to run the services in a different way. This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok. I'd recommend not using systemd, as that will break systemd systems badly. Instead use a different init system, such as supervisord.
[Mooney, Sean K] if we don’t use the bifrost install playbook then yes supervisord would be a good choice for the init system.
Looking at the official centos docker image https://hub.docker.com/_/centos/ they do provided instruction for running systemd containers tough I have had issues with this in the past.

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the
Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran
Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

This leave me with 3 paths forward.

1. I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2. I can use the kolla build system to build only part of the image

a. the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b. After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c. I can then connect to this running container and run the bifrost install script unmodified.

d. Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e. This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

1. I can skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

4.
Make a supervisord set of init scripts and make the docker file do what it was intended – install the files. This is kind of a mashup of your 1-3 ideas. Good thinking :)

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.
Docker really was not designed to run systemd as part of docker build.

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have
Is should I use the kolla build system to make the base image or not.

If anyone else has suggestion on how I can progress please let me know but currently I am leaning towards option 2.

If you have questions about my suggestion to use supervisord, hit me up on IRC. Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would. Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.
[Mooney, Sean K] I have briefly used supervisord before for a pet project https://github.com/SeanMooney/docker-devstack to create a container for running devstack so it did hot pollute my host.
supervisord is a nice tool. Im just about to head home for the weekend but I might grab you on irc on Monday to follow up.

Regards
-steve

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies. I'd like to keep that part of Kolla intact :)
[Mooney, Sean K] yes I would prefer not to break that too. This was basically the option of we don’t actually do the integration and instead just tell
The user how to use bifrost to do the deployment but leave it up to them do decide how to install it. so for me that was plan Z so we have a couple of letter
Go through first.

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered
Quite well as part of the bifrost project.

Regards
Sean.

---

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

---

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

From: Devananda van der Veen <devananda.vdv@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: Monday, May 9, 2016 at 1:05 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi folks,

It's a shame that etherpad was down during the ODS kolla/bifrost session. My recollection is that we agreed *not* to re-invent it Bifrost in containers, but to just stick with running it in a VM (as it is today) because that is the quickest path, and allows the Kolla community to leverage the work that the Ironic/Bifrost community is already doing.

We absolutely want to use upstream Bifrost and not duplicate a bunch of work already done.  That said, I don't recall any discussion or agreement about sticking to running it in a VM.  If we choose that path in the short term, it would be my hope that long term there was a viable path to full containerization of Bifrost in a systematic baby steps iterative approach.

This email is about sorting out what those first baby steps involve :)

Regards

-steve

I'd like to respond to several of the emails in this thread and, hopefully, clear up some misunderstandings. Pardon the coming series of responses, but it's easier than trying to respond to one email.

--Deva

On Mon, May 9, 2016 at 11:06 AM Mooney, Sean K <sean.k.mooney@intel.com> wrote:

Hi

 

If we choose to use bifrost to deploy ironic standalone I think combining kevins previous

suggestion of modifying the bifrost install playbook with Steve Dake’s suggestion of creating a series

of supervisord configs for running each of the service is a reasonable approch.

 

I am currently look to scope how much effort would be required to split  the main task in the bifrost-ironic-install role

https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifrost-ironic-install/tasks/main.yml

into 3 files which would be included in the main.yml:

Install_componets.yml (executed when skip_install is not defiend)

Bootstrap_components.yml (executed when skip_bootstrap is not defiend)

Start_components.yml  (executed when skip_start is not defiend)

By default all three would be executed maintain the current behavior of bifrost today,.

 

During the kolla build of the biforst image the https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml would be in

run with skip_bootstrap and skip_start defined as true so only Install_componets.yml will be executed by the main task.

This would install all software components of bifrost/ironic without preforming configuration or starting the services.

 

At deployment time during the bootstrap phase we would spawn an instance of the biforst-base container and invoke

https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with skip_install and skip_start defined executing Bootstrap_components.yml

 

Bootstrap_components.yml would encapsulate all logic related to creating the ironic db(running migration scripts) and generating the configuration

Files for the biforst components.

 

Finally in the start phase we have 3 options

a)      Spawn an instance of the bifrost-supervisor container and use supervisord to run the bifrost/ironic services (fat container)

b)      Spawn an instance of the bifrost-base container and Invoke https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with
skip_install and skip_bootstrap and allow biforst to star the services.(fat container)

c)       Spawn a series of containers each running a single service sharing the required volumes to allow them  to communicate (app containers)

 

 

I would welcome any input for the bifrost community on this especially related to the decomposition of the main.yml into 3 phases.

Im hoping to do a quick poc this week to see how easy it is to do this decomposition.

 

I would also like to call out upfront that depending on the scope of this item I may have to withdraw from contributing to it.

I work in intel’s network platforms group so enabling baremetal installation is somewhat outside the standard

Work our division undertakes.  If we can reuse bifrost to do most of the heavy lifting of creating the bifrost container and deploying ironic then

The scope of creating the bifrost container is small enough that I can justify spending some of my time working on it. if it requires

Significant changes to bifrost or rework of kolla’s ironic support then I will have to step back and focus more on feature that are closer aligned to

Our teams core networking and orchestration focus such as enhancing kolla to be able to deploy ovs with dpdk  and/or opendaylight which are

Also items I would like to contribute to this cycle. I don’t want to commit to delivering this feature unless I know I will have the time to work on

It but am happy to help where I can.

 

@kevin some replies to your questions inline.

 

Regards

Sean.

 

 

From: Fox, Kevin M [mailto:Kevin.Fox@pnnl.gov]
Sent: Friday, May 6, 2016 9:17 PM

To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

I was under the impression bifrost was 2 things, one, an installer/configurator of ironic in a stand alone mode, and two, a management tool for getting machines deployed without needing nova using ironic.

[Mooney, Sean K] yes this is correct, bifrost does provide both install playbooks for deploying ironic in standalone mode and a series of playbooks for dynamically enrolling node in ironic and dynamically deploy imanges to host

Without requiring nova. Bifrost also provides intergration with Disk image builder to generate machine images if desired.

The first use case seems like it should just be handled by enhancing kolla's ironic container stuff to directly to handle the use case, doing things the kolla way. This seems much cleaner to me. Doing it at runtime looses most of the benefits of doing it in a container at all.

[Mooney, Sean K] I was not suggestiong doing the installation at runtime. Option 2 and 3   suggested spawning a container as part of the build in which the install playbook would be run.

That container would then be stopped and exported to form the base image for the bifrost continer(s). The base image (bifrost-postinstall)  would either be use to create  a fat containter using an init system such as supervisord to run each of the services

or be used as the base image for a set of bifrost container each of which ran a single component.

The second adds a lot of value I think, and thats what the bifrost container should be?

[Mooney, Sean K]  yes it does and I think it can be reused regarless or how we decide to deploy ironic.

 

Thanks,
Kevin

---

From: Mooney, Sean K [sean.k.mooney@intel.com]
Sent: Friday, May 06, 2016 12:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

 

From: Steven Dake (stdake) [mailto:stdake@cisco.com]
Sent: Friday, May 6, 2016 6:56 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

Sean,

 

Thanks for taking this on :)  I didn't know you had such an AR :)

[Mooney, Sean K] well if other want to do the work that ok with me too but I was planning on deploying bifrost

At home again anyway so I taught I  might as well try to automate the process while im at it.

 

From: "Mooney, Sean K" <sean.k.mooney@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

 

Hi everyone.

 

Following up on my AR from the kolla host repository session

https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo

I started working on creating a kolla bifrost container.

 

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.

In particular the install playbook both installs the ironic dependencies and configure and runs the services.

 

 

What I'd do here is ignore the install playbook and duplicate what it installs.  We don't want to install at run time, we want to install at build time.  You weren't clear if that is what your doing.

[Mooney, Sean K] that is certainly an option but bifrost is an installer for ironic and its supporting service. Not using its installation scripts significantly reduces the value of

Integrating with bifrost vs fixing the existing ironic support in kolla and using that to provision the undercloud.

 

The reason we would ignore the install playbook is because it runs the services.  We need to run the services in a different way.  This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok.  I'd recommend not using systemd, as that will break systemd systems badly.  Instead use a different init system, such as supervisord.

[Mooney, Sean K] if we don’t use the  bifrost install playbook then yes supervisord would be a good choice for the init system.

Looking at the official centos docker image https://hub.docker.com/_/centos/  they do provided instruction for running systemd containers tough I have had issues with this in the past.

 

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the

Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

 

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran

Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

 

 

This leave me with 3 paths forward.

 

1.       I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2.       I can use the kolla build system to build only part of the image

a.        the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b.      After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c.       I can then connect to this running container and run the bifrost install script unmodified.

d.      Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e.      This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

3.       I can  skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

 

4.

Make a supervisord set of init scripts and make the docker file do what it was intended – install the files.  This is kind of a mashup of your 1-3 ideas.  Good thinking :)

 

 

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.

Docker really was not designed to run systemd as part of docker build.

 

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have

Is should I use the kolla build system to make the base image or not.

 

If anyone else has suggestion on how I can progress  please let me know but currently I am leaning towards option 2.

 

 

If you have questions about my suggestion to use supervisord, hit me up on IRC.  Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would.  Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.

[Mooney, Sean K]  I have briefly used supervisord before for a pet project https://github.com/SeanMooney/docker-devstack to create a container for running devstack so it did hot pollute my host.

supervisord  is a nice tool. Im just about to head home for the weekend but I might grab you on irc on Monday to follow up.

 

 

Regards

-steve

 

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

 

GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies.  I'd like to keep that part of Kolla intact :)

[Mooney, Sean K]  yes I would prefer not to break that too. This was basically the option of we don’t actually do the integration and instead just tell

The user how to use bifrost to do the deployment but leave it up to them do decide how to install it. so for me that was plan Z so we have a couple of letter

Go through first.

 

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered

Quite well as part of the bifrost project.

 

Regards

Sean.

 

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Answer 10

From: "Mooney, Sean K" sean.k.mooney@intel.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Monday, May 9, 2016 at 11:03 AM
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi

If we choose to use bifrost to deploy ironic standalone I think combining kevins previous
suggestion of modifying the bifrost install playbook with Steve Dake’s suggestion of creating a series
of supervisord configs for running each of the service is a reasonable approch.

I am currently look to scope how much effort would be required to split the main task in the bifrost-ironic-install role
https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifrost-ironic-install/tasks/main.yml
into 3 files which would be included in the main.yml:
Installcomponets.yml (executed when skipinstall is not defiend)
Bootstrapcomponents.yml (executed when skipbootstrap is not defiend)
Startcomponents.yml (executed when skipstart is not defiend)
By default all three would be executed maintain the current behavior of bifrost today,.

Yes

During the kolla build of the biforst image the https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml would be in
run with skipbootstrap and skipstart defined as true so only Install_componets.yml will be executed by the main task.
This would install all software components of bifrost/ironic without preforming configuration or starting the services.

Yes

At deployment time during the bootstrap phase we would spawn an instance of the biforst-base container and invoke
https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with skipinstall and skipstart defined executing Bootstrap_components.yml

Yes

Bootstrap_components.yml would encapsulate all logic related to creating the ironic db(running migration scripts) and generating the configuration
Files for the biforst components.

Finally in the start phase we have 3 options

a) Spawn an instance of the bifrost-supervisor container and use supervisord to run the bifrost/ironic services (fat container)

b) Spawn an instance of the bifrost-base container and Invoke https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with
skipinstall and skipbootstrap and allow biforst to star the services.(fat container)

c) Spawn a series of containers each running a single service sharing the required volumes to allow them to communicate (app containers)

A is path of least resistance (in a container). I'd highly recommend doing this work in the upstream Bifrost community. C is obviously where we want to be long term, but lets see where we can get to from A. I'd be happy with A in general even if that was the last step we made in the progress of Bifrost & containerization of ironic.

Regards
-steve

I would welcome any input for the bifrost community on this especially related to the decomposition of the main.yml into 3 phases.
Im hoping to do a quick poc this week to see how easy it is to do this decomposition.

I would also like to call out upfront that depending on the scope of this item I may have to withdraw from contributing to it.
I work in intel’s network platforms group so enabling baremetal installation is somewhat outside the standard
Work our division undertakes. If we can reuse bifrost to do most of the heavy lifting of creating the bifrost container and deploying ironic then
The scope of creating the bifrost container is small enough that I can justify spending some of my time working on it. if it requires
Significant changes to bifrost or rework of kolla’s ironic support then I will have to step back and focus more on feature that are closer aligned to
Our teams core networking and orchestration focus such as enhancing kolla to be able to deploy ovs with dpdk and/or opendaylight which are
Also items I would like to contribute to this cycle. I don’t want to commit to delivering this feature unless I know I will have the time to work on
It but am happy to help where I can.

@kevin some replies to your questions inline.

Regards
Sean.

From: Fox, Kevin M [mailto:Kevin.Fox@pnnl.gov]
Sent: Friday, May 6, 2016 9:17 PM
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

I was under the impression bifrost was 2 things, one, an installer/configurator of ironic in a stand alone mode, and two, a management tool for getting machines deployed without needing nova using ironic.
[Mooney, Sean K] yes this is correct, bifrost does provide both install playbooks for deploying ironic in standalone mode and a series of playbooks for dynamically enrolling node in ironic and dynamically deploy imanges to host
Without requiring nova. Bifrost also provides intergration with Disk image builder to generate machine images if desired.

The first use case seems like it should just be handled by enhancing kolla's ironic container stuff to directly to handle the use case, doing things the kolla way. This seems much cleaner to me. Doing it at runtime looses most of the benefits of doing it in a container at all.
[Mooney, Sean K] I was not suggestiong doing the installation at runtime. Option 2 and 3 suggested spawning a container as part of the build in which the install playbook would be run.
That container would then be stopped and exported to form the base image for the bifrost continer(s). The base image (bifrost-postinstall) would either be use to create a fat containter using an init system such as supervisord to run each of the services
or be used as the base image for a set of bifrost container each of which ran a single component.

The second adds a lot of value I think, and thats what the bifrost container should be?
[Mooney, Sean K] yes it does and I think it can be reused regarless or how we decide to deploy ironic.

Thanks,
Kevin

---

From: Mooney, Sean K [sean.k.mooney@intel.com]
Sent: Friday, May 06, 2016 12:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

From: Steven Dake (stdake) [mailto:stdake@cisco.com]
Sent: Friday, May 6, 2016 6:56 PM
To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

Sean,

Thanks for taking this on :) I didn't know you had such an AR :)
[Mooney, Sean K] well if other want to do the work that ok with me too but I was planning on deploying bifrost
At home again anyway so I taught I might as well try to automate the process while im at it.

From: "Mooney, Sean K" sean.k.mooney@intel.com
Reply-To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi everyone.

Following up on my AR from the kolla host repository session
https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo
I started working on creating a kolla bifrost container.

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.
In particular the install playbook both installs the ironic dependencies and configure and runs the services.

What I'd do here is ignore the install playbook and duplicate what it installs. We don't want to install at run time, we want to install at build time. You weren't clear if that is what your doing.
[Mooney, Sean K] that is certainly an option but bifrost is an installer for ironic and its supporting service. Not using its installation scripts significantly reduces the value of
Integrating with bifrost vs fixing the existing ironic support in kolla and using that to provision the undercloud.

The reason we would ignore the install playbook is because it runs the services. We need to run the services in a different way. This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok. I'd recommend not using systemd, as that will break systemd systems badly. Instead use a different init system, such as supervisord.
[Mooney, Sean K] if we don’t use the bifrost install playbook then yes supervisord would be a good choice for the init system.
Looking at the official centos docker image https://hub.docker.com/_/centos/ they do provided instruction for running systemd containers tough I have had issues with this in the past.

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the
Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran
Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

This leave me with 3 paths forward.

1. I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2. I can use the kolla build system to build only part of the image

a. the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b. After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c. I can then connect to this running container and run the bifrost install script unmodified.

d. Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e. This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

1. I can skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

4.
Make a supervisord set of init scripts and make the docker file do what it was intended – install the files. This is kind of a mashup of your 1-3 ideas. Good thinking :)

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.
Docker really was not designed to run systemd as part of docker build.

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have
Is should I use the kolla build system to make the base image or not.

If anyone else has suggestion on how I can progress please let me know but currently I am leaning towards option 2.

If you have questions about my suggestion to use supervisord, hit me up on IRC. Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would. Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.
[Mooney, Sean K] I have briefly used supervisord before for a pet project https://github.com/SeanMooney/docker-devstack to create a container for running devstack so it did hot pollute my host.
supervisord is a nice tool. Im just about to head home for the weekend but I might grab you on irc on Monday to follow up.

Regards
-steve

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies. I'd like to keep that part of Kolla intact :)
[Mooney, Sean K] yes I would prefer not to break that too. This was basically the option of we don’t actually do the integration and instead just tell
The user how to use bifrost to do the deployment but leave it up to them do decide how to install it. so for me that was plan Z so we have a couple of letter
Go through first.

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered
Quite well as part of the bifrost project.

Regards
Sean.

---

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

From: "Mooney, Sean K" <sean.k.mooney@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: Monday, May 9, 2016 at 11:03 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

Hi

 

If we choose to use bifrost to deploy ironic standalone I think combining kevins previous

suggestion of modifying the bifrost install playbook with Steve Dake’s suggestion of creating a series

of supervisord configs for running each of the service is a reasonable approch.

 

I am currently look to scope how much effort would be required to split  the main task in the bifrost-ironic-install role

https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifrost-ironic-install/tasks/main.yml

into 3 files which would be included in the main.yml:

Install_componets.yml (executed when skip_install is not defiend)

Bootstrap_components.yml (executed when skip_bootstrap is not defiend)

Start_components.yml  (executed when skip_start is not defiend)

By default all three would be executed maintain the current behavior of bifrost today,.

 

Yes

During the kolla build of the biforst image the https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml would be in

run with skip_bootstrap and skip_start defined as true so only Install_componets.yml will be executed by the main task.

This would install all software components of bifrost/ironic without preforming configuration or starting the services.

Yes

 

At deployment time during the bootstrap phase we would spawn an instance of the biforst-base container and invoke

https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with skip_install and skip_start defined executing Bootstrap_components.yml

Yes

 

Bootstrap_components.yml would encapsulate all logic related to creating the ironic db(running migration scripts) and generating the configuration

Files for the biforst components.

 

Finally in the start phase we have 3 options

a)      Spawn an instance of the bifrost-supervisor container and use supervisord to run the bifrost/ironic services (fat container)

b)      Spawn an instance of the bifrost-base container and Invoke https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with
skip_install and skip_bootstrap and allow biforst to star the services.(fat container)

c)       Spawn a series of containers each running a single service sharing the required volumes to allow them  to communicate (app containers)

A is path of least resistance (in a container).  I'd highly recommend doing this work in the upstream Bifrost community.  C is obviously where we want to be long term, but lets see where we can get to from A.  I'd be happy with A in general even if that was the last step we made in the progress of Bifrost & containerization of ironic.

Regards

-steve

 

 

I would welcome any input for the bifrost community on this especially related to the decomposition of the main.yml into 3 phases.

Im hoping to do a quick poc this week to see how easy it is to do this decomposition.

 

I would also like to call out upfront that depending on the scope of this item I may have to withdraw from contributing to it.

I work in intel’s network platforms group so enabling baremetal installation is somewhat outside the standard

Work our division undertakes.  If we can reuse bifrost to do most of the heavy lifting of creating the bifrost container and deploying ironic then

The scope of creating the bifrost container is small enough that I can justify spending some of my time working on it. if it requires

Significant changes to bifrost or rework of kolla’s ironic support then I will have to step back and focus more on feature that are closer aligned to

Our teams core networking and orchestration focus such as enhancing kolla to be able to deploy ovs with dpdk  and/or opendaylight which are

Also items I would like to contribute to this cycle. I don’t want to commit to delivering this feature unless I know I will have the time to work on

It but am happy to help where I can.

 

@kevin some replies to your questions inline.

 

Regards

Sean.

 

 

From: Fox, Kevin M [mailto:Kevin.Fox@pnnl.gov]
Sent: Friday, May 6, 2016 9:17 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

I was under the impression bifrost was 2 things, one, an installer/configurator of ironic in a stand alone mode, and two, a management tool for getting machines deployed without needing nova using ironic.

[Mooney, Sean K] yes this is correct, bifrost does provide both install playbooks for deploying ironic in standalone mode and a series of playbooks for dynamically enrolling node in ironic and dynamically deploy imanges to host

Without requiring nova. Bifrost also provides intergration with Disk image builder to generate machine images if desired.

The first use case seems like it should just be handled by enhancing kolla's ironic container stuff to directly to handle the use case, doing things the kolla way. This seems much cleaner to me. Doing it at runtime looses most of the benefits of doing it in a container at all.

[Mooney, Sean K] I was not suggestiong doing the installation at runtime. Option 2 and 3   suggested spawning a container as part of the build in which the install playbook would be run.

That container would then be stopped and exported to form the base image for the bifrost continer(s). The base image (bifrost-postinstall)  would either be use to create  a fat containter using an init system such as supervisord to run each of the services

or be used as the base image for a set of bifrost container each of which ran a single component.

The second adds a lot of value I think, and thats what the bifrost container should be?

[Mooney, Sean K]  yes it does and I think it can be reused regarless or how we decide to deploy ironic.

 

Thanks,
Kevin

---

From: Mooney, Sean K [sean.k.mooney@intel.com]
Sent: Friday, May 06, 2016 12:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

 

From: Steven Dake (stdake) [mailto:stdake@cisco.com]
Sent: Friday, May 6, 2016 6:56 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

 

Sean,

 

Thanks for taking this on :)  I didn't know you had such an AR :)

[Mooney, Sean K] well if other want to do the work that ok with me too but I was planning on deploying bifrost

At home again anyway so I taught I  might as well try to automate the process while im at it.

 

From: "Mooney, Sean K" <sean.k.mooney@intel.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Date: Friday, May 6, 2016 at 10:14 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [kolla] [bifrost] bifrost container.

 

Hi everyone.

 

Following up on my AR from the kolla host repository session

https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kolla-host-repo

I started working on creating a kolla bifrost container.

 

Are some initial success it have hit a roadblock with the current install playbook provided by bifrost.

In particular the install playbook both installs the ironic dependencies and configure and runs the services.

 

 

What I'd do here is ignore the install playbook and duplicate what it installs.  We don't want to install at run time, we want to install at build time.  You weren't clear if that is what your doing.

[Mooney, Sean K] that is certainly an option but bifrost is an installer for ironic and its supporting service. Not using its installation scripts significantly reduces the value of

Integrating with bifrost vs fixing the existing ironic support in kolla and using that to provision the undercloud.

 

The reason we would ignore the install playbook is because it runs the services.  We need to run the services in a different way.  This will (as we discussed at ODS) be a fat container on the underlord cloud – which I guess is ok.  I'd recommend not using systemd, as that will break systemd systems badly.  Instead use a different init system, such as supervisord.

[Mooney, Sean K] if we don’t use the  bifrost install playbook then yes supervisord would be a good choice for the init system.

Looking at the official centos docker image https://hub.docker.com/_/centos/  they do provided instruction for running systemd containers tough I have had issues with this in the past.

 

The installation of ironic and its dependencies would not be a problem but the ansible service module is not cable able of starting the

Infrastructure services (mysql,rabbit …) without a running init system which is not present during the docker build.

 

When I created a biforst container in the past is spawned a Ubuntu upstart container then docker exec into the container and ran

Bifrost install script. This works because the init system is running and the service module could test and start the relevant services.

 

 

This leave me with 3 paths forward.

 

1.       I can continue to try and make the bifrost install script work with the kolla build system by using sed to modify the install playbook or try start systemd during the docker build.

2.       I can use the kolla build system to build only part of the image

a.        the bifrost-base image would be build with the kolla build system without running the bifrost playbook. This
would allow the existing allow the existing features of the build system such as adding headers/footers to be used.

b.      After the base image is built by kolla I can spawn an instance of bifrost-base with systemd running

c.       I can then connect to this running container and run the bifrost install script unmodified.

d.      Once it is finished I can stop the container and export it to an image “bifros-postinstall”.

e.      This can either be used directly (fat container) or as the base image for other container that run each of the ironic services (thin containers)

3.       I can  skip the kolla build system entirely and create a script/playbook that will build the bifrost container similar to 2.

 

4.

Make a supervisord set of init scripts and make the docker file do what it was intended – install the files.  This is kind of a mashup of your 1-3 ideas.  Good thinking :)

 

 

While option 1 would fully use the kolla build system It is my least favorite as it is both hacky and complicated to make work.

Docker really was not designed to run systemd as part of docker build.

 

For option 2 and 3 I can provide a single playbook/script that will fully automate the build but the real question I have

Is should I use the kolla build system to make the base image or not.

 

If anyone else has suggestion on how I can progress  please let me know but currently I am leaning towards option 2.

 

 

If you have questions about my suggestion to use supervisord, hit me up on IRC.  Ideally we would also contribute these init scripts back into bifrost code base assuming they want them, which I think they would.  Nobody will run systemd in a container, and we all have an interest in seeing BiFrost as the standard bare metal deployment model inside or outside of containers.

[Mooney, Sean K]  I have briefly used supervisord before for a pet project https://github.com/SeanMooney/docker-devstack to create a container for running devstack so it did hot pollute my host.

supervisord  is a nice tool. Im just about to head home for the weekend but I might grab you on irc on Monday to follow up.

 

 

Regards

-steve

 

The only other option I see would be to not use a container and either install biforst on the host or in a vm.

 

GROAN – one advantage containers provide us is not mucking up the host OS with a bajillion dependencies.  I'd like to keep that part of Kolla intact :)

[Mooney, Sean K]  yes I would prefer not to break that too. This was basically the option of we don’t actually do the integration and instead just tell

The user how to use bifrost to do the deployment but leave it up to them do decide how to install it. so for me that was plan Z so we have a couple of letter

Go through first.

 

These would essentially be a no op for kolla as we would simply have to document how to install bifrost which is covered

Quite well as part of the bifrost project.

 

Regards

Sean.