This topic has been controversial in the past, but ... > (so to use bare-metal, with the packages directly installed on the machine)
Often called “package-based”. When I started wit Dumpling, there was no upstream orchestrator, one reason that various adopters and distributions rolled there own. When cephadm / ceph orch first came out, it was a bit rough, like any newly-hatched system. I’d never touched a container before, so I personally clung to package-based deployments. Both have since changed. >> If not, is there something technical that prevents it to happen or just >> that there is a policy that container based deployment is the only best way >> to do it therefore cephadm will only use it this way? There is a nontrivial segment of our community who run package-based installs for various reasons, one of which is existing homebrew orchestration. Certain distributions also have their own orchestration: Proxmox AIUI uses package-based deployments. The key thing to know here is that cephadm is a tool, but not the critical path. Our nomenclature and usage can be a bit confusing here, we often conflate “cephadm” and the “ceph orch” orchestrator. >> >> I ask this in the context of finding out that ceph-ansible is deprecated >> and that it should not be used, I hear conflicting information re ceph-ansible, but my sense is that usage of and support for it going forward is at most less than it once was. >> but i still need to use ansible for >> management and i think (so without factual experience) that bare metal >> services would be easier to manage after doing by hand deployment with >> cephadm If you had difficulty with a cephadm / ceph orch deployment, it may be that your process wasn’t getting something right. It would not be uncommon for an Ansible playbook to take care of setting up SSH keys etc. before an orchestrated deployment. That said, an example of Ansible code using cephadm / ceph orch is vexxhost/atmosphere on GitHub. I would not necessarily recommend adopting / adapting this for Ceph deployment, but it’s a useful example. Ansible’s command and shell modules let you invoke any CLI you like and act based on the return code. Even the asynchronous nature of certain operations is straightforward to accommodate with looping (and I have an RFE in to add a —synchronous switch). > Using containers is one of the fundamental building blocks of cephadm and it > would be a very large, potentially disruptive, change to alter that. However, > Ceph already has some level of support of alternative orch backends. My sense is that Rook is an example. > To also briefly touch on your point WRT ansible: there is already a cephadm- > ansible project (see https://docs.ceph.com/projects/cephadm-ansible/en/latest/ > index.html ). Personally, I also drive my VM setups using ansible and cephadm > together (but I'm just a mere dev and all my clusters are ephemeral :-)). cephadm-ansible is AIUI a collection of utilities / glue that enable just what you’re after: managing the orchestrator with Ansible. _______________________________________________ ceph-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
