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
__________________________________________________________________________
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
