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 /.

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.