Feature #168
closed
Make HOSTS fields optional when using "unattended"
Added by Marcello de Sousa almost 15 years ago.
Updated about 14 years ago.
Description
When using foreman with existing non-standard (legacy) machines and leaving "unattended = true" to use it for unattended installs for new machines, you get an error if you try to assign classes or groups and don't select a "Ptable" template.
The error is:
"Ptable Cant be blank unless a custom partition has been defined"
To manage this in a mixed environment I suggest not making the fields mandatory, but maybe just give a warning or confirmation saying that the fields are not completely filled up.
- Target version deleted (
0.1-4)
I agree this is a useful feature, I'll have to investigate how to implement it.
- Target version set to 0.1-5
ok, I've found a way to do it, I'll start working on towards the following release
- Status changed from New to Assigned
- Assignee changed from Ohad Levy to Paul Kelly
I have implemented a mechanism for hiding and revealing the unattended section in the gui and using this to de/activate the relevant validation checks. However when testing I found that I was not able to find a scenario in which this problem could occur.
If a legacy host has been imported via the rake tasks then all host fields are populated except the media, ptable, root password and serial. If this host then requires a new class or group then this is accessed via the edit page. The edit page will populate the ptable field unless the operating system of the host does not have any partition tables defined for it. In this case it might be more sensible to change the error message to "Ptable Cant be blank unless a custom partition has been defined\nEnsure that operatingsystem XXX has at least one partition table defined." Alternatively, a custom validation could be created that could distinguish between these to situations.
Marcello: if you have access to a current development installation, could you confirm that this problem is still present? Could you also describe how your host entries were created? If you created them whilst unattended => false and then switched to using unattended => true I would expect to see more errors as mac is not set.
- Branch set to feature/168-optional-fields
Marcello: I think that I understand the problem now so no need to reply.
Rebased.
Tests pass
- Target version changed from 0.1-5 to 0.1-6
- Status changed from Assigned to Ready For Testing
Paul Kelly wrote:
Rebased and passes tests
as its been a long time since we reviewed this, what is the change in behavior? (that we'll know to update the release notes as well).
In an installation running with unattended enabled there may be hosts that have been imported but you do not wish to manage their build cycle.
When a host edited then it is marked as being managed if it has an architecture, an OS and either a disk or ptable value. (When a host is imported then the ptable is not set.) When this host is edited then the unattended section is not rendered, so any value in that section is not updated. When these values are applied to the host object then the validations notice that the host is not managed and do not enforce the presence of a ptable.
- % Done changed from 0 to 100
- Status changed from Ready For Testing to Closed
- Status changed from Closed to Ready For Testing
- Branch changed from feature/168-optional-fields to feature/168-optional-fields-extras
The edit page after an empty create page looks wrong
The alerts enabled and host owner would look better below the comment box
Note the branch name change above
more formatting goodness added
- Status changed from Ready For Testing to Closed
Also available in: Atom
PDF
Updated by 
Updated by