On Thu, Dec 21, 2017 at 1:48 AM, Tim Serong <tserong@xxxxxxxx> wrote: > (broad topic :-), trimming back to my immediate comment/question) > > On 12/20/2017 09:55 PM, John Spray wrote: >> What? >> ===== >> >> Extend the dashboard module to provide management of the cluster, in >> addition to monitoring. This would potentially include anything you >> can currently do with the Ceph CLI, plus additional functionality like >> calling out to a container framework to spawn additional daemons. >> >> The idea is to wrap things up into friendlier higher-level operations, >> rather than just having buttons for the existing CLI operations. >> Example workflows of interest: >> - a CephFS page where you can click "New Filesystem", and the pools >> and MDS daemons will all be created for you. >> - similarly for RGW: ability to enable RGW and control the number of >> gateway daemons >> - driving OSD additional/retirement, and also format conversions >> (e.g. filestore->bluestore) >> >> Some of the functionality would depend on how Ceph is being run: >> especially, anything that detects devices and starts/stops physical >> services would depend on an environment that provides that (such as >> Kubenetes). > > Any configuration/management of things that ceph already knows about is > "easy" to implement (creating pools, rbd volumes, cluster config, etc.) > > For spawning/configuring additional daemons, is it worth considering > some kind of thin layer (another mgr module or modules?) that let the > admin choose whether this is done by k8s, salt, ansible, whatever? Yes, absolutely -- the main two that have been discussed so far are kubernetes and a notional baremetal fallback, where the bare metal version would be something that has a very small set of commands (discover devices, format an OSD, control a service with systemd) run over SSH. It's easy to imagine salt being another route to managing bare metal, and probably working a bit more robustly than the super-simple pure SSH bare metal option. That said, we should think carefully about in which sorts of scenarios an external orchestration tool needs to be in the loop: for example I don't think we'd want to be calling into salt/ansible in cases where they were just forwarding ops into Kubernetes for us -- the core value of the external orchestrator is in doing things we can't do ourselves, like working out the OS and networking configuration, bootstrapping the container environment. 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
