Open Stack

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?

Thanks,

Victoria

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.
> Thanks
>


++


>
>
> On Thu, Jan 20, 2022 at 4:45 AM Francesco Pantano <fpantano at redhat.com>
> wrote:
>
>> 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
>>> 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.
>>>
>>>
++ let's pivot devstack-plugin-ceph

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
>>
>
++ let's meet in #openstack-qa


>
>>> >
>>> > Thanks,
>>> >
>>> > Victoria
>>> >
>>> > [0] https://docs.ceph.com/en/pacific/cephadm/
>>> > [1] https://github.com/vkmc/devstack-plugin-cephadm
>>>
>>>
>>>
>>
>> --
>> Francesco Pantano
>> GPG KEY: F41BD75C
>>
>
>
> --
>
> Sofía Enriquez
>
> she/her
>
> 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
> <https://www.facebook.com/RedHatInc>
> <https://www.redhat.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220121/07f85d11/attachment-0001.htm>