I think the primary goal of a container environments
are resource isolation. At least when I read about the history I never read anything about
a tool for people to skip to learn something.
Containers allow to use mixed version
of the same dependency, despite
being a shared dependency, doing this in a non container envrionment
basically means rebuilding containers
But you clearly portray the situation here. Nobody
here is against container environment, because every tool has its purpose. But the
container solution proposed here is not for the purpose of utilizing container benefits,
but for creating a tool so 'I do not know what to do' people can use ceph. And
because this is the development perspective and ceph is not really adapted for being used
in containers, you get the current friction with accepting cephadm.
Is this like an insult? The point is not about not learning something,
but I would choose docker/container over ansible every time for this
(ansible has its place, but it has no concept of current state, as a
ceph orchestrator heavily benefits from).
I kinda feel that you have not worked a lot with containers, created a
strawman what you think benefits are, and then continue to burn down
that strawman while not even recognizing a lot of benefits.
Eg. this command is wrong in my opinion
ceph orch device ls
What has a device list to do with having an OC or not?
Well you need to start a
small tool to actually find devices on every
system, for this you need to first find all nodes that exist in the
cluster, if not the orchestrator, who should have this information,
especially since it can change at runtime due to hosts being added.
I do not even know why ceph is working on something
that uses Kubernetes, let the Kubernetes platform implement a ceph solution. If ceph wants
be used in a container environment, start making the daemons ready to run in container
environments.
So my question still stands: What problem is it actually that the cephadm dev team is
trying to solve? That is not clear to me.
Again, clean orchestration, being able to upgrade each deamon without
influencing running ones, this is just not possible with the native
packages.
Being able to run on a lot more platforms, as native packages are just
not maintainable for all platforms that could easily run a docker daemon.
>
>
>
>> -----Original Message-----
>> Sent: Monday, 21 June 2021 01:21
>> To: ceph-users(a)ceph.io
>> Subject: [ceph-users] Re: Why you might want packages not containers for
>> Ceph deployments
>>
>> Because all of this reads way to negative regarding containers for me I
>> wanted to give a different perspective.
>>
>> Coming from a day to day job, that heavily utilizes kubernetes for its
>> normal environment, I found cephadm quite like a godsent,
>>
>> instead of having to deal with a lot of pesky details with installations
>> and services, having to learn ansible or ceph-deploy, that tool did like
>> 90% of everything in a way I already feel familiar with it.
>>
>> Additionally, having some pools for not so important data using low
>> replications counts, it is quite nice, that cephadm only concurrently
>> upgrades osd's in matter that no service interruptions happen.
>>
>> There are still some shortcomings (eg. some limitations when moving osd
>> devices between hosts), but as it is still a relatively new tool that is
>> to be expected.
>> _______________________________________________
>> ceph-users mailing list -- ceph-users(a)ceph.io
>> To unsubscribe send an email to ceph-users-leave(a)ceph.io