Open Stack

On Fri, 2018-07-20 at 15:06 -0400, Emilien Macchi wrote:
> 
> 
> On Fri, Jul 20, 2018 at 2:55 PM Ben Nemec <openstack at nemebean.com>
> wrote:
> > Okay, based on a private conversation this is coming off as way
> > more 
> > troll-ish than I intended.  I don't understand where this work is
> > going, 
> > but I don't really need to so I'll step back from the discussion. 
> > Apologies for any offense.
> 
> No offense here, Ben. In fact I hope we can still continue to have a
> productive discussion here.
> 
> I'm speaking on my own view now, and I'm happy to be wrong and learn
> but I wanted to explore how far we can bring the work around
> standalone architecture. If it was worth exploring making it "multi-
> node" somehow, what would be our technical challenges and more than
> anything else: what use-case we would enable.
> 
> I'm actually quite happy to see that people already looked at some of
> these challenges before (see what Giulio / James / Steve H. already
> worked on), so I guess it makes sense to continue the investigation.
> We are not making any decision right now in what API we plan to use.
> The current production architecture is still undercloud + overcloud,
> and our day 2 operations are done by Mistral/Heat for now but as we
> transition more to Ansible I think we wanted to explore more options.
> 
> I hope this little background helped.
> Thanks,
> -- 
> Emilien Macchi
> 

The split-stack work is interesting.

I'm however not convinced driving the standalone for the edge use
cases. (Like Ben I don't have enough background ...) However, this is
the spec of an edge user: https://review.openstack.org/543936 - they
want ironic to deploy their nodes and I bet choosing os-net-config is a
tripleo influenced choice ... 

I think for these users an undercloud that can deploy multiple
overclouds would make more sense. I.e Deploy one undercloud and use
that to deploy a number of overclouds.

I imagine split stack being used to separate compute and controllers.
Something like: controlplane-overcloud-a + compute-overcloud-a0 +
compute-overcloud-a1 + compute-overcloud-a2. 3x stacks building one
cloud using split-stack. Then the undercloud must be able to deploy b,
c, d etc stack sets similar to the a stacks.

This keeps the central management system but we can manage multiple
clouds and for edge-cases we can do scale/update/upgrade operations on
the stack for compute/storage nodes in each edge individually etc.


--
Harald