[openstack-dev] [Infra] Use of heat for CI of OpenStack

Sean Dague sean at dague.net
Fri Apr 3 17:35:32 UTC 2015

On 04/03/2015 01:08 PM, Joshua Harlow wrote:
> Monty Taylor wrote:
>> On 04/03/2015 08:55 AM, Maish Saidel-Keesing wrote:
>>> I was wondering..
>>> Is the OpenStack CI/CD Infra using Heat in any way? Do the commits
>>> trigger a new build of DevStack/OpenStack that is based on a Heat
>>> Template or just the provisioning of a regular instance and then
>>> deployment of code on top of that?
>> Nope - we do not use heat - we use a program called nodepool:
>> http://git.openstack.org/cgit/openstack-infra/nodepool/
>> Which uses the nova api to provision servers. These servers are
>> currently registered as jenkins slaves so that the workload run on them
>> is defined a s jenkins job.
>> There are a few reasons we do not use heat for this - none of them I
>> think of as negative against heat:
>> - Our pool spans 4 regions of 2 public clouds. Heat runs in a cloud, the
>> positioning is wrong
>> - Our pool is predominantly single-machines that are used once - which
>> means a heat template would add extra complexity for not much gain.
>> - Our current system predates the existence of heat. It is also highly
>> specific to the task at hand - namely, ensuring that there are always
>> test nodes available.
> Can these things be fixed? Heat afaik isn't a frozen piece of sofware...
> It would be pretty neat to use the projects that we have that others are
> using if we could. Might be an interesting summit topic/idea?

Honestly, I find it more neat that nodepool is a good example
application of consuming the Nova API to build a custom workflow. I
think assuming that the moment you do things with more than 1 machine
you should be using Heat kind of misses the point of Nova having it's
own API.

We should be encouraging more applications out in the wild to use our
APIs at all kinds of levels.


Sean Dague

More information about the OpenStack-dev mailing list