Open Stack

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"

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

note that I know of at least another case (the swift rings building)
which would benefit from being able to trigger a workflow during the
overcloud deployment and does not need to run ansible

[...]

>> Personally, I'm pretty apprehensive about the approach taken in (3). I
>> feel that it is a lot of complexity that could be done simpler if we
>> took a step back and thought more about a longer term approach. I
>> recognize that it's mostly an experiment/POC at this stage, and I'm
>> not trying to directly knock down the approach. It's just that when I
>> start to see more patches (Kubernetes installation) using the same
>> approach, I figure it's worth discussing more broadly vs trying to
>> have a discussion by -1'ing patch reviews, etc.
> 
> I agree, I think the approach in (3) is a stopgap until we can define
> a cleaner approach with less layers.

> IMO the first step towards that is likely to be a "split stack" which
> outputs heat data, then deployment configuration is performed via
> mistral->ansible just like we already do in (1).

given option (3) allows triggering of workflows during a particular
deployment step, it seems that option (1) would need to be revisited to
implement some sort of a loop in mistral, instead of heat, to provide
that same functionality ... which in the end moves the existing logic
from heat into mistral

>> I'm interested in all feedback of course. And I plan to take a shot at
>> working on the prototype I mentioned in (5) if anyone would like to
>> collaborate around that.
> 
> I'm very happy to collaborate, and this is quite closely related to
> the investigations I've been doing around enabling minor updates for
> containers.
> 
> Lets sync up about it, but as I mentioned above I'm not yet fully sold
> on a new translation tool, vs just more t-h-t refactoring to enable
> output of data directly consumable via ansible-playbook (which can
> then be run via operators, or heat, or mistral, or whatever).
I'd be happy to revisit the requirements around the ceph-ansible
integration as well, to see how those can still be met
-- 
Giulio Fidente
GPG KEY: 08D733BA