Hi Bernd
On 2020-05-27 21:22, Bernd Zeimetz wrote:
sorry for not replying inline, but I thought I'd just share my general
opinion on this.
The biggest issue in maintaining ceph is to make it build on 32 bit
architectures. This seems not to be supported at all by upstream
anymore.
First of all, I don't know what your goal is to support 32 bit.
I do have a goal: I have loads of armhf machines and only so many amd64
machines that do not even have enough memory to properly support ceph
and being able to do something (as the MON uses 1GB of memory alone).
I have multiple sites with this situation, and for the foreseeable
future, we will still be building infrastructure on armhf. Getting a
decent AMD64 setup in any location is additional and probably
unnecessary costs.
Between 14.2.7 and 14.2.9 I had a longer look into the issue and
started
to fix some issues, for example the parsing of config options does
pretty broken things if the default for the option does not fit into a
32bit integer. Fixing this properly brought me to various other places
where size_t is being used in the code, but actually an (at least)
uint64_t is being required.
Fedora already removed ceph for all 32bit architectures with a "not
supported by upstream anymore", but I was not able to find an official
statement from ceph upstream.
I think the stance of the ceph community in this is: as long as nobody
sends in patches they are not going to care. And they can't support it
themselves because they have a totally different target (clouds).
Also unfortunately I did not yet find the time to collect my findings
and send them to the ceph devel mailinglist, but I'd assume that they
just don't want to support 32bit anymore, otherwise they'd test it
properly.
As the work to fix this is properly seems to be a rather long task, I
definitely won't do this. But I also don't want to upload maybe-working
binaries to Debian anymore. So unless somebody fixes and tests ceph for
32bit (or does this for Debian, also fine for me - running the
regression test suite is possible with enough resources and some
hardware), I will remove all 32bit architectures with the next upload.
My debian karma is bad, really bad. That's why I asked you what your
goal is of supporting 32 bit. I have a goal. I might also be able to let
64 bit lxc containers talk to 32 bit lxc containers and real armhf
machines so I can test.
I am willing to host the armhf releases and maybe the i386 releases on
my server, that way there will be 32 bit releases but not official ones.
But I do want your involvement.
I've been trying to compile it for a time, using sources from ceph and
from proxmox, until I realised ceph nautilus is in backports. And it
worked.
So at least I want your guidance on how you build these... For now I've
used an armhf machine, and I needed to limit the number of threads to 1
due to c++ compiler needing more than 1GB of RAM to compile a single
source.
Not only do I want to make support complete so I can use hardware, I
also think it's just bad programming not to use explicit sizes. And I am
also on the verge of investing in amd64 clusters, I don't want it to
depend on code that's depending on a lot of features.
Anyway: I don't know how you build and test on non amd64 systems, do you
also use armhf, or do you use a cross compile environment?
Regards,
Ard van Breemen
