[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [PATCH 1/2] Add booleans indicating queued operations on formats.



On 03/31/2009 08:01 AM, David Lehman wrote:
On Tue, 2009-03-31 at 19:20 +0200, Radek Vykydal wrote:
David Lehman wrote:
On Mon, 2009-03-30 at 18:18 -1000, David Cantrell wrote:

---
  storage/formats/__init__.py |   30 ++++++++++++++++++++++++++++++
  1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/storage/formats/__init__.py b/storage/formats/__init__.py
index 9ec0999..60be55e 100644
--- a/storage/formats/__init__.py
+++ b/storage/formats/__init__.py
@@ -149,6 +149,9 @@ class DeviceFormat(object):
      _minSize = 0                        # minimum size in MB
      _dump = False
      _check = False
+    _wantFormat = False

wantFormat is equivalent to 'not self.exists'

Is it true for existing partitions we want to format?

It should be. We probably do not handle correctly the case of re-editing
a preexisting partition and unchecking 'format' after having checked it
in the initial edit. In this case we should use the device tree to look
up the ActionDestroyFormat and ActionCreateFormat and cancel them both.

I see the new want* properties more as a place to store information for UI.
When I was thinking about how to fix UI edit flow (multiple editing) of
existing
partitions, I was trying another approach - to store original (in the
sense of UI)
format in device instance attribute or ui (in deviceinstance-keyed dict)
and create
the dialog based on actual device format and stored original format, but
it started
to become too clumsy and complicated.

I wanted to achieve that for existing partitions, re-edit would mean
starting
from the same point (preexisting format) so that you could e.g. decide
to migreate
(from original fs) instead of format when reediting the partition - this
would also
require canceling of format action planned in previous edit.

Right -- this is something we would need to do in any case if we have
scheduled a format action that we do not want to actually execute. For
new devices we can just schedule more actions and they get sorted out by
DeviceTree.pruneActions, but it has the same effect.

What's funny is that the UI flow in the code wasn't entirely obvious to me until after I talked to dlehman in IRC about why the format was getting a new instance each time the dialog box ran. The problem I was trying to solve was what Radek was describing, but the wrong approach.

I've reworked the patch to remove the wantFormat, wantMigrate, and wantResize flags. I'm now using what we already had. The thing I had to do was modify how fmt_class() is being called so we carry over the values we need.

New patches will be posted soon, including fixes for RAID and LVM if I determine those are needed.

Dave and Radek, thanks for the feedback.

--
David Cantrell <dcantrell redhat com>
Red Hat / Honolulu, HI


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]