Re: subpackages for mgr modules

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

 



On Mon, May 22, 2017 at 11:45 AM, Ken Dreyer <kdreyer@xxxxxxxxxx> wrote:
> On Sun, May 21, 2017 at 4:31 PM, John Spray <jspray@xxxxxxxxxx> wrote:
>> My preferred solution would be mon commands for toggling modules "ceph
>> mgr module [enable|disable] <module>", and a record in the MgrMap that
>> says which are enabled.
>
> Sure. It's just another command users have to do to get to a preferred state.
>
> The classic response on these things has been "ceph setup is hard,
> let's wrap it in ceph-ansible" (or whatever higher-level tool will do
> all these tricky steps). Then ceph-ansible becomes more and more
> complex, and I wonder whether the complexity could be addressed
> elsewhere by simply scaling down the flexibility.

I can agree here with how these helpful commands tend to add
complexity on the deployment systems.

Maybe a good compromise would be the allow both? That is: installation
would enable a module, but that
could also be disabled (and re-enabled) by the CLI. That way, we
aren't forcing users to uninstall always and keeps
other systems like ceph-ansible lean.

>
> - Ken
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux