Open Stack

On Mon, Oct 10, 2016 at 05:11:28PM +0200, Spyros Trigazis wrote:
> Hi heat and magnum.
> 
> Apart from the scalability issues that have been observed, I'd like to
> add few more subjects to discuss during the summit.
> 
> 1. One nested stack per node and linear scale of cluster creation
> time.
> 
> 1.1
> For large stacks, the creation of all nested stack scales linearly. We
> haven't run any tested using the convergence-engine.

Convergence would hopfully help in this scenario, thus definitely worth
a try.

<snip...> 
> 1.3
> After the stack create API call to heat, magnum's conductor
> busy-waits heat with a thread/cluster. (In case of a magnum conductor
> restart, we lose that thread and we can't update the status in
> magnum). Investigate better ways to sync the status between magnum
> and heat.

Sounds like something to be done when magnum conductor bootstraps
itself.
 
> 2. Next generation magnum clusters
> 
> A need that comes up frequently in magnum is heterogeneous clusters.
> * We want to able to create cluster on different hardware, (e.g. spawn
>   vms on nodes with SSDs and nodes without SSDs or other special
>   hardware available only in some nodes of the cluster FPGA, GPU)
> * Spawn cluster across different AZs

This smells very much like a senlin use case.
> I'll describe briefly our plan here, for further information we have a
> detailed spec under review. [1]
> 
> To address this issue we introduce the node-group concept in magnum.
> Each node-group will correspond to a different heat stack. The master
> nodes can be organized in one or more stacks, so as the worker nodes.

My personal feeling is that modelling a node-group as a heat stack is
feasible though not flexible. It will end up heavy dependency on the
'stack-update' operation for whatever changes needed later. Senlin
provides you more APIs on managing such a group of things, without
masking out any existing features/capabilities from heat template/stack.

> We investigate how to implement this feature. We consider the
> following:
> At the moment, we have three template files, cluster, master and
> node, and all three template files create one stack. The new
> generation of clusters will have a cluster stack containing
> the resources in the cluster template, specifically, networks, lbaas
> floating-ips etc. Then, the output of this stack would be passed as
> input to create the master node stack(s) and the worker nodes
> stack(s).

Before investing resources into this effort, you may want to check if
senlin (can be improved to) meet magnum's requirements:

 - API [1]
 - User Doc [2] 
 - Developer Doc [3]
 - Quick Tutorial [4]

> 4. Finally, a thought under investigation is replacing the nodes one
>    by one using a different image. e.g. Upgrade from fedora 24 to 25
>    with new versions of packages all in a new qcow2 image. How could
>    we update the stack for this?

Emm.. senlin is working on an operation that allows you to replace
existing nodes: 

  POST /v1/clusters/<cluster_id>/actions

  {
    'replace_nodes': {
      'name_or_id_old_node': 'name_or_id_new_node',
      ...
    }
  }


References:

[1] http://developer.openstack.org/api-ref/clustering/
[2] http://docs.openstack.org/developer/senlin/user/index.html
[3] http://docs.openstack.org/developer/senlin/developer/index.html
[4] http://docs.openstack.org/developer/senlin/tutorial/index.html