On 07/10/2017 09:23 PM, James Slagle wrote: > On Mon, Jul 10, 2017 at 2:54 PM, Giulio Fidente <gfide...@redhat.com> wrote: >> On 07/10/2017 07:06 PM, James Slagle wrote: >>> On Mon, Jul 10, 2017 at 11:19 AM, Giulio Fidente <gfide...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
