Role based nodes

[wimpers]

Currently a host can have many roles (run the framework, arakoon , asds, voldrv) but assigning these roles isn't very flexible. With this feature request we want to be assign roles more flexible.

This feature should tackle a few items:

• Don't automatically deploy the GUI on all master nodes. We could f.e. run the GUI in a container which can be moved or deployed across the cluster.

  • Use a keep alive IP for the GUI Integrate keepalived IP address during setup #1116

• Allow multiple storagedrivers for the same vpool to be deployed on a single host Multiple StorageDrivers per vPool/StorageRouter #1290

• Allow to specify which nodes to be used for the DTL Setup and configure DTL nodes #993

• Allow to specify which nodes should be used for arakoon/metadata Arakoon deployment configurable via GUI/framework #1712

  • allow to set preferred master
  • allow to set a standby arakoon host Automatically replace a broken Arakoon node #1596
  • allow to spin up new nsm cluster, don't allow to remove arakoon clusters (f.e. nsm cluster removal as requested in add an option remove-nsm-host alba#713 is out of scope)

• Allow to specify which nodes should be used Iscsi servers

• Allow to specify which nodes should be used for rabbitMQ

• Proxies deployment https://github.com/openvstorage/home/issues/38

• Placement of maintenance processes Maintenance agent for global backend in case of remote backends not being deployed framework-alba-plugin#200

• (Optionally) monitoring stack

• deploy the asd packages on storage node only nodes without having to copy the cacc Seperated storage nodes: ask IP to copy arakoon config file/etcd config #631

[wimpers]

@saelbrec feel free to add your input

[domsj]

Allow to specify which nodes should be used for arakoon/metadata #1712

What is the granularity of these roles?
Is there 1 role for all arakoon clusters? Or subdivided by type of arakoon clusters (e.g. ovsdb/voldrv/abm/nsms)? Or for the alba specific ones it can depend on which backend the abm/nsm belongs too?

Placement of maintenance processes is one to add to your list too.

[wimpers]

I would allow this to be as specific as possible even up the the NSM backend level. It should allow you to have full control over where which Arakoon cluster lives so the external Arakoon cluster 'hack' is no longer needed.

[JeffreyDevloo]

I might have misclicked