> -----Original Message----- > Sent: Monday, 21 June 2021 16:44 > Subject: Re: 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! _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |