On Wed, 2022-01-19 at 12:04 +0100, Victoria Martínez de la Cruz wrote:
> Hi all,
>
> I'm reaching out to you to let you know that we will start the design and
> development of a Cephadm DevStack plugin.
>
> Some of the reasons on why we want to take this approach:
>
> - devstack-plugin-ceph worked for us for a lot of years, but the
> development of it relies on several hacks to adapt to the different Ceph
> versions we use and the different distros we support. This led to a
> monolithic script that sometimes is hard to debug and break our development
> environments and our CI
> - cephadm is the deployment tool developed and maintained by the Ceph
> community, it allows their users to get specific Ceph versions very easily
> and enforces good practices for Ceph clusters. From their docs, "Cephadm
> manages the full lifecycle of a Ceph cluster. It starts by bootstrapping a
> tiny Ceph cluster on a single node (one monitor and one manager) and then
> uses the orchestration interface (“day 2” commands) to expand the cluster
> to include all hosts and to provision all Ceph daemons and services. [0]"
> - OpenStack deployment tools are starting to use cephadm as their way to
> deploy Ceph, so it would be nice to include cephadm in our development
> process to be closer with what is being done in the field
>
> I started the development of this in [1], but it might be better to change
> devstack-plugin-ceph to do this instead of having a new plugin. This is
> something I would love to discuss in a first meeting.
i would advocate for pivoting devstack-plugin-ceph.
i dont think we have the capsity as a comunity to devleop, maintaine and debug/support
2 differnt ways of deploying ceph in our ci system in the long term.
to me the way devstack-plugin-ceph install cpeh is jsut an implementaion detail.
its contract is that it will install and configure ceph for use with openstack.
if you make it use cephadm for that its just and internal detail that should not
affect the consomes of the plugin provide you maintain the interface to the devstack pluging
mostly the same.
Starting with pacific the deployment of Ceph is moved from ceph-ansible to cephadm: the implication of this change it's not just
on the deployment side but this new component (which interacts with the ceph orchestrator module) is able to maintain the lifecycle
of the deployed containers, so I'd say the new approach it's not just an implementation detail but also changes the way some components
interact with Ceph.
Manila using ganesha, for instance, it's the first component that should start using the orchestrator interface, so I guess it's worth
aligning (and extending) the most popular dev installer to support the new way (like other projects already did).
i would suggest addign a devstack macro initally to choose the backend but then eventually
once the cephadm appoch is stable just swap the default.
+1 on choosing the backend and plan the switch when the cephadm approach is ready and works for all the openstack components
>
> Having said this, I propose using the channel #openstack-cephadm in the
> OFTC network to talk about this and set up a first meeting with people
> interested in contributing to this effort.
ack im not sure i will get involed with this but the other option woudl be to
just use #openstack-qa since that is the chanlle for devstack development.
Either #openstack-qa or a dedicated one works well , maybe #openstack-qa is useful to reach more people
who can help / review the relevant changes .. wdyt
>
> Thanks,
>
> Victoria
>
> [0] https://docs.ceph.com/en/pacific/cephadm/
> [1] https://github.com/vkmc/devstack-plugin-cephadm