Open Stack

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?

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