On 10/24/2012 11:36 AM, Hugh Brock wrote:
On Wed, Oct 24, 2012 at 10:43:53AM -0400, Matt Wagner wrote:
On Wed, Oct 24, 2012 at 01:29:18PM +0100, Angus Thomas wrote:
<snip>
I'm approaching this from the perspective of a member of the Aeolus
community. Because of my job, though, I'm in a position to talk
directly to product managers etc. associated with Cloud Engine, and
to move to an agreement. To that end, Hugh and I have already met
with the Cloud Engine product managers, persuaded them, if it was
necessary, that the disadvantages of the current situation are such
that we should all seek to resolve it, and established what their
position is on each of the current set of terms.
[useful content snipped, apols]
Cloud – “Environment” is difficult because that term already has a
specific meaning in Katello, which is different to the way that we're
currently using it. A Katello environment is essentially a set of
repositories of content. That doesn't map directly onto what we're
calling environments and, given the fact that Katello and Aeolus are
complimentary applications, we should avoid a concept/name collision.
From the point of view of users, Aeolus makes cloud resources
available. This is an encapsulation of those resources, hence Cloud.
Also, this is the term, they tell me, which is employed by other
widely used cloud infrastructure management applications, so it is
the term that a lot of potential users understand. Using it will make
adoption simpler.
I want to be careful here, because I don't really know how our
real-world users think, and my thinking may be very different than
theirs.
We have to change _something_, because we call this an Environment, the
code still calls it a Pool Family, and downstream calls it a Cloud.
My problem with "Cloud" is... Well, actually, I have several.
One is that "cloud" is already overloaded and over-hyped. It's like
calling things "green" -- it's gotten to the point where it really has
no meaning. MS Office markets itself as being part of the cloud, for
example. I have no clue what that even means. So we're adding this
overused, ambiguous buzzword and expecting people take us seriously.
Another problem is that, within a narrower niche of tech-savvy
sysadmins, "cloud" _does_ have a clearer meaning. It's cloud providers,
like EC2 or Rackspace, or internal private "clouds". But that's now how
we are using it, _even though we have that concept in our app_. We are
instead using it to refer to a smaller grouping of things. So in
CloudForms Cloud Engine, you can have Clouds that don't map up to the
clouds you are using. How does that even make sense?
So we are hijacking an overused term, and not even using it in its
sometimes-understood meaning. Personally, as a technical person, I would
have a hard time taking seriously a product that misused the word
"cloud" -- particularly one that was actually supposed to manage cloud
resources.
As for the fact that everyone else abuses the word "cloud" -- as my
mother used to say: if all your friends jumped off a bridge, would you?
With or without a bungee cord attached?
OK, I'm going to try to mount a defense of "Cloud" here on the
merits. Wish me luck.
I'm sorry to have to admit it, but using "Cloud" for what we currenly
call "Pool Family" or "Environment" was actually my idea. So was Pool
Family, to be fair. The reason I had the idea at the time, and the
reasons I *still* think it fits, are as follows:
* Conductor, properly imagined, has a single primary mission, which is
to provide administrators with a way to merge or synthesize provider
clouds -- an EC2 account, a private RHEV instance, a private vSphere
instance -- into a single entity.
(leave aside the fact that right now Conductor does a whole bunch of
other stuff, we need to fix that and it shouldn't enter into this
discussion)
* If we all do our jobs properly, the merged entity, with the various
providers added and obscured by the Conductor mechanisms that serve
that purpose, should be indistinguishable to an end-user from a
compute cloud. In other words, I should be able to connect to
Conductor and launch a thing in a Conductor Cloud, and that operation
should be *not even a little bit different* from connecting to EC2 and
launching that same thing.
* The only difference between such a merged entity and an Amazon cloud
or an OpenStack cloud, is that you don't know in advance which
provider cloud your instance is eventually going to wind up on. In my
view though *this is precisely what a cloud is*. You don't know which
rack or which machine in the us-east data center your instance is
going to be on, and you don't *need* to know. If you do need to know
whether your instance is running on EC2 or vSphere, then we're not
doing our jobs right.
So, that's the rationale. Please feel free to tell me I'm all wet, and I
would welcome alternate suggestions for the name for this thing. If you
disagree with my understanding of the primary mission of Conductor, that
is also a discussion worth having, but by all means let's have it now so
we can settle it :).
Take care,
--Hugh
So in a way I'm less opposed to this than I was originally. I'm still
concerned that the term 'cloud' alone might be confusing. Especially
since, when at one point we were deciding how we'd map all this stuff to
deltacloud, at the time we thought that pools/zones were the thing that
mapped to a "front end" provider.
How about "Cloud environment" -- it seems to encapsulate most of what
we're saying is good about 'cloud' -- but with the additional notion
that these cloud environments differ in how they attach to physical
clouds, their intended purpose (i.e. what images are available), etc.
Especially since our intended use of the PoolFamily/Environment/Cloud
concept was for things like separating "development" from "production", etc.
Scott
