Open Stack

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:
>> On 07/10/2017 03:19 PM, Steven Hardy wrote:
>>> On Fri, Jul 7, 2017 at 6:50 PM, James Slagle <james.slagle at gmail.com> wrote:
>>
>> [...]
>>
>>> Yeah, I think the first step is to focus on a clean "split stack"
>>> model where the nodes/networks etc are still deployed via heat, then
>>> ansible handles the configuration of the nodes.
>>
>> +1
>>
>> as per my previous email, if splitstack was available we might have been
>> able to use that for the ceph-ansible integration : "if we had migrated
>> to splitstack already, it might have been possible"
> 
> Can you expand on what isn't available? I've primarily been the one
> working on different parts of splitstack, and I'm not sure what it
> can't do that you need it to do :).

the idea behind option (3) was to make it possible to run any mistral
workflow (or task) to deploy a service

we decoupled, on a per-service basis, how a given service is deployed
from the rest of the stack, yet maintained orchestration of the
overcloud deployment steps in heat; I know for sure that not everybody
liked this idea but it was the goal

as a result via option (3) you can deploy a new service in tripleo by
pointing it to a workflow ... and it doesn't matter if the workflow uses
ansible, puppet or simply returns 0

plus the workflow can be executed at a given deployment step, making it
possible to interleave its execution with the rest of the deployment
steps (the puppet apply steps); splitstack couldn't interleave the steps
and even if we made it to, we needed to add the parts to describe which
workflow/task needed to be run

but now that option (3) is implemented, assuming we move outside heat
the capability to collect and run tasks/workflows for a given service,
it'll be trivial to remove the "mistral > heat > mistral" loop, we'd
just need to execute the service workflows from the
$new_tool_driving_the_deployment_steps

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

-- 
Giulio Fidente
GPG KEY: 08D733BA