-----Original Message-----
Sent: Monday, 21 June 2021 16:44
Subject: Re: [ceph-users] Re: Why you might want packages not containers
for Ceph deployments
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
So why did you make this a point previously stating something that you were able to use
ceph with kubernetes like commands.
How can you compare docker/containers to ansible? It is like comparing a drill to fruit
mixer or so.
(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.
Your feelings mislead you, you would understand this if you knew what I am writing
about.
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.
1. Is this even being done then cephadm? I still see commands that upgrade a whole node.
2. Has this ever been a problem in the past? I had no problems going from Kraken ->
Luminous -> nautilus. There is no significant problem updating and/or upgrading.
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
Yes and let me guess the solution is sending a whole centos/rhel container image? Not!