On 07/10/2017 03:19 PM, Steven Hardy wrote: > On Fri, Jul 7, 2017 at 6:50 PM, James Slagle <[email protected]> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
