Hello guys,
I'm doing this bug https://bugzilla.redhat.com/show_bug.cgi?id=1113207%C2%A0 and because of it I need to create new KS command for snapshot creation. Because kickstart is something with really stable API, I want to ask everyone before I'll implement something badly.
Possible solutions:
Adding --snapshot parameter to existing KS command -------------------------------------------------- * It should be easier to implement. * Could be easier to find in documentation. * It's logically part of that storage type. * logvol command have big number of parameters now.
Adding standalone snapshot command ---------------------------------- * Harder to implement but it's more general. * Easier to extend. * Easier to just add support for btrfs with additional required parameters and anything else in future and syntax will not change so much.
Personally I see the snapshot command as better choice but want to hear your idea.
Thank you for your feedback, Jirka
On Thu, Jun 23, 2016 at 05:36:38PM +0200, Jiří Konečný wrote:
Hello guys,
I'm doing this bug https://bugzilla.redhat.com/show_bug.cgi?id=1113207%C2%A0 and because of it I need to create new KS command for snapshot creation. Because kickstart is something with really stable API, I want to ask everyone before I'll implement something badly.
Possible solutions:
Adding --snapshot parameter to existing KS command
* It should be easier to implement. * Could be easier to find in documentation. * It's logically part of that storage type. * logvol command have big number of parameters now.
Adding standalone snapshot command
* Harder to implement but it's more general. * Easier to extend. * Easier to just add support for btrfs with additional required parameters and anything else in future and syntax will not change so much.
Personally I see the snapshot command as better choice but want to hear your idea.
I like the standalone snapshot command. The user doesn't need to know what's underneath it and could possibly do:
autopart --type=thinp snapshot --name=initial_install
And then switching to btrfs would be as simple as using a different autopart type.
If used with non-autopart it will also need to sanity check their storage setup to make sure they are using something that supports snapshots.
I also agree with your comment in the bug, minimize changes to Anaconda and keep using /.
Adding standalone snapshot command
* Harder to implement but it's more general. * Easier to extend. * Easier to just add support for btrfs with additional required parameters and anything else in future and syntax will not change so much.
Personally I see the snapshot command as better choice but want to hear your idea.
What do you imagine the snapshot command will do? What arguments will it need to take?
- Chris
On Thu, 2016-06-23 at 08:56 -0700, Brian C. Lane wrote:
On Thu, Jun 23, 2016 at 05:36:38PM +0200, Jiří Konečný wrote:
Hello guys,
I'm doing this bug https://bugzilla.redhat.com/show_bug.cgi?id=1113 207 and because of it I need to create new KS command for snapshot creation. Because kickstart is something with really stable API, I want to ask everyone before I'll implement something badly.
Possible solutions:
Adding --snapshot parameter to existing KS command
* It should be easier to implement. * Could be easier to find in documentation. * It's logically part of that storage type. * logvol command have big number of parameters now.
Adding standalone snapshot command
* Harder to implement but it's more general. * Easier to extend. * Easier to just add support for btrfs with additional required parameters and anything else in future and syntax will not change so much.
Personally I see the snapshot command as better choice but want to hear your idea.
I like the standalone snapshot command. The user doesn't need to know what's underneath it and could possibly do:
autopart --type=thinp snapshot --name=initial_install
And then switching to btrfs would be as simple as using a different autopart type.
If used with non-autopart it will also need to sanity check their storage setup to make sure they are using something that supports snapshots.
Good point, I totally forgot about autopart. Requirement for sanity check is main reason why I wrote that it will be harder to implement.
Thank you for pointing this out.
I also agree with your comment in the bug, minimize changes to Anaconda and keep using /.
On Thu, 2016-06-23 at 14:23 -0400, Chris Lumens wrote:
Adding standalone snapshot command
* Harder to implement but it's more general. * Easier to extend. * Easier to just add support for btrfs with additional required parameters and anything else in future and syntax will not change so much.
Personally I see the snapshot command as better choice but want to hear your idea.
What do you imagine the snapshot command will do? What arguments will it need to take?
Now it won't do much, it only takes name of the thin-LVM and name of the future snapshot. When you use this command, it creates snapshot before the system will restart at the end of the installation. Main reason for this is testing if everything is fine after an installation and factory reset for a running system.
For future I think it should have: * before/after (or even before post/pre section) installation do a snapshot to existing LV * required parameters for other storage (like size of a snapshot for normal LVM) and who knows what for btrfs or anything else in the future * mountpoint where you want to mount this snapshot (you can do backup of whole system before install and automatically mount it to some place in installed system) * mount it as ro/rw should be another parameter
I think there could be even more of similar features.
On Thu, 2016-06-23 at 08:56 -0700, Brian C. Lane wrote:
On Thu, Jun 23, 2016 at 05:36:38PM +0200, Jiří Konečný wrote:
Hello guys,
I'm doing this bug https://bugzilla.redhat.com/show_bug.cgi?id=1113 207 and because of it I need to create new KS command for snapshot creation. Because kickstart is something with really stable API, I want to ask everyone before I'll implement something badly.
Possible solutions:
Adding --snapshot parameter to existing KS command
* It should be easier to implement. * Could be easier to find in documentation. * It's logically part of that storage type. * logvol command have big number of parameters now.
Adding standalone snapshot command
* Harder to implement but it's more general. * Easier to extend. * Easier to just add support for btrfs with additional required parameters and anything else in future and syntax will not change so much.
Personally I see the snapshot command as better choice but want to hear your idea.
I like the standalone snapshot command. The user doesn't need to know what's underneath it and could possibly do:
autopart --type=thinp snapshot --name=initial_install
Yeah - and also by having a separate command, we also get a namespace "for free", unlike if the snapshot functionality was piggybacking on an existing command, where all commands would need to be accordingly prefixed (--snapshot-foo, --snapshot--bar, etc.).
And then switching to btrfs would be as simple as using a different autopart type.
If used with non-autopart it will also need to sanity check their storage setup to make sure they are using something that supports snapshots.
I also agree with your comment in the bug, minimize changes to Anaconda and keep using /.
anaconda-devel@lists.stg.fedoraproject.org
-
Brian C. Lane -
Chris Lumens -
Jiří Konečný -
Martin Kolman