add posibility to use 'autopart' or 'part' in redhat's kickstart #474

Merged
merged 1 commit into from May 9, 2013

Conversation

Projects
None yet
6 participants
@faja
Contributor

faja commented May 9, 2013

'autopart' (an option in redhat's kickstart) is cool, but if my disk has 2T of space, after installation there will be 50G of root partition and 1.5T of /home, and it's not what i want.

# df -h
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/vg_autopart1-lv_root   50G  775M   46G   2% /
/dev/mapper/vg_autopart1-lv_home  1.6T  197M  1.5T   1% /home

Changes allow to manually set size of root and swap partition or to use autopart (default).

We can create two(or more) models with different partitions, based on red hat template, eg:

  • for phisical servers
    • 16G /
    • 8G swap
  • for virtual servers
    • 4G /
    • no swap

slippycheeze added a commit that referenced this pull request May 9, 2013

Merge pull request #474 from faja/feature/add_part_in_redhat_model
add posibility to use 'autopart' or 'part' in redhat's kickstart

@slippycheeze slippycheeze merged commit 1cce71e into puppetlabs:master May 9, 2013

@tjmcs

This comment has been minimized.

Show comment Hide comment
@tjmcs

tjmcs May 9, 2013

I know that this pull request has already been merged, but does it change the default behavior that users of the Red Hat model would have experienced previous to the merge of this pull request? If so, shouldn't this be noted somewhere (or, perhaps, even submitted as a separate model instead of changing the behavior of the default Red Hat model...something similar is why the "ubuntu_precise_ip_pool" model was constructed, after all)? Of course, if this is changing the default behavior for this model (asking users to specify whether or not they want to auto partition and, if not, what the partitioning plan should be) then we probably need to discuss the change somewhere (and perhaps even carry the same change out to the other model templates). Personally, I would have been much happier with creating a custom model for this purpose (rather than changing the behavior of the top-level Red Hat model)...

tjmcs commented May 9, 2013

I know that this pull request has already been merged, but does it change the default behavior that users of the Red Hat model would have experienced previous to the merge of this pull request? If so, shouldn't this be noted somewhere (or, perhaps, even submitted as a separate model instead of changing the behavior of the default Red Hat model...something similar is why the "ubuntu_precise_ip_pool" model was constructed, after all)? Of course, if this is changing the default behavior for this model (asking users to specify whether or not they want to auto partition and, if not, what the partitioning plan should be) then we probably need to discuss the change somewhere (and perhaps even carry the same change out to the other model templates). Personally, I would have been much happier with creating a custom model for this purpose (rather than changing the behavior of the top-level Red Hat model)...

@slippycheeze

This comment has been minimized.

Show comment Hide comment
@slippycheeze

slippycheeze May 9, 2013

Contributor

I know that this pull request has already been merged, but does it change the default behavior that users of the Red Hat model would have experienced previous to the merge of this pull request?

Nope.

Contributor

slippycheeze commented May 9, 2013

I know that this pull request has already been merged, but does it change the default behavior that users of the Red Hat model would have experienced previous to the merge of this pull request?

Nope.

@tjmcs

This comment has been minimized.

Show comment Hide comment
@tjmcs

tjmcs May 9, 2013

Perhaps you could elaborate? How does one use the changes in this pull request to specify a partitioning plan if Razor isn't asking you for the details? Also, if there is no real change, should the same be done for the other models we support (allowing for either auto-partitioning or a partitioning plan)? What happens if someone decides that they really want more than two or three partitions? Do we then need yet another model to support that more complex partitioning plan?

I just don't see this being very maintainable over time (if we're going to start modifying a minimal model in order to support a lot of additional user requirements for a more complex install process)...

tjmcs commented May 9, 2013

Perhaps you could elaborate? How does one use the changes in this pull request to specify a partitioning plan if Razor isn't asking you for the details? Also, if there is no real change, should the same be done for the other models we support (allowing for either auto-partitioning or a partitioning plan)? What happens if someone decides that they really want more than two or three partitions? Do we then need yet another model to support that more complex partitioning plan?

I just don't see this being very maintainable over time (if we're going to start modifying a minimal model in order to support a lot of additional user requirements for a more complex install process)...

@slippycheeze

This comment has been minimized.

Show comment Hide comment
@slippycheeze

slippycheeze May 9, 2013

Contributor

Perhaps you could elaborate?

Sure. I thought the code was pretty clear, but anyway: the default
behaviour is to use autopart, just like the code did before. Users
who don't take any specific action and simply accept the default
values will get the same outcome they would before the code was
committed.

Users who do specify custom partition sizes get custom partition
sizes, but they need to explicitly decide not to use the default,
automatic, partitioning.

Also, if there is no real change, should the same be done for the other models we support (allowing for either auto-partitioning or a partitioning plan)?

Probably, although there being no actual standard layout specification
between platforms, non-EL models will need different code and
different options. (Unless someone fancies trying to abstract that,
which I don't think would be a good investment.)

What happens if someone decides that they really want more than two or three partitions? Do we then need yet another model to support that more complex partitioning plan?

I don't see why they wouldn't simply extend the existing set of
questions to cover their needs.

I just don't see this being very maintainable over time (if we're going to start modifying a minimal model in order to support a lot of additional user requirements for a more complex install process)...

No, I agree. I think that the notion that the models should contain
and abstract all the configuration details of an OS install is
probably flawed, ultimately, because it will grow to be equal in scope
to the underlying tool. That is, ultimately someone is likely to want
every option that you can specify to kickstart, so the set of
questions that Razor offered would be identically equal to the set of
options you can enter in a kickstart file.

With that in mind, I think the long term strategy is probably to allow
users to easily provide their own modifications to the kickstart (or
preseed, or whatever) file directly, rather than having to ask Razor
to do that for them.

However, since that is not even on the roadmap at the moment, this is
a clear quality of life improvement, it is compatible with existing
behaviour by default, and it doesn't introduce a significant amount of
code that makes the project harder to maintain, I couldn't see any
reason to refuse to merge it in the interim.

Contributor

slippycheeze commented May 9, 2013

Perhaps you could elaborate?

Sure. I thought the code was pretty clear, but anyway: the default
behaviour is to use autopart, just like the code did before. Users
who don't take any specific action and simply accept the default
values will get the same outcome they would before the code was
committed.

Users who do specify custom partition sizes get custom partition
sizes, but they need to explicitly decide not to use the default,
automatic, partitioning.

Also, if there is no real change, should the same be done for the other models we support (allowing for either auto-partitioning or a partitioning plan)?

Probably, although there being no actual standard layout specification
between platforms, non-EL models will need different code and
different options. (Unless someone fancies trying to abstract that,
which I don't think would be a good investment.)

What happens if someone decides that they really want more than two or three partitions? Do we then need yet another model to support that more complex partitioning plan?

I don't see why they wouldn't simply extend the existing set of
questions to cover their needs.

I just don't see this being very maintainable over time (if we're going to start modifying a minimal model in order to support a lot of additional user requirements for a more complex install process)...

No, I agree. I think that the notion that the models should contain
and abstract all the configuration details of an OS install is
probably flawed, ultimately, because it will grow to be equal in scope
to the underlying tool. That is, ultimately someone is likely to want
every option that you can specify to kickstart, so the set of
questions that Razor offered would be identically equal to the set of
options you can enter in a kickstart file.

With that in mind, I think the long term strategy is probably to allow
users to easily provide their own modifications to the kickstart (or
preseed, or whatever) file directly, rather than having to ask Razor
to do that for them.

However, since that is not even on the roadmap at the moment, this is
a clear quality of life improvement, it is compatible with existing
behaviour by default, and it doesn't introduce a significant amount of
code that makes the project harder to maintain, I couldn't see any
reason to refuse to merge it in the interim.

@faja

This comment has been minimized.

Show comment Hide comment
@faja

faja May 9, 2013

Contributor

Hi tjmcs,
there is LVM, and it gives you easy way to create and mount new partition after installation.
In my opinion Razor should create root partition with minimal/defined size (and of course /boot).
Next, depends on server role you can create partition for /database, /opt, /home , /log or whatever or just extend root partition if there is such need.

Contributor

faja commented May 9, 2013

Hi tjmcs,
there is LVM, and it gives you easy way to create and mount new partition after installation.
In my opinion Razor should create root partition with minimal/defined size (and of course /boot).
Next, depends on server role you can create partition for /database, /opt, /home , /log or whatever or just extend root partition if there is such need.

@tjmcs

This comment has been minimized.

Show comment Hide comment
@tjmcs

tjmcs May 9, 2013

So, what it sounds like (to me) is that there are an additional questions being added to the model build process (whether or not to use auto-partitioning and the partition sizes). This is a change in behavior as far as I'm concerned, because users who have scripted how a model is built will now have to answer additional questions in the model build process that they didn't have to answer before. Just as an example, here's what used to happen when I built a CentOS model:

# razor model add -t centos_6 -i 3ldKqkcgY5J8qos8fu5tD6 -l "CentOS-6.3 Model"
--- Building Model (centos_6): 

Please enter node hostname prefix (will append node number) (example: node) 
default: node
(QUIT to cancel)
 > 
Please enter local domain name (will be used in /etc/hosts file) (example: example.com) 
default: localdomain
(QUIT to cancel)
 > 
Please enter root password (> 8 characters) (example: P@ssword!) 
default: test1234
(QUIT to cancel)
 > 
Model created
 Label =>  CentOS-6.3 Model
 Template =>  linux_deploy
 Description =>  CentOS 6 Model
 UUID =>  4iIsazX7WDzm3Oszh3K7NY
 Image UUID =>  3ldKqkcgY5J8qos8fu5tD6

# 

and here's what happens after this pull request is merged in:

# razor model add -t centos_6 -i 3ldKqkcgY5J8qos8fu5tD6 -l "CentOS-6.3 Model"
--- Building Model (centos_6): 

Please enter node hostname prefix (will append node number) (example: node) 
default: node
(QUIT to cancel)
 > 
Please enter local domain name (will be used in /etc/hosts file) (example: example.com) 
default: localdomain
(QUIT to cancel)
 > 
Please enter root password (> 8 characters) (example: P@ssword!) 
default: test1234
(QUIT to cancel)
 > 
Please enter size (in megabytes) of root partition (valid if autopart == false) (example: 6144) 
default: 16384
(QUIT to cancel)
 > 
Please enter size (in megabytes) of swap partition (valid if autopart == false) (example: 2048) 
default: 8192
(QUIT to cancel)
 > 
Please enter if you want to use 'autopart' option (example: false) 
default: true
(QUIT to cancel)
 > 
Model created
 Label =>  CentOS-6.3 Model
 Template =>  linux_deploy
 Description =>  CentOS 6 Model
 UUID =>  5GbIzRYt6vUtsN4VDdRjea
 Image UUID =>  3ldKqkcgY5J8qos8fu5tD6

# 

that was my original concern. We're changing the behavior of the model without making a note of it somewhere (and discussing whether or not users feel this is a good idea). If someone wants to create a model that uses a custom partitioning plan I'm not against it, I just don't think that users of the system who are building Red Hat (or CentOS, which is based on Red Hat) models should have to answer all of these additional questions (regardless of whether or not they plan on using the new features that one or more users might want to have added for their own purposes).

tjmcs commented May 9, 2013

So, what it sounds like (to me) is that there are an additional questions being added to the model build process (whether or not to use auto-partitioning and the partition sizes). This is a change in behavior as far as I'm concerned, because users who have scripted how a model is built will now have to answer additional questions in the model build process that they didn't have to answer before. Just as an example, here's what used to happen when I built a CentOS model:

# razor model add -t centos_6 -i 3ldKqkcgY5J8qos8fu5tD6 -l "CentOS-6.3 Model"
--- Building Model (centos_6): 

Please enter node hostname prefix (will append node number) (example: node) 
default: node
(QUIT to cancel)
 > 
Please enter local domain name (will be used in /etc/hosts file) (example: example.com) 
default: localdomain
(QUIT to cancel)
 > 
Please enter root password (> 8 characters) (example: P@ssword!) 
default: test1234
(QUIT to cancel)
 > 
Model created
 Label =>  CentOS-6.3 Model
 Template =>  linux_deploy
 Description =>  CentOS 6 Model
 UUID =>  4iIsazX7WDzm3Oszh3K7NY
 Image UUID =>  3ldKqkcgY5J8qos8fu5tD6

# 

and here's what happens after this pull request is merged in:

# razor model add -t centos_6 -i 3ldKqkcgY5J8qos8fu5tD6 -l "CentOS-6.3 Model"
--- Building Model (centos_6): 

Please enter node hostname prefix (will append node number) (example: node) 
default: node
(QUIT to cancel)
 > 
Please enter local domain name (will be used in /etc/hosts file) (example: example.com) 
default: localdomain
(QUIT to cancel)
 > 
Please enter root password (> 8 characters) (example: P@ssword!) 
default: test1234
(QUIT to cancel)
 > 
Please enter size (in megabytes) of root partition (valid if autopart == false) (example: 6144) 
default: 16384
(QUIT to cancel)
 > 
Please enter size (in megabytes) of swap partition (valid if autopart == false) (example: 2048) 
default: 8192
(QUIT to cancel)
 > 
Please enter if you want to use 'autopart' option (example: false) 
default: true
(QUIT to cancel)
 > 
Model created
 Label =>  CentOS-6.3 Model
 Template =>  linux_deploy
 Description =>  CentOS 6 Model
 UUID =>  5GbIzRYt6vUtsN4VDdRjea
 Image UUID =>  3ldKqkcgY5J8qos8fu5tD6

# 

that was my original concern. We're changing the behavior of the model without making a note of it somewhere (and discussing whether or not users feel this is a good idea). If someone wants to create a model that uses a custom partitioning plan I'm not against it, I just don't think that users of the system who are building Red Hat (or CentOS, which is based on Red Hat) models should have to answer all of these additional questions (regardless of whether or not they plan on using the new features that one or more users might want to have added for their own purposes).

@slippycheeze

This comment has been minimized.

Show comment Hide comment
@slippycheeze

slippycheeze May 9, 2013

Contributor

So, what it sounds like (to me) is that there are an additional questions
being added to the model build process (whether or not to use
auto-partitioning and the partition sizes).

Didn't you read the code before commenting? That should have answered
this question for you.

Yes, it does add additional questions.

This is a change in behavior as
far as I'm concerned, because users who have scripted how a model is built
will now have to answer additional questions in the model build process that
they didn't have to answer before.

Yes, they will. I am not sympathetic to the idea that "I wrote
scripts that drive a human focused, interactive command line set of
questions" is valid or reasonable API for users to build on.

If being able to create models programatically, from scripts, is
desirable, then building an interface designed that way is reasonable.
Treating interactive query on STDIN that way is not particularly
robust - especially because it provides little to no meaningful way
for users to effectively error-check, without having to go into the
universe of expect scripts.

that was my original concern. We're changing the behavior of the model
without making a note of it somewhere

This is a confusing claim. The change is recorded in the git commit
history, and will become part of the release notes for the next
version.

Are you concerned that users who have installed from git head will
have code change under them? Indeed, they will. That is the nature
of following the (untested) commits to git head.

If someone wants to create a model that uses a
custom partitioning plan I'm not against it

I absolutely am: proliferating models to allow two ways to answer
questions is madness. You already built this human-interactive set of
questions to configure models, and I see no reason why it shouldn't be
used to configure models.

The idea that partitioning is different from, say, the root password,
or the domain name, seems crazy. Would you suggest, also, that users
create new models when they want a different IP address, or a
different hostname prefix?

Contributor

slippycheeze commented May 9, 2013

So, what it sounds like (to me) is that there are an additional questions
being added to the model build process (whether or not to use
auto-partitioning and the partition sizes).

Didn't you read the code before commenting? That should have answered
this question for you.

Yes, it does add additional questions.

This is a change in behavior as
far as I'm concerned, because users who have scripted how a model is built
will now have to answer additional questions in the model build process that
they didn't have to answer before.

Yes, they will. I am not sympathetic to the idea that "I wrote
scripts that drive a human focused, interactive command line set of
questions" is valid or reasonable API for users to build on.

If being able to create models programatically, from scripts, is
desirable, then building an interface designed that way is reasonable.
Treating interactive query on STDIN that way is not particularly
robust - especially because it provides little to no meaningful way
for users to effectively error-check, without having to go into the
universe of expect scripts.

that was my original concern. We're changing the behavior of the model
without making a note of it somewhere

This is a confusing claim. The change is recorded in the git commit
history, and will become part of the release notes for the next
version.

Are you concerned that users who have installed from git head will
have code change under them? Indeed, they will. That is the nature
of following the (untested) commits to git head.

If someone wants to create a model that uses a
custom partitioning plan I'm not against it

I absolutely am: proliferating models to allow two ways to answer
questions is madness. You already built this human-interactive set of
questions to configure models, and I see no reason why it shouldn't be
used to configure models.

The idea that partitioning is different from, say, the root password,
or the domain name, seems crazy. Would you suggest, also, that users
create new models when they want a different IP address, or a
different hostname prefix?

@nanliu

This comment has been minimized.

Show comment Hide comment
@nanliu

nanliu May 9, 2013

Contributor

@daniel-pittman, the output is just the CLI interface, not the workflow/API. Anyhow, I'm going to get back to the issue of adding everything type of customization to satisfy custom environments.

The models should be treated as template, similar to veewee model. Rather than adding myriad of customization (albeit all individually with good reason), it's better to let the user define their own model.

veewee default template probably doesn't make anyone happy (who installs chef & puppet), but it's provided as an example. However anyone can make a veewee-definition and customize to nth degree. I think that would be a saner path.

Contributor

nanliu commented May 9, 2013

@daniel-pittman, the output is just the CLI interface, not the workflow/API. Anyhow, I'm going to get back to the issue of adding everything type of customization to satisfy custom environments.

The models should be treated as template, similar to veewee model. Rather than adding myriad of customization (albeit all individually with good reason), it's better to let the user define their own model.

veewee default template probably doesn't make anyone happy (who installs chef & puppet), but it's provided as an example. However anyone can make a veewee-definition and customize to nth degree. I think that would be a saner path.

@grimradical

This comment has been minimized.

Show comment Hide comment
@grimradical

grimradical May 10, 2013

Member

Crap, I think I accidentally nuked a comment from this thread. Apologies...I have no idea how to get it back. :/

Member

grimradical commented May 10, 2013

Crap, I think I accidentally nuked a comment from this thread. Apologies...I have no idea how to get it back. :/

@grimradical

This comment has been minimized.

Show comment Hide comment
@grimradical

grimradical May 10, 2013

Member

Adding @lynxbat 's comment back in, from my email:

Didn't you read the code before commenting? That should have answered this question for you. Yes, it does add additional questions.

I think Tom was being polite here Daniel.

Yes, they will. I am not sympathetic to the idea that "I wrote scripts that drive a human focused, interactive command line set of questions" is valid or reasonable API for users to build on. If being able to create models programatically, from scripts, is desirable, then building an interface designed that way is reasonable. Treating interactive query on STDIN that way is not particularly robust - especially because it provides little to no meaningful way for users to effectively error-check, without having to go into the universe of expect scripts.

What does your personal empathic response have to do with changing API (CLI is an API) behavior? This is a community project - not a Pittman-project.

This is a confusing claim. The change is recorded in the git commit history, and will become part of the release notes for the next version. Are you concerned that users who have installed from git head will have code change under them? Indeed, they will. That is the nature of following the (untested) commits to git head.

Daniel - what testing did you do for the inherited Redhat and Centos versions that will all have to support this behavior? It seems like you are saying none - and that the master branch GIT HEAD is going to take on untested commits. And it scares me how you see this as confusing. Tom is stating (and correctly) that it is possible someone pulls this and suddenly has broken model creation processes. It is possible and your response is snarky and patronizing.

I know that this pull request has already been merged, but does it change the default behavior that users of the Red Hat model would have experienced previous to the merge of this pull request?
Nope.

It does change the behavior. This is a perception statement. Also - if you had read the code you should have correctly stated that this also affects Centos since it inherits from this model. Anyone who has custom models based off of the Redhat or Centos model here now inherits this behavior. If anyone implemented their own custom partitioning it is likely it is either broken or unpredictable with their models.

The original intent of the base models was very basic generic functionality since environmental customization is almost always needed in environments. Your merging of this without comment or concern alerted Tom to the opposite of that pattern. Your response didn't make that any better.

I am not completely opposed to this change - but Daniel I believe you evaluation of it here is quite off.

Member

grimradical commented May 10, 2013

Adding @lynxbat 's comment back in, from my email:

Didn't you read the code before commenting? That should have answered this question for you. Yes, it does add additional questions.

I think Tom was being polite here Daniel.

Yes, they will. I am not sympathetic to the idea that "I wrote scripts that drive a human focused, interactive command line set of questions" is valid or reasonable API for users to build on. If being able to create models programatically, from scripts, is desirable, then building an interface designed that way is reasonable. Treating interactive query on STDIN that way is not particularly robust - especially because it provides little to no meaningful way for users to effectively error-check, without having to go into the universe of expect scripts.

What does your personal empathic response have to do with changing API (CLI is an API) behavior? This is a community project - not a Pittman-project.

This is a confusing claim. The change is recorded in the git commit history, and will become part of the release notes for the next version. Are you concerned that users who have installed from git head will have code change under them? Indeed, they will. That is the nature of following the (untested) commits to git head.

Daniel - what testing did you do for the inherited Redhat and Centos versions that will all have to support this behavior? It seems like you are saying none - and that the master branch GIT HEAD is going to take on untested commits. And it scares me how you see this as confusing. Tom is stating (and correctly) that it is possible someone pulls this and suddenly has broken model creation processes. It is possible and your response is snarky and patronizing.

I know that this pull request has already been merged, but does it change the default behavior that users of the Red Hat model would have experienced previous to the merge of this pull request?
Nope.

It does change the behavior. This is a perception statement. Also - if you had read the code you should have correctly stated that this also affects Centos since it inherits from this model. Anyone who has custom models based off of the Redhat or Centos model here now inherits this behavior. If anyone implemented their own custom partitioning it is likely it is either broken or unpredictable with their models.

The original intent of the base models was very basic generic functionality since environmental customization is almost always needed in environments. Your merging of this without comment or concern alerted Tom to the opposite of that pattern. Your response didn't make that any better.

I am not completely opposed to this change - but Daniel I believe you evaluation of it here is quite off.

@grimradical

This comment has been minimized.

Show comment Hide comment
@grimradical

grimradical May 10, 2013

Member

All that to say: let's keep this impersonal and about the code, please.

Member

grimradical commented May 10, 2013

All that to say: let's keep this impersonal and about the code, please.

@lynxbat

This comment has been minimized.

Show comment Hide comment
@lynxbat

lynxbat May 10, 2013

Contributor

@grimradical we have 3 of the 4 project committers listed in the README expressing concern over this merge. With the 4th being the one who merged.

How should this be resolved?

Contributor

lynxbat commented May 10, 2013

@grimradical we have 3 of the 4 project committers listed in the README expressing concern over this merge. With the 4th being the one who merged.

How should this be resolved?

@slippycheeze

This comment has been minimized.

Show comment Hide comment
@slippycheeze

slippycheeze May 10, 2013

Contributor

I am happy to revert the change, and remove the feature that was routinely
requested by actual users, since it is shockingly controversial.

Contributor

slippycheeze commented May 10, 2013

I am happy to revert the change, and remove the feature that was routinely
requested by actual users, since it is shockingly controversial.

@slippycheeze

This comment has been minimized.

Show comment Hide comment
@slippycheeze

slippycheeze May 10, 2013

Contributor

That pull request contains a revert on the change, ready for you to merge.

Contributor

slippycheeze commented May 10, 2013

That pull request contains a revert on the change, ready for you to merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment