[manila][cinder][glance][nova] Pop-up team for design and development of a Cephadm DevStack plugin
Victoria Martínez de la Cruz
victoria at vmartinezdelacruz.com
Fri Jan 21 10:58:13 UTC 2022
Thanks everybody for your responses!
I'll send an initial path with a macro to pick between implementations and
we can go from there.
Let's have a meeting next Friday at 3pm UTC in #openstack-qa at OFTC. Would
that work for you?
On Thu, Jan 20, 2022 at 2:04 PM Sofia Enriquez <senrique at redhat.com> wrote:
> Sounds good. I wanna join .
> I haven't tried cephadm yet but It would help us to make ceph new features
> more transparent to Cinder in the future.
> On Thu, Jan 20, 2022 at 4:45 AM Francesco Pantano <fpantano at redhat.com>
>> Hi Victoria,
>> thanks for starting this thread.
>> On Wed, Jan 19, 2022 at 2:03 PM Sean Mooney <smooney at redhat.com> wrote:
>>> 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
>>> > 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
>>> > versions we use and the different distros we support. This led to a
>>> > monolithic script that sometimes is hard to debug and break our
>>> > 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
>>> > and enforces good practices for Ceph clusters. From their docs,
>>> > 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
>>> > uses the orchestration interface (“day 2” commands) to expand the
>>> > to include all hosts and to provision all Ceph daemons and services.
>>> > - OpenStack deployment tools are starting to use cephadm as their way
>>> > 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 , but it might be better to
>>> > 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
>>> 2 differnt ways of deploying ceph in our ci system in the long term.
++ let's pivot devstack-plugin-ceph
to me the way devstack-plugin-ceph install cpeh is jsut an implementaion
>>> its contract is that it will install and configure ceph for use with
>>> 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
>> 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
++ let's meet in #openstack-qa
>>> > Thanks,
>>> > Victoria
>>> >  https://docs.ceph.com/en/pacific/cephadm/
>>> >  https://github.com/vkmc/devstack-plugin-cephadm
>> Francesco Pantano
>> GPG KEY: F41BD75C
> Sofía Enriquez
> Software Engineer
> Red Hat PnT <https://www.redhat.com>
> IRC: @enriquetaso
> @RedHat <https://twitter.com/redhat> Red Hat
> <https://www.linkedin.com/company/red-hat> Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openstack-discuss