+++ This bug was initially created as a clone of Bug #880243 +++

3. What is the nature and description of the request?

RHN Satellite generated kickstarts have the following default disk partitioning section present :

~~~
zerombr
clearpart --all
bootloader --location mbr
[..]
part /boot --fstype=ext3 --size=200 
part pv.01 --size=1000 --grow 
part swap --size=1000   --maxsize=2000 
volgroup myvg pv.01 
logvol / --vgname=myvg --name=rootvol --size=1000 --grow
~~~

When used to deploy hosts in a RHEV cluster this default section can destroy attached storage already in use within the RHEV environment.

4. Why does the customer need this? (List the business requirements here)

There is an instance where the customer used a RHN Satellite generated kickstart file to provision a RHEV host resulting in the corruption of a data storage domain and loss of multiple guests.

5. How would the customer like to achieve this? (List the functional
requirements here)

- By default all kickstart files generated by RHN Satellite should not destory LUNs already used by RHEV.  

6. For each functional requirement listed in question 5, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.

- Generate a fresh kickstart profile within RHN Satellite.
- Without editing the kickstart, redeploy a host that has access to LUNs used by RHEV.
- The host should be reinstalled using the local disks or LUNs not associated with RHEV.

7. Is there already an existing RFE upstream or in Red Hat bugzilla?
No.

8. Does the customer have any specific timeline dependencies?
No.

9. Is the sales team involved in this request and do they have any additional input?
No.

10. List any affected packages or components.
anaconda, if additional changes are required to the behaviour of clearpart --all etc.

11. Would the customer be able to assist in testing this functionality if
implemented?
Yes.

--- Additional comment from Stephen Herr on 2013-03-18 17:31:02 EDT ---

I think I need additional guidance on this bug. Satellite is essentially just a frontend to Cobbler, so if functionality is not available in Cobbler / Anaconda then there's not a lot we can do. My thoughts:

1) When someone creates a Kickstart Profile that translates down to a Cobbler Profile. This is when the kickstart file gets generated (mostly). A Kickstart / Cobbler Profile can be used multiple times across many different systems, so there is no way to know at Kickstart Profile creation time which hard drives we should use, which are LUNs, etc.

2) The 'clearpart --all' option is set at Kickstart Profile creation time. What we would probably really like is the ability to say "Only clear the partitions on sda and sdb, use them for the install process" or something similar. At the very least what we want to say is "don't clear the partitions on hdb" or similar. The way to do this is to specify which drives to clear the partitions on, like 'clearpart --all --drives=vda,vdb'. However specifically which [hsv]d[a-z] drives we want to clear will depend on the system in question, clearly not something that can be set at the Profile level.

3) When we schedule a kickstart for a particular system in Satellite, one of the things that happens is that we create a Cobbler System record. A Cobbler System record allows you to specify some things that are unique to the system, mostly networking-related. (https://github.com/cobbler/cobbler/wiki/Start%20Here#adding-systems) Unfortunately, there is no option here to specify the clearpart command.

4) Of course if the user knows of this issue and as a result wants to create a new Kickstart Profile for each of their servers that needs it, they can do so and can upload / modify the kickstart file all they want. No additional work is needed. We /could/ create a tool in the UI that helps them craft a clearpart line (the user would have to know in advance which system (probably singular) would use this Kickstart Profile and which disk(s) on that system are not LUNs), but it's a very small leap from knowing about the problem to knowing how to modify the kickstart file to fix it. However if the user is already aware of the issue then it would be much easier to simply disconnect the LUN before kickstarting, so I don't think anyone would actually do this.

5) The other option would be to have the default kickstart file have no clearpart option whatsoever. This would leave behind old partitions forever and only use up unallocated space (if any) for our install. This would probably cause the vast majority of kickstarts to fail. Probably not desired behavior.

6) If just a warning is sufficient, I could display a warning after each and every Kickstart Profile is created in the Satellite webui. However it can potentially be a very long time between Kickstart Profile creation and a given Kickstart event, so the user may have forgotten or it may be a different user entirely.

7) I can display a warning each and every time a system is Kickstarted through the *Satellite webui*. However there are other ways to kickstart systems directly through Cobbler that never hit the Satellite webui, those users would never see the warning.


It seems to me that the best I can do is to implement #7 here, just display a warning each and every time a user kickstarts a system through the Satellite webui. Is anyone aware of an Anaconda setting that could help? Cobbler options I have missed? Any way to actually implement the desired behavior? I don't see that Satellite can do much other than display a warning that may / may not be seen and may / may not be heeded.

--- Additional comment from Jan Pazdziora on 2013-03-19 04:34:20 EDT ---

Is this only a reprovisioning issue or also an issue with bare metal (re)provisionings?

If it is reprovisioning only issue, can't spacewalk-koan (?) probe the disks and tell someone what the layout is and what should be purged?

Why are the comments in this bugzilla so insanely wide?

--- Additional comment from Stephen Herr on 2013-03-19 08:41:16 EDT ---

(In reply to comment #9)
> Is this only a reprovisioning issue or also an issue with bare metal
> (re)provisionings?

It should be just a re-provisioning issue. If you have a bare metal machine with no OS then you couldn't have added a LUN to it yet.

> If it is reprovisioning only issue, can't spacewalk-koan (?) probe the disks
> and tell someone what the layout is and what should be purged?

Whether it can or not is not the issue. The issue is that even if it could, there's no way of changing the kickstart file at that point. This bit of the kickstart file is written at Cobbler Profile creation time, and there's no way to change it later. 

> Why are the comments in this bugzilla so insanely wide?

I don't know, I've noticed some bugs do this ever since they upgraded bugzilla versions.

--- Additional comment from Jan Pazdziora on 2013-03-19 08:58:52 EDT ---

(In reply to comment #10)
> 
> Whether it can or not is not the issue. The issue is that even if it could,
> there's no way of changing the kickstart file at that point. This bit of the
> kickstart file is written at Cobbler Profile creation time, and there's no
> way to change it later. 

So if instead of hardcoding that clearpart --all we put in some snippet, that wouldn't work?

--- Additional comment from Clifford Perry on 2013-03-19 10:15:49 EDT ---

So, my thoughts. 

We have 2 or 3 'stock' disk layout options for anaconda to use. 

During the kickstart profile creation wizard, we add a new page in the wizard, asking you to select which disk layout you want to use. One of which is the clear all partitions and install default layout [default]. 

The other is something like use only available free space /partition - which if not available will make the install fail. 

Some other option. 

Then, within WebUI, on the partitioning tab (rhn/kickstart/KickstartPartitionEdit.do?) 

it displays what is selected, but allows for an option to toggle to a new layout (from the 2 or 3 known stock options). 

Includes (which is not listed today) the clear partition options. So by default would show in this page:

zerombr
clearpart --all
bootloader --location mbr
part /boot --fstype=ext3 --size=200 
part pv.01 --size=1000 --grow 
part swap --size=1000   --maxsize=2000 
volgroup myvg pv.01 
logvol / --vgname=myvg --name=rootvol --size=1000 --grow

Or may the clearpart and zerombr toggles on the page for global options. 

Basically, anywhere we can allow you to select to clear all disks, there is some warning/note telling the end user what this option that anaconda obeys, does. 

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-options.html

I hope this helps. We cannot totally prevent users from doing bad-things, but can be more interactive and display WebUI warnings about kickstarts. I'm not in favor disrupting a kickstart or making it harder to use Satellite. In general from comment #8, I'm in favor of option #6 that was listed. I cannot baby-sit all customer interactions, nor do I want to seriously annoy established users who know how things work. At time of creating the profile, for me is the right place to add this. 

Cliff

--- Additional comment from Stephen Herr on 2013-03-19 11:18:17 EDT ---

Okay, I think after a long discussion we have defined three possible ways to
proceed on this bug.


1) Modify the Kickstart Profile pages to show additional warnings and draw extra
attention / add visibility to the currently-available ability to modify the
zerombr and clearpart lines of the kickstart file.

This option has a couple of problems. First and foremost, Kickstart Profiles may
be created a long time before (years potentially) a given kickstart event. The
user who creates the Kickstart Profile may be different from the user doing the
Kickstart. The chances that this would actually inform the correct people and/or
that they'd remember are slim.

In addition this reduces the generic nature of Kickstart Profiles. You would
have to know in advance specifically what machines you would use with the
profile, and know what their disk layout is. Any machine with a different disk
layout would require a separate Kickstart Profile.

Upsides:
Easy, not that different from what exists currently.
Safe, not making major changes to kickstart infrastructure.
Would apply to all kickstarts, not just kickstarts initiated from the webui.

Downsides:
Not sure it actually solves the problem (see above).
Antithetical to the generic nature of Kickstart Profiles (see above).


2) Modify the default settings to be more parameterized using cobbler snippets.
Add extra steps in the webui kickstart scheduling wizard to force the user to
either explicitly accept the defaults or to modify the disk layout to be more
appropriate for the kickstarting system.

Upsides: 
This is the most user-friendly and foolproof (if there is such a thing when it
comes to system administration) of the options.

Downsides:
It involves changing values that have been the defaults for a long time and
requires much tighter integration with Cobbler. Consequently there is
additional risk that we may not catch all of the potential problems with all of
the potential kickstart paths and end up introducing errors.
It is a lot of work.
It requires an extra step that is completely unnecessary for the *vast*
majority of kickstarts.
Doesn't help with non-webui kickstarts.


3) Display a warning at webui kickstart time if they are using the default
"destroy all partitions" options. Explain the risk, tell them to either remove
disks they don't want destroyed or change (through existing infrastructure) the
kickstart options.

Upsides:
Informs without being too intrusive.
Easy.
A safe change to make.

Downsides:
Not as foolproof as option #2.
Also doesn't help with non-webui kickstarts.
Also requires an extra step that is unnecessary for the majority of kickstarts.


Given the options above I'm leaning towards option #3 and away from option #1.
Option #2 sounds like a decent idea, but it's a lot of work / risk for a
potentially unnecessary change, especially if we implement #3 instead. Thoughts?