Open Stack

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.

> 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.

>> 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!

> Anyway, It should be relatively easy to take the Heat provider templates
> from TripleO and deploy them into a cloud in the same way you should
> have no trouble deploying os-ansible-deployment into a cloud. Whatever
> assumptions about real hardware are made will need to be addressed, but
> ultimately 99% of what is called "advanced services" is just services
> running regular binaries speaking regular protocols storing things on
> regular filesystems.

-Christopher