[blivet] Add support for FBA EDEV/EAV installation. (#885957)
Peter Oberparleiter
oberpar at linux.vnet.ibm.com
Fri Aug 9 10:24:57 UTC 2013
(Resend due to mailing list reject)
David Lehman wrote:
> On Mon, 2013-06-10 at 16:03 +0530, Nageswara R Sastry wrote:
>> >> --- a/blivet/devices.py
>> >> +++ b/blivet/devices.py
>> >> @@ -1484,15 +1484,16 @@ class PartitionDevice(StorageDevice):
>> >> def _create(self):
>> >> """ Create the device. """
>> >> log_method_call(self, self.name, status=self.status)
>> >> - self.disk.format.addPartition(self.partedPartition)
>> >> + # Do not create partition on LDL formatted
>> >> + if not self.disk.format.isLDL():
>> >> + self.disk.format.addPartition(self.partedPartition)
>> >
>> >So, what -- we're just going to silently not add a partition we have
>> >already planned to add? This isn't right.
>>
>> FBA disks already have implicit partition and adding a new partition
>> is not
>> possible.
>
> Then we should ensure that nothing ever attempts to add a partition to
> one of these devices at all instead of silently ignoring the request
> after it is made. Some testing on your end could reveal whether any
> change is needed to address this concern. Regardless, the above change
> is not acceptable.
Taking back a step, the situation is that currently Anaconda can't cope
with disks that have an unalterable partition table. Admittedly, the
concept of such partitions is somewhat strange in itself, but
unfortunately for mainframe Linux this is a reality. What is also a
reality is that there are users that want to be able to use Anaconda
with this type of devices so we need to find a solution for this.
We had initially identified two main approaches to achieve this goal:
1) Change Anaconda to not issue any partition modifications for FBA
devices (as you are suggesting above)
2) Have Parted (and the associated Anaconda code) accept partition
modifications for FBA devices as long as the result is compatible with
the one implicit partition.
While assessing the options, we found that approach 1), while being the
cleanest approach, seemed also the most intrusive one. The assumption
that partitions can be changed appears to be integrated so deeply into
Anaconda design and implementation that attempts to alter it would
result in a significant amount of modifications all over the place and
might even require changing the overall code flow for partitioning.
This type of change holds a high chance for introducing bugs and
breaking functionality for all users, not just those on mainframe Linux.
There's also the danger that the result would be a different workflow
for users installing on mainframe Linux when compared to other
platforms. These are effects that we'd like to avoid.
Option 2) on the other hand seemed to be much less intrusive: Existing
Anaconda assumptions don't need to be challenged for this very
particular device type which is of interest for only a minority of
users. When done right, this should have no effect on non-mainframe
Anaconda users at all.
That said I fully agree with cleaning up the patches themselves in the
concrete areas that you identified in some of your other comments. I'll
leave it to Nageswara to reply to/act on these.
Regards,
Peter Oberparleiter
--
Peter Oberparleiter
Linux on System z Development - IBM Germany
More information about the anaconda-patches
mailing list