Re: Storing cls and erasure code plugins in a pool

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



If you're planning on having plugins that are not shipped with the
host software you have to worry about both API and ABI stability.
Traditionally (and in my personal experience) keeping a C++ ABI
compatible is hard. For those reasons, I would strongly campaign for
having the plugins interface be in C (or et least their interface
would be C linkage).

Otherwise here's some things you can read read about C++ ABI stability
(from the KDE people):
https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++

This are my 2 cents based on my past experience.

On Sun, Sep 7, 2014 at 4:26 AM, Loic Dachary <loic@xxxxxxxxxxx> wrote:
> Hi Ceph,
>
> There is a need for a cluster to share code such as cls https://github.com/ceph/ceph/tree/master/src/cls or erasure code plugins https://github.com/ceph/ceph/tree/master/src/erasure-code/.
>
> These plugins could have a life cycle independent of Ceph, as long as they comply to the supported API ( https://github.com/ceph/ceph/blob/master/src/erasure-code/ErasureCodeInterface.h ). For erasure code plugins it currently works this way (or it will as soon as https://github.com/ceph/ceph/pull/2397 is merged):
>
> a) upgrade from Hammer to I* half the OSD nodes. The new I* have new erasure code plugins
> b) the MON will refuse to create an erasure coded pool using the new I* plugins, otherwise the Hammer nodes will find themselves unable to participate in the pool
>
> Instead it could work this way:
>
> a) upgrade from Hammer to I* half the OSD nodes. The new I* have new erasure code plugins
> b) the new erasure code plugins are uploaded to a "plugins" pool
> c) an erasure coded pool is created using a new plugin from I*
> d) the Hammer OSD downloads the plugin from the pool and can participate in the pool
>
> It is easier said than done and there are a lot of details to consider. However it not different from maintaining an Operating System that includes shared libraries and the path to do so properly is well known.
>
> Thoughts ?
>
> Cheers
>
> --
> Loïc Dachary, Artisan Logiciel Libre
>



-- 
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016

p: 646-253-9055
e: milosz@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux