On 06/04/2014 12:09 AM, Jaroslav Kortus wrote:
On 06/03/2014 01:25 AM, Dan Callaghan wrote:
> In the long run, standardising on OpenStack-compatible APIs (rather than
> EC2-compatible ones) might make more sense as there are more and more
> public/private/hybrid cloud offerings popping up based on OpenStack.
> I like that idea much better than being limited to whatever features
> Amazon feels like offering.
>
My idea was more like using openstack through deltacloud api (i.e.
something more universal). Definitely not recommending standardizing on
non-open platform or any Amazon API.
The point was that anyone could take beaker and point it to any other
cloud simply through the same API and deal with the problems. We (as Red
Hat) would still be focused on beaker+openstack only.
Does this sound better? :)
The problem/concern I have with abstraction layers like DeltaCloud is
that they tend to be "subset APIs" - they only expose things all the
clouds can do. With Beaker's dynamic VM support, we want to offer all
the niceties Beaker users are used to (especially console log recording
and monitoring to help diagnose provisioning and kernel level issues
that prevent normal network based access to the test VMs). To do that
via DeltaCloud, we'd have to learn both OpenStack's native capabilities
in that area (to make sure it is supported at all), *and* DeltaCloud's
abstraction layer for it (to figure out how to talk to it via
DeltaCloud). If we encounter problems, we'd have to investigate both the
OpenStack backend and the DeltaCloud shim in addition to our own code,
and we'd be unable to offer the feature in Beaker if DeltaCloud didn't
support it, even if it was available in OpenStack itself.
By starting specifically with OpenStack support, it takes the entire
DeltaCloud layer out of the equation: we only have to learn OpenStack,
and if OpenStack can do something we want, we can offer it as a feature
of the integration. We can also document the end-to-end configuration
settings needed to make the feature work properly in combination with
OpenStack (again, console logs are a case where if you configure your
OpenStack instance incorrectly, Beaker won't be able to record and
monitor them - as noted in my original email, there are also currently
several caveats around SSH access depending on how the networking is
configured). This gets us the functionality we're after (dynamic
provisioning in our existing internal cloud infrastructure) as quickly
and as simply as possible.
By contrast, starting with DeltaCloud would mean making the integration
task more complicated, to provide flexibility we don't currently need
(as the dynamic VM infrastructure we want to talk to specifically uses
OpenStack). The point where I see supporting DeltaCloud in addition to
direct integration with OpenStack potentially making sense is if we were
considering adding support for a *second* cloud backend (like EC2) - at
that stage, we could just offer both "OpenStack based dynamic VMs" and
"DeltaCloud based dynamic VMs", rather than building our own abstraction
layer over multiple cloud types. But using DeltaCloud up front would
violate the principle of "Do the simplest thing that could possibly
work" and likely result in unnecessary delays in providing an initial
implementation of the dynamic VM feature.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
Testing Solutions Team Lead