[lvm-devel] [PATCH 1/4] Move guts of pvcreate into library area - prep for vgcreate.

[Dave Wysochanski]

On Sun, 2008-11-30 at 04:26 +0000, Alasdair G Kergon wrote:
> I'm a bit bothered that too much code may be getting dumped into the library here
> wholesale rather than getting broken up into separate calls.
> 
> - I don't think the library should be prompting, that should remain at tools level
> and the interface should allow for that.
> -- maybe yes_no_prompt needs some global mode (anaconda would set) to control
> whether it does anything or simply defaults to the value given in an additional
> parameter 
> 

Why global mode - why not just set 'force' and '-y' for the API call?  I
think this was similar to Thomas's argument - he always envisioned '-ff'
and '-y' on things like pvcreate.

To be specific, in pvcreate we prompt if:
1) the device is already a PV
2) we find an MD superblock
(and of course the user has not given the '-ff' and '-y')

So if we don't want the yes_no_prompt() in the library, either the
library calls do not do these checks at all, or we duplicate the code in
the library.  Otherwise, we leave the yes_no_prompt() code in the
library and just set the options for the API call.

Note that we currently have yes_no_prompt() in the library for lvremove
and vgremove code paths.  The pvcreate/vgremove/lvremove paths might
also be a good area to talk about the error codes/handling and what the
API should look like.