Re: Why you might want packages not containers for Ceph deployments

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I figured it might be worth chiming in with an example from users (even
though we're not quite novice users anymore).

On the one hand we really like cephadm - it's beautiful with central
reporting of versions, status, default ability to perform rolling updates,
placing services, etc.

A minor drawback is that we can no longer easily handle things in salt, but
I think that's a matter of having to accept that we can't both eat the cake
and have it (since both are different management tools).

However, we recently had another snafu - suddenly cephadm upgrade doesn't
do anything - it just waits. I'm sure this is a trivial bug/config setting
somewhere, but there are pretty much no log messages about, and what would
have been trivial with standard packages (just force an upgrade, one node
at a time, if necessary) suddenly becomes a bug-hunt that might take a day
or two.

This is most definitely not an argument against Cephadm. I think it's a
great solution we'll stick with, and I'm sure it will only get more stable.
Still, I think the challenge for non-expert users is that *default*
deployments and maintenance can be easier with container solutions, but
when you need to step out of that and debug/customize things, the
additional layer(s) create a barrier.

Cheers,

Erik
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx



[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux