Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Connecting redmine issue http://projects.theforeman.org/issues/8289 from this bug

Upstream bug component is Compute Resources

This is of high value to RHCI.

Moving to POST since upstream bug http://projects.theforeman.org/issues/8289 has been closed

Created attachment 1290909 [details]
Backport of https://github.com/abenari/rbovirt/pull/80/commits/0977712b2082ddebd69cfade8240f5fbe3eb96c9 against rbovirt 0.0.38 (satellite 6.2)

Created attachment 1290910 [details]
Backport of https://github.com/theforeman/foreman/pull/2350/commits/12ffd00fbbb125b7a411961760653c071005aff8 to foreman 1.11 (satellite 6.2)

Created attachment 1305440 [details]
Hotfix packages with additional commit to rbovirt to fix compatibility for cloud-init setup with RHEV 4

There were addition compatibility changes needed for the cloud init provisioning to work with RHEV 4.

I've tested the code with Satellite 6.2.9 and RHEV 4 and worked as expected: the cloud-init data were available in the VM under `/dev/sr1` when the provisioning finished.

Created attachment 1305442 [details]
Hotfix RPMs - third version

Updated hotfix to work with RHEV4. Marking previous versions as obsolete. Tested against 6.2.9 and RHEV 4.1.2

Hello Ivan,

This version indeed seems to work a lot better.
The payload seems to get correctly to RHV and the data is passed to the VM.

We still don't get the behavior the customer expects, though. I wonder if this has anything to do with satellite or rather it's a cloud-init bug/limitation.

I'll post the data here so you can maybe point me to the right direction.

The customer is using a template found upstream as the one shipped with Satellite didn't seem to work at all (can't remember exactly the problem, I'd have to go fetch it in old comments). I'll attach the current template they're using and the screenshots they provided from the logs.

It appears that not all tasks are executed. For example, IP is not changed, hostname is not changed (this seems to be a bug in 7.3) and post scripts are not run (they use a script to workaround the IP change problem, but it doesn't seem to work).

I'll attach all the data they attached to the ticket.

Created attachment 1309048 [details]
template

Created attachment 1309049 [details]
cloud-init output

Created attachment 1309050 [details]
cloud-init log

Created attachment 1309051 [details]
cloud.tar.gz

Could you share output of `/unattended/user_data?hostname=host.example.com` (replace the hostname with the real name).

In the logs, there is '2017-08-03 16:55:56,670 - cc_write_files.py[DEBUG]: Skipping module named write-files, no/empty 'write_files' key in configuration', which seems to be connected to the writing for /tmp/foreman-userdata.sh file, therefore I'm interested into how the cloud-init rendered looks like.

I was able to run simple template like this:

```
#cloud-init
runcmd:
- rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
```

However, when I tried to do something more useful, such as 

```
runcmd:
<% if rhel_compatible -%>
- |
<%= indent(2) { snippet('epel') } %>
<% end -%>
- |
<%= indent(2) { snippet('remote_execution_ssh_keys') } %>
<% end -%>
```

it failed to generate proper user_data template on the system, due to wrong
indentation of the resulting file.

I've opened a minimal fix for the issue in rbovirt gem upstream

https://github.com/abenari/rbovirt/pull/120

There are other gotchas in the cloud-init integration, which mean we
currently support just a small subset of the cloud-init template (I will
file another bug against that) that I don't think are
blocking the initial use of it after fixing https://github.com/abenari/rbovirt/pull/120, but mean the user needs to write the cloud-init template that respects this limitations. I will open different issue for that, as fixing this limitation might get more complicated (as the fix goes through 3 different code-bases), which can slow down the delivery of that part.

Additional bug, describing the limitation of the current cloud-init support is here https://bugzilla.redhat.com/show_bug.cgi?id=1481315

Upstream bug assigned to inecas

Upstream bug assigned to inecas

Additional fix https://github.com/abenari/rbovirt/pull/120 merged, putting to POST

Created attachment 1317125 [details]
Hotfix RPMs - 4th version

Yet another hotfix version, including https://github.com/abenari/rbovirt/pull/120 to support multi-line runcmd commands.

Is there an upstream release of rbovirt to be pulled in?

Set tfm-rubygem-rbovirt-0.1.4-1.el7sat as fixed in field. I've realized I've forgot to open upstream PR for packaging https://github.com/theforeman/foreman-packaging/pull/1782

*** Bug 1480349 has been marked as a duplicate of this bug. ***

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/RHSA-2018:0336

Could you please suggest if i need cloud-init installed in my image? also is this works completely? i dont find it's setting up runcmd, manage_resolve_conf and other modules from cloud-init ? i am using satellite 6.2.12 for Vmware image provisioning.

The specific implementation of the user_data is provider dependent. VmWare is not using the cloud-init standard, but they rather export a specific set of keys to customize the provisioning. [1].

The data to be generated for this spec should be defined in YAML Foreman in the user_data template.

[1] - https://pubs.vmware.com/vi3/sdk/ReferenceGuide/vim.vm.customization.Specification.html

@inecas, one more question please. when user_data template is executed on Client, what network Ports are communicated from Client to vCentre and Client to Capsule or Client to Satellite Master ?

Thanks

The question regarding the communication from Client to vCenter is more suitable for the vSphere product support, as it's outside of Satellite's realm.

For the client -> capsule communication, it's not different from the standard network-based provisioning.