Bug 1397983 - Multiple host records if self-hosted engine fqdn is >64 characters
Summary: Multiple host records if self-hosted engine fqdn is >64 characters
Keywords:
Status: CLOSED EOL
Alias: None
Product: Red Hat Quickstart Cloud Installer
Classification: Red Hat
Component: Installation - RHEV
Version: 1.1
Hardware: All
OS: All
unspecified
medium
Target Milestone: ---
: 1.2
Assignee: John Matthews
QA Contact: Sudhir Mallamprabhakara
Dan Macpherson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-23 17:58 UTC by Tasos Papaioannou
Modified: 2018-02-26 19:55 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-26 19:55:13 UTC
Target Upstream Version:


Attachments (Terms of Use)

Comment 2 Jason Montleon 2016-11-28 20:05:44 UTC
Tasos, before running a deployment can you turn on "Use UUID for certificates" under puppet in the Satellite settings and see if you end up with one host record instead of two on a new deployment?

We probably want to turn this feature on to better deal with vm's running on Openstack, and I'm curious if it will mitigate this problem as well.

Comment 3 Tasos Papaioannou 2016-11-30 14:28:48 UTC
The behavior is the same with "Use UUID for certificates" set to "true" under Settings > Puppet. I'm not sure why that puppet-related setting would affect the content host record name, though. Also, the engine-setup command fails on the engine VM when the hostname is too long, when it tries to generate its CA:


2016-11-29 22:07:13 INFO otopi.plugins.gr_he_common.engine.health health._closeup:130 Running engine-setup on the appliance
2016-11-29 22:08:32 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |- Enabling ssh access
[...]
2016-11-29 22:09:19 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |- [ INFO  ] Creating CA
2016-11-29 22:09:25 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |- [ ERROR ] Failed to execute stage 'Misc configuration': Command '/usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh' failed to execute
2016-11-29 22:09:25 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |- [ INFO  ] Stage: Clean up
2016-11-29 22:09:25 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |-           Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20161129170855-rk3huf.log
2016-11-29 22:09:25 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |- [ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20161129170924-setup.conf'
2016-11-29 22:09:25 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |- [ INFO  ] Stage: Pre-termination
2016-11-29 22:09:25 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |- [ INFO  ] Stage: Termination
2016-11-29 22:09:25 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |- [ ERROR ] Execution of setup failed
2016-11-29 22:09:25 DEBUG otopi.plugins.otopi.dialog.human dialog.__logString:204 DIALOG:SEND                 |- HE_APPLIANCE_ENGINE_SETUP_FAIL
2016-11-29 22:09:25 ERROR otopi.plugins.gr_he_common.engine.health health._closeup:170 Engine setup failed on the appliance

I'm guessing this is also related to a length limit on the CN field in the CA. Limiting the FQDN of the self-hosted engine should resolve both of these issues.

Comment 4 Fabian von Feilitzsch 2016-11-30 15:42:27 UTC
This looks like it's probably an issue with our hostname validators (backend and frontend), do you only see this issue with the self-hosted engine or is it present for the hypervisors and regular engine as well? Chris, thoughts?

Comment 5 Tasos Papaioannou 2016-11-30 19:11:34 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=1362288 restricted the length of custom short hostnames that the user could enter for engine+hypervisor deployments, but if either the hypervisor host or engine's shortname + domain is longer than 64 characters, then its host record is duplicated, and if the engine's fqdn is too long, then the deployment fails when running /usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh as in c#3 above.

Also, it looks like nothing prevents the user from installing fusor with a domain name that by itself is longer than 64 characters, so if that happened all RHV deployments would fail.

Comment 6 Jason Montleon 2016-12-05 15:08:56 UTC
Some thoughts:

I think the longest prefix/suffix we append to a generated hostname is overcloud-, which if I counted correctly is ten characters. With a 53 character domain this would leave just one character for the deployment name. Perhaps we can put a note in the installer when they set the domain as to what the longest deployment name will be.

If we limited the domain name to 53 characters we would then have to ensure the domain name plus deployment name is no more than 54 characters. 

Beyond that we'd have to ensure hostnames users set (renamed discovered hosts, ose router domain, etc.) are no more than 64 characters in total.

Comment 8 Jason Montleon 2016-12-06 16:14:44 UTC
First small step:
https://github.com/fusor/fusor-installer/pull/104

The reason for 48 is that discovered hosts have a default name of 'mac'+ the 12 characters of the mac address. Adding a dot between shortname and domain means we need to provide for a total of 16 characters in addition to the domain name in a RHEV deployment where someone simply clicks through the UI.

We should also limit the deployment name + domain name to 53 characters as mentioned above. That allows for 10 characters for the overcloud- prefix and a dot between shortname + domain.

And then individual hostnames that are not autogenerated will need to be checked in the ui when they are modified by the user in various places that allow for it.


Note You need to log in before you can comment on or make changes to this bug.