On 18/09/13 19:44, Robert Collins wrote: > On 18 September 2013 20:59, mar...@redhat.com <mandr...@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 > > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
