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.

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.

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?

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.



> -----Original Message-----
> Sent: Monday, 21 June 2021 01:21
> To: ceph-users@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@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io
_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Reply via email to