Hi, Thanks for the summary/plan that resulted from last week's meetings. Some comments/questions below: On 26-03-2018 15:35, John Spray wrote:
Hi folks, 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".
Sounds like the best way to go. Similar to what we discussed a few weeks ago in another email thread.
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
Each of the stateless services (and might also apply to future stateful services) has different ways to configure. From an implementation perspective we need to write specialized code (within the orchestration module) to handle each of the stateless service. This means that maybe we should also add the capability of listing the types of services supported by the 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. 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.
Was the ability for modules to call another modules already discussed somewhere? or is there already an implementation draft?
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
-- Ricardo Dias Senior Software Engineer - Storage Team SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- 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
