Open Stack

Excerpts from Christopher Aedo's message of 2015-07-26 14:52:31 -0700:
> On Sun, Jul 26, 2015 at 10:53 AM, Clint Byrum <clint at fewbar.com> wrote:
> > Excerpts from Christopher Aedo's message of 2015-07-25 19:35:24 -0700:
> >> My understanding of TripleO
> >> is that the entire model is tightly coupled such that you must take an
> >> all or nothing approach (i.e. you can not use one deployment method
> >> for your cloud, and then use TripleO to deploy other components of
> >> your cloud later on).  I would be happy to hear my understanding is
> >> wrong in this case though.
> >>
> >
> > I can understand why it might have seemed that way because we were
> > driving at producing something production-like that ran in the gate,
> > but you actually heard wrong. The entire thing is intended to be modular
> > and one of the reasons to use OpenStack to deploy OpenStack is so that
> > you can easily move components into the cloud. Any tight coupling is an
> > accident and is likely only there because at this point there is only
> > one implementation receiving much attention (the puppet one).
> 
> That's great and I'm glad to be corrected.  If what I said was not
> completely clear, I was under the impression that if you did not start
> with "OpenStack on OpenStack", you would have trouble using the OoO
> Heat templates in a cloud deployed differently (Juju, Fuel, or Puppet
> for instance).  Sounds to me like you are saying you do not need to
> start from TripleO to make use of the TripleO templates.
> 

I think this is sometimes how we end up thinking about OpenStack because
so many are doing it as a single org with homogeneous tooling because
thats how things are done in many orgs, and certainly thats how products
do things.

But I'm certain there are clouds where each service is its own island,
and that's a good thing. Hang your API shingle out in the Keystone
catalog. Who cares how you're deployed, right?

> > Mixing and matching chef and puppet on a single box doesn't work, because
> > they both make assumptions about what they own. But you can quite easily
> > have two services managed by two separate sets of tools.
> 
> Yes, I should have been more clear here, I'm taking Kevin's original
> question as "can we use the heat templates to deploy additional
> services in an already-deployed cloud".  My chef vs. puppet example
> muddied things - I was really trying to highlight a situation where
> you're using one of those tools to deploy and manage a service (say
> your message queue), and that if you've done that with one service you
> will have great difficulty trying to update/modify that service with a
> different tool if it's still actively managing it.
> 

Understood.

> >> I would love to see some way for the App Catalog to allow OpenStack
> >> users or operators add additional services easily though, and I'm
> >> excited to see this floated here.  It's possible at least to do this
> >> with Rally via Murano[2] but that assumes the environment has included
> >> Murano and also has a Heat environment that includes everything needed
> >> by the resulting template.  As many have seen, it's not necessarily
> >> easy for users to know in advance whether this will work (another good
> >> thread, unfortunately with an unsatisfactory resolution).
> >>
> >> Hopefully we'll see some great responses here on how we can solve some
> >> of this together!
> >>
> >
> > This is blowing my mind a little, because I've always been told that
> > Rally is a performance measuring tool. :-P I guess I should read up on
> > it because it sounds like it is also a packaging or deployment tool?
> 
> I think you misunderstood me :)  I was using "deploy Rally via Murano"
> as an example of deploying a service (Rally) that was not originally
> deployed with the cloud.  It sounds like the Heat templates could be
> used in the same way, that's great!
>

Indeed, that did confuse me. Thanks. :)