[openstack-dev] [Infra] Use of heat for CI of OpenStack
harlowja at outlook.com
Fri Apr 3 18:18:29 UTC 2015
Sean Dague wrote:
> 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:
>>> 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.
Sure, and I think that's great and is the right thing to do, but there
are various levels of eating our own dogfood and it'd be nice to do that
where appropriate. I know there is history here that I don't know about
but the future is unwritten and it might be worthwhile to think about
these kinds of things instead of just 'doing what we have always done,
just because it has always been done'...
More information about the OpenStack-dev