Open Stack

On 18/09/13 19:44, Robert Collins wrote:
> On 18 September 2013 20:59, marios at redhat.com <mandreou at redhat.com> wrote:
>> I have an AI from the tuskar community meeting to come up with a
>> description of how TripleO 'differs from' Tuskar. I have no idea where
>> this will be used/placed and in fact I don't know where to send it:
>> should we paste it into the naming etherpad, open a launchpad docs
>> blueprint (seems a bit much, especially as I don't know which doc it's
>> going into). Alternatively please feel free to change and use as you see
>> fit wherever:
>>
>>
>> "
>>
>>  How does tuskar fit in with TripleO?
>>
>>
>> TripleO [1] is a blanket term for a number of subprojects - but the
> 
> Huh? TripleO is the OpenStack Deployment project codename: we're a
> program focused on production deployment of OpenStack at scale. The
> fact we have a number of specific projects to facilitate that is just
> good engineering, exactly the same as nova having the server API and
> client in different projects.

indeed ^^^ and this is how I intended it - the same way that 'nova' is a
collection of related but distinct services (compute, scheduler, api,
message bus/broker, etc) - tbh that's the first time I've seen
'OpenStack Deployment project' so my apologies for not using that

> 
> What you've written below is correct, but it's implementation detail :)
> 
> 
>> Tuskar [2] is actually a perfect fit for TripleO and entirely depends on
>> the TripleO concept and services to do all of the heavy lifting.
>> Actually, Tuskar may in part be defined as a *design* tool. With Tuskar,
>> you get a UI and API with which you can tell the undercloud
>> nova-baremetal service exactly which OpenStack services (i.e. baremetal
>> images) to deploy onto which machines in the datacenter. The UI
>> integrates into the default OpenStack Horizon dashboard and allows you
>> to define your datacenter in terms of Racks (groups of physical machines
>> registered by id/mac_address) and ResourceClasses (groups of Racks that
>> all provide the same Overcloud service 'compute' vs 'block_storage').
>>
>>
>> In the simplest terms, Tuskar translates your definition into the
>> undercloud machine HEAT template, allowing you to then provision your
>> datacenter at the push of a button. Beyond this planning/design, Tuskar
>> also monitors the datacenter, allowing operators to make most efficient
>> use of capacity. Ultimately, Tuskar aims to allow you to plan, define,
>> deploy and monitor your datacenter in an accessible, scalable,
>> repeatable, highly available and secure way.
>> "
> 
> FWIW I see keeping the deployed OpenStack up to date, performing well,
> scaling it up and down, replacing hardware etc as all part of the
> production deployment problem : we'd be delighted to have those
> facilities be part of the TripleO program - but we have to walk before
> we run :).
> 
I just read Tomas e-mail, this is great news :)

marios


> Cheers,
> Rob
> 
>