Hi folks, We had some productive face to face discussions last week about how to build a generic interface between the dashboard and the various cluster orchestration backends (ceph-ansible, DeepSea, Rook). The motivation is to enable users to manage their Ceph services using the shared dashboard, no matter which orchestrator is in use. Thanks to everyone who was able to participate last week (and it was great to catch up with you all!) We discussed having a common set of functions, with implementations living inside ceph-mgr as some extra per-backend python code. The underlying orchestration platform would remain the source of truth for information about available hardware and what services are running where: the new mgr code is just "glue". The key list of capabilities from the whiteboard last Wednesday were: 1. Getting an inventory from the orchestrator (list of nodes+drives) 2. Add/remove of stateful services (osds, mons) targeting particular nodes+drives 3. Add/remove of stateless services, leaving node location up to orchestrator 4. Requesting orchestrator to upgrade the Ceph cluster 5. Getting status from orchestrator about currently running daemons I've written some draft python classes in this PR to serve as a basis for continued discussion (https://github.com/ceph/ceph/pull/21046/files) -- please add your comments. For anyone joining the discussion at this point, let me emphasize that the goal is *not* to define a completely general purpose interface for managing linux servers, or for managing Ceph: this is just about the placement and lifecycle of the Ceph daemons. When it comes to doing a real implementation of this interface, I'm thinking that each of the orchestrator backends should be its own ceph-mgr module -- that way, they have access to the mgr module configuration and persistence hooks and we don't have to re-invent any of that for orchestrator modules specifically. The dashboard module can then look at which module is enabled to work out which one to call through to (although perhaps some extra protection is needed to avoid someone enabling more than one). This all relies on the forthcoming ability for modules to call out to one another, of course. Cheers, John -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
