On 17-11-13 07:40 PM, John Spray wrote:
On Mon, Nov 13, 2017 at 6:20 PM, Kyle Bader <kyle.bader@xxxxxxxxx> wrote:
Configuration files are often driven by configuration management, with
previous versions stored in some kind of version control systems. We
should make sure that if configuration moves to the monitors that you
have some form of history and rollback capabilities. It might be worth
modeling it similar to network switch configuration shells, a la
Junos.
* change configuration
* require commit configuration change
* ability to rollback N configuration changes
* ability to diff to configuration versions
That way an admin can figure out when the last configuration change
was, what changed, and rollback if necessary.
That is an extremely good idea.
As a minimal thing, it should be pretty straightforward to implement a
snapshot/rollback.
https://thedailywtf.com/articles/The_Complicator_0x27_s_Gloves
I imagine many users today are not so disciplined as to version
control their configs, but this is a good opportunity to push that as
the norm by building it in.
Using Ceph on any decent scale actually requires one to use at least Puppet
or similar tool, I wouldn't add any unnecessary complexity to already
complex code just because of novice users that are going to have hard time
using Ceph anyway once a disk breaks and needs to be replaced, or when
performance goes to hell because users are free to create and remove
snapshots every 5 minutes.
And I can already imagine clusters breaking down once config
database/history breaks for whatever reason, including early implementation
bugs.
Distributing configs through mon isn't bad idea by itself, I can imagine
having changes to runtime-changeable settings propagated to OSDs without the
need for extra step (actually injecting them) and without the need for
restart, but for anything else, there are already good tools and I see no
value in trying to mimic them.
--
Piotr Dałek
piotr.dalek@xxxxxxxxxxxx
https://www.ovh.com/us/
--
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
