[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