* Re: [linux-lvm] [Yum-devel] [PATCH 4/2] fs snapshot plugin: add LVM tag to allow tools to link pre and post snapshots
2013-03-11 21:25 ` [linux-lvm] [PATCH 4/2] fs snapshot plugin: add LVM tag to allow tools to link pre and post snapshots Mike Snitzer
@ 2013-03-12 13:46 ` James Antill
2013-03-12 14:41 ` [linux-lvm] " Mike Snitzer
2013-03-12 15:00 ` [linux-lvm] [PATCH 4/2 v2] " Mike Snitzer
2013-03-12 18:16 ` [linux-lvm] [PATCH 4/2 v3] " Mike Snitzer
2 siblings, 1 reply; 13+ messages in thread
From: James Antill @ 2013-03-12 13:46 UTC (permalink / raw)
To: Mike Snitzer; +Cc: okozina, yum-devel, linux-lvm
On Mon, 2013-03-11 at 17:25 -0400, Mike Snitzer wrote:
> Add a "yum_fs_snapshot_<trans_id>_<origin_volume>" LVM tag to LVM-based
> snapshots (old or thinp). These tags will allow tools (e.g snapper) to
> link the pre and post snapshot volumes together.
>
> yum_fs_snapshot_trans_id() uses the first 16 digits of the hash() of the
> rpm TransactionSet instance to establish a unique id that is common to
> both the pretrans_hook() and posttrans_hook() -- this is quite the hack;
> I'm open to using other (more future-proof) methods.
Esp. as hash(ts.ts) is just the address of the pointer for that object
in C.
It depends what you want, I guess.
My first guess is that you'd want roughly what the rest of yum uses,
so:
rpmdbv = self.rpmdb.simpleVersion(main_only=True)[0]
frpmdbv = self.tsInfo.futureRpmDBVersion()
...except things like yum history also get the real "future" rpmdbv
after the transaction happens, which this can't (unless we can add the
tags in post_trans? -- and then there are problems about what happens if
we don't get there).
This should identify the state of the system, and what will happen well
enough ... but that means if the user does:
yum blah
yum history undo last
yum history undo last
yum history undo last
...you'll have multiple snapshots with the same tag (as the system will
be in the same states from the packaging POV -- is this what you want?).
The other alternative is to just use a stored time.time(), of the first
snapshot (or maybe that and the start rpmdbv?).
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [linux-lvm] [PATCH 4/2] fs snapshot plugin: add LVM tag to allow tools to link pre and post snapshots
2013-03-12 13:46 ` [linux-lvm] [Yum-devel] " James Antill
@ 2013-03-12 14:41 ` Mike Snitzer
2013-03-12 16:41 ` James Antill
0 siblings, 1 reply; 13+ messages in thread
From: Mike Snitzer @ 2013-03-12 14:41 UTC (permalink / raw)
To: James Antill; +Cc: okozina, yum-devel, linux-lvm
On Tue, Mar 12 2013 at 9:46am -0400,
James Antill <james@fedoraproject.org> wrote:
> On Mon, 2013-03-11 at 17:25 -0400, Mike Snitzer wrote:
> > Add a "yum_fs_snapshot_<trans_id>_<origin_volume>" LVM tag to LVM-based
> > snapshots (old or thinp). These tags will allow tools (e.g snapper) to
> > link the pre and post snapshot volumes together.
> >
> > yum_fs_snapshot_trans_id() uses the first 16 digits of the hash() of the
> > rpm TransactionSet instance to establish a unique id that is common to
> > both the pretrans_hook() and posttrans_hook() -- this is quite the hack;
> > I'm open to using other (more future-proof) methods.
>
> Esp. as hash(ts.ts) is just the address of the pointer for that object
> in C.
> It depends what you want, I guess.
I couldn't figure out how to store anything in pretrans_hook() and
retrieve it in posttrans_hook(). Use of a global caused the plugin to
fail silently.
All I was going for was a unique number that was the same in both
pretrans_hook() and posttrans_hook().
> My first guess is that you'd want roughly what the rest of yum uses,
> so:
>
> rpmdbv = self.rpmdb.simpleVersion(main_only=True)[0]
> frpmdbv = self.tsInfo.futureRpmDBVersion()
>
> ...except things like yum history also get the real "future" rpmdbv
> after the transaction happens, which this can't (unless we can add the
> tags in post_trans? -- and then there are problems about what happens if
> we don't get there).
>
> This should identify the state of the system, and what will happen well
> enough ... but that means if the user does:
>
> yum blah
> yum history undo last
> yum history undo last
> yum history undo last
>
> ...you'll have multiple snapshots with the same tag (as the system will
> be in the same states from the packaging POV -- is this what you want?).
> The other alternative is to just use a stored time.time(), of the first
> snapshot (or maybe that and the start rpmdbv?).
I like the idea of using the actual future rpmDB version; but as you
note it won't be unique on its own if you undo a transaction. SO this
is the incremental change I came up with. I'll post v2 of the 4/2 patch
with these chnages folded in:
diff --git a/plugins/fs-snapshot/fs-snapshot.py b/plugins/fs-snapshot/fs-snapshot.py
index 22582aa..1625564 100644
--- a/plugins/fs-snapshot/fs-snapshot.py
+++ b/plugins/fs-snapshot/fs-snapshot.py
@@ -43,11 +43,14 @@ lvm_key = "create_lvm_snapshot"
dm_snapshot_merge_checked = 0
dm_snapshot_merge_support = 0
-def yum_fs_snapshot_trans_id(ts):
+def yum_fs_snapshot_trans_id(conduit):
# return pseudo yum transaction id string
# this string is identical for both {pre,post}trans_hook
- yum_ts_hash = "%d" % abs(hash(ts.ts))
- return "yum_fs_snapshot_" + yum_ts_hash[:16]
+ tsInfo = conduit.getTsInfo()
+ # using hash of tsInfo purely to get unique number that isn't tied to rpmDB
+ tsInfo_hash = "%d" % (abs(hash(tsInfo)))
+ frpmdbv = tsInfo.futureRpmDBVersion()
+ return "yum_fs_snapshot_%s_%s" % (tsInfo_hash[:8], frpmdbv)
def _fail(msg):
raise PluginYumExit(msg)
@@ -262,8 +265,6 @@ def _create_lvm_snapshot(conduit, snapshot_tag, volume):
mntpnt = volume["mntpnt"]
kern_inst = True # Default to saying it might be.
ts = conduit._base.rpmdb.readOnlyTS()
- # save pseudo yum transaction id
- yum_trans_id = yum_fs_snapshot_trans_id(ts)
kern_pkgtup = yum.misc.get_running_kernel_pkgtup(ts)
del ts
if kern_pkgtup is not None:
@@ -299,6 +300,7 @@ def _create_lvm_snapshot(conduit, snapshot_tag, volume):
return 1
# Add tag to allow other tools (e.g. snapper) to link pre
# and post snapshot LVs together
+ yum_trans_id = yum_fs_snapshot_trans_id(conduit)
if add_lvm_tag_to_snapshot(conduit, yum_trans_id + "_" + orig_lvname, snap_device):
return 1
return 2
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [linux-lvm] [PATCH 4/2] fs snapshot plugin: add LVM tag to allow tools to link pre and post snapshots
2013-03-12 14:41 ` [linux-lvm] " Mike Snitzer
@ 2013-03-12 16:41 ` James Antill
2013-03-12 18:09 ` Mike Snitzer
0 siblings, 1 reply; 13+ messages in thread
From: James Antill @ 2013-03-12 16:41 UTC (permalink / raw)
To: Mike Snitzer; +Cc: okozina, yum-devel, linux-lvm
On Tue, 2013-03-12 at 10:41 -0400, Mike Snitzer wrote:
> On Tue, Mar 12 2013 at 9:46am -0400,
> James Antill <james@fedoraproject.org> wrote:
>
> > On Mon, 2013-03-11 at 17:25 -0400, Mike Snitzer wrote:
> > > Add a "yum_fs_snapshot_<trans_id>_<origin_volume>" LVM tag to LVM-based
> > > snapshots (old or thinp). These tags will allow tools (e.g snapper) to
> > > link the pre and post snapshot volumes together.
> > >
> > > yum_fs_snapshot_trans_id() uses the first 16 digits of the hash() of the
> > > rpm TransactionSet instance to establish a unique id that is common to
> > > both the pretrans_hook() and posttrans_hook() -- this is quite the hack;
> > > I'm open to using other (more future-proof) methods.
> >
> > Esp. as hash(ts.ts) is just the address of the pointer for that object
> > in C.
> > It depends what you want, I guess.
>
> I couldn't figure out how to store anything in pretrans_hook() and
> retrieve it in posttrans_hook(). Use of a global caused the plugin to
> fail silently.
Using globals should work, the only real problem is if some python API
creates multiple YumBase() instances (but although we've worried about
that, nothing has ever really done it AFAIK).
The common way is to just stuff something unique in the yum base object
(base.__plugin_fssnap_whatever = blah).
[...]
> I like the idea of using the actual future rpmDB version; but as you
> note it won't be unique on its own if you undo a transaction. SO this
> is the incremental change I came up with. I'll post v2 of the 4/2 patch
> with these chnages folded in:
[...]
> -def yum_fs_snapshot_trans_id(ts):
> +def yum_fs_snapshot_trans_id(conduit):
> # return pseudo yum transaction id string
> # this string is identical for both {pre,post}trans_hook
> - yum_ts_hash = "%d" % abs(hash(ts.ts))
> - return "yum_fs_snapshot_" + yum_ts_hash[:16]
> + tsInfo = conduit.getTsInfo()
> + # using hash of tsInfo purely to get unique number that isn't tied to rpmDB
> + tsInfo_hash = "%d" % (abs(hash(tsInfo)))
> + frpmdbv = tsInfo.futureRpmDBVersion()
> + return "yum_fs_snapshot_%s_%s" % (tsInfo_hash[:8], frpmdbv)
I still worry about how unique "abs(hash(ts.ts))" will be over multiple
runs ... is the reason for not using a timestamp just that you don't
know where to store it?
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [linux-lvm] [PATCH 4/2] fs snapshot plugin: add LVM tag to allow tools to link pre and post snapshots
2013-03-12 16:41 ` James Antill
@ 2013-03-12 18:09 ` Mike Snitzer
2013-03-12 19:52 ` [linux-lvm] [Yum-devel] " James Antill
0 siblings, 1 reply; 13+ messages in thread
From: Mike Snitzer @ 2013-03-12 18:09 UTC (permalink / raw)
To: James Antill; +Cc: okozina, yum-devel, linux-lvm
On Tue, Mar 12 2013 at 12:41pm -0400,
James Antill <james@fedoraproject.org> wrote:
> On Tue, 2013-03-12 at 10:41 -0400, Mike Snitzer wrote:
> > On Tue, Mar 12 2013 at 9:46am -0400,
> > James Antill <james@fedoraproject.org> wrote:
> >
> > > On Mon, 2013-03-11 at 17:25 -0400, Mike Snitzer wrote:
> > > > Add a "yum_fs_snapshot_<trans_id>_<origin_volume>" LVM tag to LVM-based
> > > > snapshots (old or thinp). These tags will allow tools (e.g snapper) to
> > > > link the pre and post snapshot volumes together.
> > > >
> > > > yum_fs_snapshot_trans_id() uses the first 16 digits of the hash() of the
> > > > rpm TransactionSet instance to establish a unique id that is common to
> > > > both the pretrans_hook() and posttrans_hook() -- this is quite the hack;
> > > > I'm open to using other (more future-proof) methods.
> > >
> > > Esp. as hash(ts.ts) is just the address of the pointer for that object
> > > in C.
> > > It depends what you want, I guess.
> >
> > I couldn't figure out how to store anything in pretrans_hook() and
> > retrieve it in posttrans_hook(). Use of a global caused the plugin to
> > fail silently.
>
> Using globals should work, the only real problem is if some python API
> creates multiple YumBase() instances (but although we've worried about
> that, nothing has ever really done it AFAIK).
Just adding a single global caused the plugin to fail: global foo = None
> The common way is to just stuff something unique in the yum base object
> (base.__plugin_fssnap_whatever = blah).
OK.
> > I like the idea of using the actual future rpmDB version; but as you
> > note it won't be unique on its own if you undo a transaction. SO this
> > is the incremental change I came up with. I'll post v2 of the 4/2 patch
> > with these chnages folded in:
> [...]
> > -def yum_fs_snapshot_trans_id(ts):
> > +def yum_fs_snapshot_trans_id(conduit):
> > # return pseudo yum transaction id string
> > # this string is identical for both {pre,post}trans_hook
> > - yum_ts_hash = "%d" % abs(hash(ts.ts))
> > - return "yum_fs_snapshot_" + yum_ts_hash[:16]
> > + tsInfo = conduit.getTsInfo()
> > + # using hash of tsInfo purely to get unique number that isn't tied to rpmDB
> > + tsInfo_hash = "%d" % (abs(hash(tsInfo)))
> > + frpmdbv = tsInfo.futureRpmDBVersion()
> > + return "yum_fs_snapshot_%s_%s" % (tsInfo_hash[:8], frpmdbv)
>
> I still worry about how unique "abs(hash(ts.ts))" will be over multiple
> runs ... is the reason for not using a timestamp just that you don't
> know where to store it?
abs(hash(tsInfo)) should be sufficiently unique when coupled with
futureRpmDBVersion(). But yeah, I didn't know how to store the timestamp.
I'll send a simpler v3 now.. thanks for your help!
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [linux-lvm] [Yum-devel] [PATCH 4/2] fs snapshot plugin: add LVM tag to allow tools to link pre and post snapshots
2013-03-12 18:09 ` Mike Snitzer
@ 2013-03-12 19:52 ` James Antill
2013-03-12 20:30 ` [linux-lvm] " Mike Snitzer
0 siblings, 1 reply; 13+ messages in thread
From: James Antill @ 2013-03-12 19:52 UTC (permalink / raw)
To: Mike Snitzer; +Cc: okozina, yum-devel, linux-lvm
On Tue, 2013-03-12 at 14:09 -0400, Mike Snitzer wrote:
> On Tue, Mar 12 2013 at 12:41pm -0400,
> James Antill <james@fedoraproject.org> wrote:
> > Using globals should work, the only real problem is if some python API
> > creates multiple YumBase() instances (but although we've worried about
> > that, nothing has ever really done it AFAIK).
>
> Just adding a single global caused the plugin to fail: global foo = None
That's a syntax error, python is much more annoying about globals than
perl (or pretty much any other language :).
Also note that you can pass "-d 9" (maybe even just -v) to yum get the
traceback from plugins, we suppress them on load, by default, as that's
much better for users.
> abs(hash(tsInfo)) should be sufficiently unique when coupled with
> futureRpmDBVersion().
Probably, I was just worried that in some cases it might have similar
addresses (given it's doing mostly the same work each time, without some
kind of memory randomization it might well be at an identical memory
address).
> But yeah, I didn't know how to store the timestamp.
>
> I'll send a simpler v3 now.. thanks for your help!
Looks fine, I've pushed it and built it in rawhide (on F19 branch too).
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [linux-lvm] [PATCH 4/2] fs snapshot plugin: add LVM tag to allow tools to link pre and post snapshots
2013-03-12 19:52 ` [linux-lvm] [Yum-devel] " James Antill
@ 2013-03-12 20:30 ` Mike Snitzer
0 siblings, 0 replies; 13+ messages in thread
From: Mike Snitzer @ 2013-03-12 20:30 UTC (permalink / raw)
To: James Antill; +Cc: okozina, yum-devel, linux-lvm
On Tue, Mar 12 2013 at 3:52pm -0400,
James Antill <james@fedoraproject.org> wrote:
> On Tue, 2013-03-12 at 14:09 -0400, Mike Snitzer wrote:
> > On Tue, Mar 12 2013 at 12:41pm -0400,
> > James Antill <james@fedoraproject.org> wrote:
> > > Using globals should work, the only real problem is if some python API
> > > creates multiple YumBase() instances (but although we've worried about
> > > that, nothing has ever really done it AFAIK).
> >
> > Just adding a single global caused the plugin to fail: global foo = None
>
> That's a syntax error, python is much more annoying about globals than
> perl (or pretty much any other language :).
> Also note that you can pass "-d 9" (maybe even just -v) to yum get the
> traceback from plugins, we suppress them on load, by default, as that's
> much better for users.
OK, thanks.
> > But yeah, I didn't know how to store the timestamp.
> >
> > I'll send a simpler v3 now.. thanks for your help!
>
> Looks fine, I've pushed it and built it in rawhide (on F19 branch too).
Much appreciated!
^ permalink raw reply [flat|nested] 13+ messages in thread
* [linux-lvm] [PATCH 4/2 v2] fs snapshot plugin: add LVM tag to allow tools to link pre and post snapshots
2013-03-11 21:25 ` [linux-lvm] [PATCH 4/2] fs snapshot plugin: add LVM tag to allow tools to link pre and post snapshots Mike Snitzer
2013-03-12 13:46 ` [linux-lvm] [Yum-devel] " James Antill
@ 2013-03-12 15:00 ` Mike Snitzer
2013-03-12 18:16 ` [linux-lvm] [PATCH 4/2 v3] " Mike Snitzer
2 siblings, 0 replies; 13+ messages in thread
From: Mike Snitzer @ 2013-03-12 15:00 UTC (permalink / raw)
To: James Antill; +Cc: okozina, yum-devel, linux-lvm
Add a "yum_fs_snapshot_<trans_id>_<origin_volume>" LVM tag to LVM-based
snapshots (old or thinp). These tags will allow tools (e.g snapper) to
link the pre and post snapshot volumes together.
yum_fs_snapshot_trans_id() uses the first 8 digits of the hash() of the
tsInfo instance to establish a unique id that is common to both the
pretrans_hook() and posttrans_hook() -- this is done because the
futureRpmDBVersion(), also included in the trans_id, will not be unique
over time if transactions are rolled back (e.g.: yum history undo last)
Factored out add_lvm_tag_to_snapshot() to allow for reuse.
Signed-off-by: Mike Snitzer <msnitzer@fedoraproject.org>
---
plugins/fs-snapshot/fs-snapshot.py | 30 ++++++++++++++++++++++++------
1 file changed, 24 insertions(+), 6 deletions(-)
v2: include the futureRpmDBVersion() in the yum_fs_snapshot_trans_id
diff --git a/plugins/fs-snapshot/fs-snapshot.py b/plugins/fs-snapshot/fs-snapshot.py
index 32a1f17..1625564 100644
--- a/plugins/fs-snapshot/fs-snapshot.py
+++ b/plugins/fs-snapshot/fs-snapshot.py
@@ -43,6 +43,15 @@ lvm_key = "create_lvm_snapshot"
dm_snapshot_merge_checked = 0
dm_snapshot_merge_support = 0
+def yum_fs_snapshot_trans_id(conduit):
+ # return pseudo yum transaction id string
+ # this string is identical for both {pre,post}trans_hook
+ tsInfo = conduit.getTsInfo()
+ # using hash of tsInfo purely to get unique number that isn't tied to rpmDB
+ tsInfo_hash = "%d" % (abs(hash(tsInfo)))
+ frpmdbv = tsInfo.futureRpmDBVersion()
+ return "yum_fs_snapshot_%s_%s" % (tsInfo_hash[:8], frpmdbv)
+
def _fail(msg):
raise PluginYumExit(msg)
@@ -221,6 +230,14 @@ def _create_btrfs_snapshot(conduit, snapshot_tag, volume):
return 1
return 2
+def add_lvm_tag_to_snapshot(conduit, tag, snap_volume):
+ p = Popen(["/sbin/lvchange", "--addtag", tag, snap_volume],
+ stdout=PIPE, stderr=PIPE)
+ err = p.wait()
+ if err:
+ conduit.error(1, "fs-snapshot: couldn't add tag to snapshot: %s" %
+ snap_volume)
+
def _create_lvm_snapshot(conduit, snapshot_tag, volume):
"""
Create LVM snapshot LV and tag it with $snapshot_tag.
@@ -260,6 +277,7 @@ def _create_lvm_snapshot(conduit, snapshot_tag, volume):
" being altered /boot may need to be manually restored\n"
" in the event that a system rollback proves necessary.\n")
+ orig_lvname = device.split('/')[3]
snap_device = device + "_" + snapshot_tag
snap_lvname = snap_device.split('/')[3]
conduit.info(1, "fs-snapshot: snapshotting %s (%s): %s" %
@@ -278,12 +296,12 @@ def _create_lvm_snapshot(conduit, snapshot_tag, volume):
# Add tag ($snapshot_tag) to snapshot LV
# - should help facilitate merge of all snapshot LVs created
# by a yum transaction, e.g.: lvconvert --merge @snapshot_tag
- p = Popen(["/sbin/lvchange", "--addtag", snapshot_tag, snap_device],
- stdout=PIPE, stderr=PIPE)
- err = p.wait()
- if err:
- conduit.error(1, "fs-snapshot: couldn't add tag to snapshot: %s" %
- snap_device)
+ if add_lvm_tag_to_snapshot(conduit, snapshot_tag, snap_device):
+ return 1
+ # Add tag to allow other tools (e.g. snapper) to link pre
+ # and post snapshot LVs together
+ yum_trans_id = yum_fs_snapshot_trans_id(conduit)
+ if add_lvm_tag_to_snapshot(conduit, yum_trans_id + "_" + orig_lvname, snap_device):
return 1
return 2
^ permalink raw reply related [flat|nested] 13+ messages in thread* [linux-lvm] [PATCH 4/2 v3] fs snapshot plugin: add LVM tag to allow tools to link pre and post snapshots
2013-03-11 21:25 ` [linux-lvm] [PATCH 4/2] fs snapshot plugin: add LVM tag to allow tools to link pre and post snapshots Mike Snitzer
2013-03-12 13:46 ` [linux-lvm] [Yum-devel] " James Antill
2013-03-12 15:00 ` [linux-lvm] [PATCH 4/2 v2] " Mike Snitzer
@ 2013-03-12 18:16 ` Mike Snitzer
2 siblings, 0 replies; 13+ messages in thread
From: Mike Snitzer @ 2013-03-12 18:16 UTC (permalink / raw)
To: James Antill; +Cc: okozina, yum-devel, linux-lvm
Add a "yum_fs_snapshot_pre_lv_name=<pre_snapshot_lv>" LVM tag to the
post transaction LVM-based snapshot (old or thinp). This tag will
allow tools (e.g snapper) to link the pre and post snapshot volumes
together.
Factored out add_lvm_tag_to_snapshot() to allow for reuse.
Signed-off-by: Mike Snitzer <msnitzer@fedoraproject.org>
---
plugins/fs-snapshot/fs-snapshot.py | 28 ++++++++++++++++++++++------
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/plugins/fs-snapshot/fs-snapshot.py b/plugins/fs-snapshot/fs-snapshot.py
index 32a1f17..38496c5 100644
--- a/plugins/fs-snapshot/fs-snapshot.py
+++ b/plugins/fs-snapshot/fs-snapshot.py
@@ -221,6 +221,14 @@ def _create_btrfs_snapshot(conduit, snapshot_tag, volume):
return 1
return 2
+def add_lvm_tag_to_snapshot(conduit, tag, snap_volume):
+ p = Popen(["/sbin/lvchange", "--addtag", tag, snap_volume],
+ stdout=PIPE, stderr=PIPE)
+ err = p.wait()
+ if err:
+ conduit.error(1, "fs-snapshot: couldn't add tag to snapshot: %s" %
+ snap_volume)
+
def _create_lvm_snapshot(conduit, snapshot_tag, volume):
"""
Create LVM snapshot LV and tag it with $snapshot_tag.
@@ -278,13 +287,15 @@ def _create_lvm_snapshot(conduit, snapshot_tag, volume):
# Add tag ($snapshot_tag) to snapshot LV
# - should help facilitate merge of all snapshot LVs created
# by a yum transaction, e.g.: lvconvert --merge @snapshot_tag
- p = Popen(["/sbin/lvchange", "--addtag", snapshot_tag, snap_device],
- stdout=PIPE, stderr=PIPE)
- err = p.wait()
- if err:
- conduit.error(1, "fs-snapshot: couldn't add tag to snapshot: %s" %
- snap_device)
+ if add_lvm_tag_to_snapshot(conduit, snapshot_tag, snap_device):
return 1
+ if conduit._base.__plugin_fs_snapshot_post_snapshot_tag == snapshot_tag:
+ # Add tag to allow other tools (e.g. snapper) to link pre
+ # and post snapshot LVs together
+ pre_snap_lv_name = "%s_%s" % (device, conduit._base.__plugin_fs_snapshot_pre_snapshot_tag)
+ pre_snapshot_tag = "yum_fs_snapshot_pre_lv_name=" + pre_snap_lv_name
+ if add_lvm_tag_to_snapshot(conduit, pre_snapshot_tag, snap_device):
+ return 1
return 2
def create_snapshots(conduit):
@@ -295,6 +306,10 @@ def create_snapshots(conduit):
"""
# common snapshot tag format: yum_${year}${month}${day}${hour}${minute}${sec}
snapshot_tag = "yum_" + time.strftime("%Y%m%d%H%M%S")
+ if not conduit._base.__plugin_fs_snapshot_pre_snapshot_tag:
+ conduit._base.__plugin_fs_snapshot_pre_snapshot_tag = snapshot_tag
+ else:
+ conduit._base.__plugin_fs_snapshot_post_snapshot_tag = snapshot_tag
volumes = get_volumes(conduit)
for volume in volumes:
@@ -306,6 +321,8 @@ def create_snapshots(conduit):
conduit.registerPackageName("yum-plugin-fs-snapshot")
def pretrans_hook(conduit):
+ conduit._base.__plugin_fs_snapshot_pre_snapshot_tag = None
+ conduit._base.__plugin_fs_snapshot_post_snapshot_tag = None
create_snapshots(conduit)
def posttrans_hook(conduit):
^ permalink raw reply related [flat|nested] 13+ messages in thread