You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a Cobbler admin
I want to be able to change the database backend
so that I can adjust the database to my needs.
Provide a detailed description of the proposed feature
Currently, we provide three backends for the storage of our database on disk:
JSON files
a MongoDB database
a SQLite database
All three backends can be configured through settings.yaml. This works great however this doesn't take care of migrating data between those backends.
To achieve this I propose that we introduce a command in cobblerd that handles migrations. For this command to operate the server must not be running. Depending on the implementation the command may be realized similarly as cobbler-settings (so as a separate scriptlet).
The command - independent of the exact implementation - shall take four parameters.
--from <serializer>
--to <serializer>
--adjust-settings <path>
--cleanup
The --from parameter is optional as it can be auto-discovered by the current state of the settings.yaml file. The choices for both serializer parameters should be displayed in the help section and the command shall adjust the value for the serializer of settings.yaml in case the third parameter --adjust-settings is given (default is that settings.yaml is not touched).
The last parameter --cleanup will take care of deleting the old database. The help string should clearly state that the admin is responsible for performing a backup of the old database.
Alternatives you've considered
Extending the cobbler <item> copy syntax was proposed by @tpw56j. This I don't like since it implements that Cobbler needs to be running during this operation. A running server may lead to data corruption since data in memory and on disk may be out of sync.
I still thought about this problem and think that although the task of transferring collection items is somewhat broader than migrating the entire database from one storage type to another, there is no need to implement all such capabilities in Cobbler. Some can be done with database tools, and some with other third-party tools.
Your option of offline migration is much preferable to online copying of the entire database via:
cobbler copy --from/--to <serializer>
I have not found any practical use for copying all items of individual collections:
cobbler profile copy --from/--to <serializer>
I don’t yet have a definite opinion about the possibility of copying single items. Perhaps due to its flexibility in use and ease of implementation, this feature may come in handy:
Is your feature request related to a problem?
As a Cobbler admin
I want to be able to change the database backend
so that I can adjust the database to my needs.
Provide a detailed description of the proposed feature
Currently, we provide three backends for the storage of our database on disk:
All three backends can be configured through
settings.yaml
. This works great however this doesn't take care of migrating data between those backends.To achieve this I propose that we introduce a command in
cobblerd
that handles migrations. For this command to operate the server must not be running. Depending on the implementation the command may be realized similarly ascobbler-settings
(so as a separate scriptlet).The command - independent of the exact implementation - shall take four parameters.
--from <serializer>
--to <serializer>
--adjust-settings <path>
--cleanup
The
--from
parameter is optional as it can be auto-discovered by the current state of thesettings.yaml
file. The choices for both serializer parameters should be displayed in the help section and the command shall adjust the value for the serializer ofsettings.yaml
in case the third parameter--adjust-settings
is given (default is thatsettings.yaml
is not touched).The last parameter
--cleanup
will take care of deleting the old database. The help string should clearly state that the admin is responsible for performing a backup of the old database.Alternatives you've considered
Extending the
cobbler <item> copy
syntax was proposed by @tpw56j. This I don't like since it implements that Cobbler needs to be running during this operation. A running server may lead to data corruption since data in memory and on disk may be out of sync.Additional information
This surfaced during the work on #3554
The text was updated successfully, but these errors were encountered: