settingsLogin | Registersettings

[openstack-dev] [tripleo][infra][deployment] Adding multinode CI jobs for TripleO in nodepool

0 votes

I've been working on various patches to TripleO to make it possible
for the baremetal provisioning part of the workflow to be optional. In
such a scenario, TripleO wouldn't use Nova or Ironic to boot any
baremetal nodes. Instead it would rely on the nodes to be already
installed with an OS and powered on. We then use Heat to drive the
deployment of OpenStack on those nodes...that part of the process is
largely unchanged.

One of the things this would allow TripleO to do is make use of CI
jobs using nodes just from the regular cloud providers in nodepool
instead of having to use our own TripleO cloud
(tripleo-test-cloud-rh1) to run all our jobs.

I'm at a point where I can start working on patches to try and set
this up, but I wanted to provide this context so folks were aware of
the background.

We'd probably start with our simplest configuration of a job with at
least 3 nodes (undercloud/controller/compute), and using CentOS
images. It looks like right now all multinode jobs are 2 nodes only
and use Ubuntu. My hope is that I/we can make some progress in
different multinode configurations and collaborate on any setup
scripts or ansible playbooks in a generally useful way. I know there
was interest in different multinode setups from the various deployment
teams at the cross project session in Austin.

If there are any pitfalls or if there are any concerns about TripleO
going in this direction, I thought we could discuss those here. Thanks
for any feedback.

--
-- James Slagle
--


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
asked May 27, 2016 in openstack-dev by James_Slagle (7,000 points)   1 3 4
retagged Jan 25, 2017 by admin

5 Responses

0 votes

On Fri, May 27, 2016 at 2:03 PM, James Slagle james.slagle@gmail.com wrote:
I've been working on various patches to TripleO to make it possible
for the baremetal provisioning part of the workflow to be optional. In
such a scenario, TripleO wouldn't use Nova or Ironic to boot any
baremetal nodes. Instead it would rely on the nodes to be already
installed with an OS and powered on. We then use Heat to drive the
deployment of OpenStack on those nodes...that part of the process is
largely unchanged.

One of the things this would allow TripleO to do is make use of CI
jobs using nodes just from the regular cloud providers in nodepool
instead of having to use our own TripleO cloud
(tripleo-test-cloud-rh1) to run all our jobs.

I'm at a point where I can start working on patches to try and set
this up, but I wanted to provide this context so folks were aware of
the background.

We'd probably start with our simplest configuration of a job with at
least 3 nodes (undercloud/controller/compute), and using CentOS
images. It looks like right now all multinode jobs are 2 nodes only
and use Ubuntu. My hope is that I/we can make some progress in
different multinode configurations and collaborate on any setup
scripts or ansible playbooks in a generally useful way. I know there
was interest in different multinode setups from the various deployment
teams at the cross project session in Austin.

If there are any pitfalls or if there are any concerns about TripleO
going in this direction, I thought we could discuss those here. Thanks
for any feedback.

It is more a question than a concern:
are we still going to test baremetal introspection with Ironic
somewhere in OpenStack?

I like the way it goes but I'm wondering if the things that we're not
going to test anymore will still be tested somewhere else (maybe in
Ironic / Nova CI jobs) or maybe it's already the case and then stop me
here.

--
-- James Slagle
--

--
Emilien Macchi


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
responded May 27, 2016 by emilien_at_redhat.co (36,940 points)   3 8 13
0 votes

On Fri, May 27, 2016 at 2:37 PM, Emilien Macchi emilien@redhat.com wrote:
On Fri, May 27, 2016 at 2:03 PM, James Slagle james.slagle@gmail.com wrote:

I've been working on various patches to TripleO to make it possible
for the baremetal provisioning part of the workflow to be optional. In
such a scenario, TripleO wouldn't use Nova or Ironic to boot any
baremetal nodes. Instead it would rely on the nodes to be already
installed with an OS and powered on. We then use Heat to drive the
deployment of OpenStack on those nodes...that part of the process is
largely unchanged.

One of the things this would allow TripleO to do is make use of CI
jobs using nodes just from the regular cloud providers in nodepool
instead of having to use our own TripleO cloud
(tripleo-test-cloud-rh1) to run all our jobs.

I'm at a point where I can start working on patches to try and set
this up, but I wanted to provide this context so folks were aware of
the background.

We'd probably start with our simplest configuration of a job with at
least 3 nodes (undercloud/controller/compute), and using CentOS
images. It looks like right now all multinode jobs are 2 nodes only
and use Ubuntu. My hope is that I/we can make some progress in
different multinode configurations and collaborate on any setup
scripts or ansible playbooks in a generally useful way. I know there
was interest in different multinode setups from the various deployment
teams at the cross project session in Austin.

If there are any pitfalls or if there are any concerns about TripleO
going in this direction, I thought we could discuss those here. Thanks
for any feedback.

It is more a question than a concern:
are we still going to test baremetal introspection with Ironic
somewhere in OpenStack?

I like the way it goes but I'm wondering if the things that we're not
going to test anymore will still be tested somewhere else (maybe in
Ironic / Nova CI jobs) or maybe it's already the case and then stop me
here.

I should have clarified: we're not moving away from still having our
own cloud running the TripleO jobs we have today.

This is about adding new jobs to test a different way of deploying via
TripleO Since we'd be able to use nodepool nodes directly to do that,
I'm proposing to do it that way.

If it pans out, I'd expect us to have a variety of jobs running with
different permutations so that we can have as much coverage as
possible.

--
-- James Slagle
--


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
responded May 27, 2016 by James_Slagle (7,000 points)   1 3 4
0 votes

On Fri, May 27, 2016 at 3:08 PM, James Slagle james.slagle@gmail.com wrote:
On Fri, May 27, 2016 at 2:37 PM, Emilien Macchi emilien@redhat.com wrote:

On Fri, May 27, 2016 at 2:03 PM, James Slagle james.slagle@gmail.com wrote:

I've been working on various patches to TripleO to make it possible
for the baremetal provisioning part of the workflow to be optional. In
such a scenario, TripleO wouldn't use Nova or Ironic to boot any
baremetal nodes. Instead it would rely on the nodes to be already
installed with an OS and powered on. We then use Heat to drive the
deployment of OpenStack on those nodes...that part of the process is
largely unchanged.

One of the things this would allow TripleO to do is make use of CI
jobs using nodes just from the regular cloud providers in nodepool
instead of having to use our own TripleO cloud
(tripleo-test-cloud-rh1) to run all our jobs.

I'm at a point where I can start working on patches to try and set
this up, but I wanted to provide this context so folks were aware of
the background.

We'd probably start with our simplest configuration of a job with at
least 3 nodes (undercloud/controller/compute), and using CentOS
images. It looks like right now all multinode jobs are 2 nodes only
and use Ubuntu. My hope is that I/we can make some progress in
different multinode configurations and collaborate on any setup
scripts or ansible playbooks in a generally useful way. I know there
was interest in different multinode setups from the various deployment
teams at the cross project session in Austin.

If there are any pitfalls or if there are any concerns about TripleO
going in this direction, I thought we could discuss those here. Thanks
for any feedback.

It is more a question than a concern:
are we still going to test baremetal introspection with Ironic
somewhere in OpenStack?

I like the way it goes but I'm wondering if the things that we're not
going to test anymore will still be tested somewhere else (maybe in
Ironic / Nova CI jobs) or maybe it's already the case and then stop me
here.

I should have clarified: we're not moving away from still having our
own cloud running the TripleO jobs we have today.

Thanks for this clarification!

This is about adding new jobs to test a different way of deploying via
TripleO Since we'd be able to use nodepool nodes directly to do that,
I'm proposing to do it that way.

If it pans out, I'd expect us to have a variety of jobs running with
different permutations so that we can have as much coverage as
possible.

I like it, I see different use-cases where we don't need to test
baremetal provisioning. One of them is openstack/puppet-* testing
(except for puppet-nova and puppet-ironic maybe) where we just want to
run puppet on a undercloud / overcloud and see if services are
working. With the new jobs, I would propose to think at removing old
jobs and use new multi-node jobs, it will help us to save time,
resources and test what we actually need to test.
--
Emilien Macchi


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
responded May 27, 2016 by emilien_at_redhat.co (36,940 points)   3 8 13
0 votes

On 28/05/16 06:03, James Slagle wrote:
I've been working on various patches to TripleO to make it possible
for the baremetal provisioning part of the workflow to be optional. In
such a scenario, TripleO wouldn't use Nova or Ironic to boot any
baremetal nodes. Instead it would rely on the nodes to be already
installed with an OS and powered on. We then use Heat to drive the
deployment of OpenStack on those nodes...that part of the process is
largely unchanged.

One of the things this would allow TripleO to do is make use of CI
jobs using nodes just from the regular cloud providers in nodepool
instead of having to use our own TripleO cloud
(tripleo-test-cloud-rh1) to run all our jobs.

I'm at a point where I can start working on patches to try and set
this up, but I wanted to provide this context so folks were aware of
the background.

We'd probably start with our simplest configuration of a job with at
least 3 nodes (undercloud/controller/compute), and using CentOS
images. It looks like right now all multinode jobs are 2 nodes only
and use Ubuntu. My hope is that I/we can make some progress in
different multinode configurations and collaborate on any setup
scripts or ansible playbooks in a generally useful way. I know there
was interest in different multinode setups from the various deployment
teams at the cross project session in Austin.

If there are any pitfalls or if there are any concerns about TripleO
going in this direction, I thought we could discuss those here. Thanks
for any feedback.

This raises the possibility of an alternative to OVB for
trying/developing TripleO on a host cloud.

If a vm version of the overcloud-full image is also generated then the
host cloud can boot these directly. The approach above can then be used
to treat these nodes as pre-existing nodes to adopt.

I did this for a while configuring the undercloud nova to use the fake
virt driver, but it sounds like the approach above doesn't interact with
nova at all.

So I'm +1 on this approach for some development environments too. Can
you provide a list of the changes?


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
responded May 30, 2016 by Steve_Baker (7,380 points)   1 3 7
0 votes

On Mon, May 30, 2016 at 6:12 PM, Steve Baker sbaker@redhat.com wrote:
This raises the possibility of an alternative to OVB for trying/developing
TripleO on a host cloud.

If a vm version of the overcloud-full image is also generated then the host
cloud can boot these directly. The approach above can then be used to treat
these nodes as pre-existing nodes to adopt.

I did this for a while configuring the undercloud nova to use the fake virt
driver, but it sounds like the approach above doesn't interact with nova at
all.

Correct, the nodes could come from anywhere. They could be prelaunched
instances on an OpenStack cloud, or any cloud for that matter. I in
fact tested this out on the Rackspace public cloud by just launching 3
vanilla Centos instances, installed an undercloud on one, and then
used the other 2 for the overcloud.

So I'm +1 on this approach for some development environments too. Can you
provide a list of the changes?

This is the primary patch to tripleo-heat-templates that enables it to work:
https://review.openstack.org/#/c/222772/

And a couple of other patches on the same topic branch:
https://review.openstack.org/#/q/topic:deployed-server

--
-- James Slagle
--


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
responded May 31, 2016 by James_Slagle (7,000 points)   1 3 4
...