Open Stack

On 07/10/2017 09:23 PM, James Slagle wrote:
> On Mon, Jul 10, 2017 at 2:54 PM, Giulio Fidente <gfidente at redhat.com> wrote:
>> On 07/10/2017 07:06 PM, James Slagle wrote:
>>> On Mon, Jul 10, 2017 at 11:19 AM, Giulio Fidente <gfidente at redhat.com> wrote:
>>>> splitstack though requires changes in how the *existing* openstack
>>>> services are deployed and we didn't want to do that just for the purpose
>>>> of integrating ceph-ansible so I still believe (3) to be a sensible
>>>> compromise to provide the needed functionalities and not breaking the
>>>> existing deployment logic
>>>
>>> We might be talking about different definitions of "splitstack", as
>>> I'm not sure what changes are required for existing services. FWIW, I
>>> refer to what we do in CI with multinode to be splitstack in that the
>>> nodes are already provisioned and we deploy the services on those
>>> nodes using the same templates that we do for a "full" stack.
>>
>>> Those nodes could have just as easily been provisioned with our
>>> undercloud and the services deployed using 2 separate stacks, and that
>>> model works just as well.
>>
>> true, sorry for the misuse of the term splistack; the existing
>> splitstack implementation continues to work well and option (3), like
>> the others, can be plugged on top of it
>>
>> what I had in mind was instead the "split stack" scenario described by
>> Steven, where the orchestration steps are moved outside heat, this is
>> what we didn't have, still don't have and can be discussed at the PTG
> 
> Ok, thanks for clarifying. So when you're saying split-stack in this
> context, you imply just deploying a baremetal stack, then use whatever
> tool we want (or may develop) to deploy the service configuration.

yes but I am still assuming heat to be tool providing the per-role and
per-service settings, while not the tool orchestrating the steps anymore

I also don't think we should assume puppet or ansible to be "the
deployment tool"; the past seems to be telling us that we changed the
tool once already, later decided to use a new one fitting better our
needs for upgrades and yet resorted to a third more generic 'workflow
triggering' mechanism to decouple further some services configuration
from the general approach and I wouldn't give away flexibility easily
-- 
Giulio Fidente
GPG KEY: 08D733BA