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