Hide Forgot
Description of problem: firstboot menu is problematic when we want to automate deployment and configure rhevm appliance. since the vm doesn't boot unless been configured from first boot menu. specially with the combination of hosted engine, everything can be configured using cloud-init, and appliance can be run with hostname/network and root password configured already Version-Release number of selected component (if applicable): 3.5.0 How reproducible: always Steps to Reproduce: 1.boot the appliance 2. 3. Actual results: Expected results: Additional info: needed for RHCI common installer.
I understand the problem, and we want to address it, but let's do this after 3.5.0, and maybe consider it for a z-stream. The reason is that it requires 1. rel-eng changes 2. Testing 3. development
Fixing target version to consider it for 3.5.z.
As discussed on the email thread, I'd rather like to enable cloud-init in the image and use the cloud-init fallback method with an attached media. The root password and network configuration can then be set using cloud-init's fallback method: http://cloudinit.readthedocs.org/en/latest/topics/datasources.html#fallback-none That way the cloud-init code path is tested twice: during automation and when the regular testing is taking place.
For several reasons it makes sense to be able to configure the image using cloud-init, some of them in no particular order: - cloud-init is used in OpenStack and RHEV - The initial setup dialog prevents easy automation - cloud-init can be used to inject an ssh key etc In summary we want to use cloud-init as a defacto standard for the bootstrap configuration of this image. This RFE needs to cover several aspects: 1. Enable cloud-init in the image 2. Disable the initial setup dialog 3. Test 3.a That cloud-init works when the image is used in RHEV 3.b That cloud-init works when the image is used in OpenStack 3.c That cloud-init works locally when using teh fallback method as described here: https://www.technovelty.org//linux/running-cloud-images-locally.html 4. Add and reference documentation if it exists elsewhere 5. Ensure that the build process works, including the errata process
This feature is actually now differnt. cloud-init is not an alternative, but cloud-init is now the only option to configure the appliance on the first boot. This is already handled by hosted-engine-setup.
Point 3a from #c4 has been verified with: rhevm-appliance-20151119.0-1 rhevm-appliance cloud-init is working for rhevm. Could we assign this to someone from Openstack QE or create separate BZ for it?
Thanks. No, OpenSTACK QE does not need to test this image right now. This image is tuned towards the Hosted-Engine flow. Advertising it in OpenStack right now will probably raise false expectations.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:0385