Bug 1481315 - Cloud-init integration with ovirt supports just a subset of cloud-init keywords
Summary: Cloud-init integration with ovirt supports just a subset of cloud-init keywords
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Compute Resources - RHEV
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
medium
medium vote
Target Milestone: Released
Assignee: Ivan Necas
QA Contact: Sanket Jagtap
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-14 14:53 UTC by Ivan Necas
Modified: 2019-10-07 17:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-14 12:36:36 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:1222 None None None 2019-05-14 12:36:54 UTC
Foreman Issue Tracker 20590 None None None 2017-08-14 15:12:04 UTC
Foreman Issue Tracker 24217 None None None 2018-07-10 10:31:23 UTC

Description Ivan Necas 2017-08-14 14:53:16 UTC
Description of problem:
As of https://bugzilla.redhat.com/show_bug.cgi?id=1189813, the cloud-init
integration with ovirt supports just a sub-set of cloud-init keys.

The following template seems to be the maximal set of keys we
can currently pass successfully to the cloud-init via user_data:

```
#cloud-init
hostname: test.example.com
ssh_authorized_keys:
- ssh-rsa test123123123 test.example.com
runcmd:
- ls /
phone_home:
  url: satellite.example.com
  post: []
```

Cloud-init supports much wider range or modules and configuration options,
https://cloudinit.readthedocs.io/en/latest/topics/modules.html#. Currently
we don't support those and this options get ignored.

Version-Release number of selected component (if applicable):
6.3.0

How reproducible:
Always

Steps to Reproduce:
1. add user_data image with cloud-init installed and configured.
2. use one of the valid cloud-init keys that ARE NOT one of `hostname`, `ssh_authorized_keys`, `runcmd`, `phone_home`,
an example could be:
```
#cloud-init
yum_repos:
    zoo:
        baseurl: https://inecas.fedorapeople.org/fakerepos/new_cds/content/zoo/1.0/x86_64/rpms/
        name: zoo
        enabled: true
```



Actual results:
Many cloud-init modules options get ignored (including the `yum_repos` one in the example)

Expected results:
All cloud-init modules options get passed to cloud-init (including the `yum_repos` one in the example)

Additional info:

Comment 2 Ivan Necas 2017-08-14 15:12:02 UTC
Connecting redmine issue http://projects.theforeman.org/issues/20590 from this bug

Comment 4 pm-sat@redhat.com 2018-04-25 12:19:31 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/20590 has been resolved.

Comment 5 Ivan Necas 2018-07-10 10:31:23 UTC
Added additional issue regarding support of shell-script format for the cloud-init

Comment 6 pm-sat@redhat.com 2018-07-13 10:21:10 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/24217 has been resolved.

Comment 9 Sanket Jagtap 2018-12-31 07:34:20 UTC
Build: Satellite 6.5 snap 9 

I am getting safe mode error on trying to use the Kickstart default user data shipped with satellite.
If, I am right this should work with safe mode too, or is there any other template I should use for Cloud Init. I also tried with User data default template, same result.
Am I missing something?

On disabling the safemode, I am able to verify this issue and Cloud Init works successfully .

Comment 15 Sanket Jagtap 2019-03-06 09:12:27 UTC
Build: Satellite 6.5 snap 18

Tested on API v3, no issues looks like i was hitting a v4 bug

Cloud-config 

#cloud-config
hostname: earl-lopata
fqdn: earl-lopata
manage_etc_hosts: true
ssh_pwauth: true
groups:
- admin
users:
- default
- name: admin
  primary-group: admin
  groups: users
  shell: /bin/bash
  sudo: ['ALL=(ALL) ALL']
  lock-passwd: false
  passwd:

yum_repos:
  zoo:
    baseurl: https://inecas.fedorapeople.org/fakerepos/new_cds/content/zoo/1.0/x86_64/rpms/
    name: zoo
    enabled: true
    gpgcheck: false


Output log cloud_init.log:
2019-03-06 09:03:19,011 - helpers.py[DEBUG]: Running config-rh_subscription using lock (<FileLock using file '/var/lib/cloud/instances/b8b10f2b-dbf0-4d2b-b0b7-a896d1365a67/sem/config_rh_subscription'>)
2019-03-06 09:03:19,011 - cc_rh_subscription.py[DEBUG]: rh_subscription: module not configured.
2019-03-06 09:03:19,011 - handlers.py[DEBUG]: finish: modules-config/config-rh_subscription: SUCCESS: config-rh_subscription ran successfully
2019-03-06 09:03:19,011 - stages.py[DEBUG]: Running module yum-add-repo (<module 'cloudinit.config.cc_yum_add_repo' from '/usr/lib/python2.7/site-packages/cloudinit/config/cc_yum_add_repo.pyc'>) with frequency once-per-instance
2019-03-06 09:03:19,012 - handlers.py[DEBUG]: start: modules-config/config-yum-add-repo: running config-yum-add-repo with frequency once-per-instance
2019-03-06 09:03:19,012 - util.py[DEBUG]: Writing to /var/lib/cloud/instances/b8b10f2b-dbf0-4d2b-b0b7-a896d1365a67/sem/config_yum_add_repo - wb: [644] 20 bytes
2019-03-06 09:03:19,013 - util.py[DEBUG]: Restoring selinux mode for /var/lib/cloud/instances/b8b10f2b-dbf0-4d2b-b0b7-a896d1365a67/sem/config_yum_add_repo (recursive=False)
2019-03-06 09:03:19,013 - util.py[DEBUG]: Restoring selinux mode for /var/lib/cloud/instances/b8b10f2b-dbf0-4d2b-b0b7-a896d1365a67/sem/config_yum_add_repo (recursive=False)
2019-03-06 09:03:19,014 - helpers.py[DEBUG]: Running config-yum-add-repo using lock (<FileLock using file '/var/lib/cloud/instances/b8b10f2b-dbf0-4d2b-b0b7-a896d1365a67/sem/config_yum_add_repo'>)
2019-03-06 09:03:19,015 - util.py[DEBUG]: Writing to /etc/yum.repos.d/zoo.repo - wb: [644] 191 bytes
2019-03-06 09:03:19,016 - util.py[DEBUG]: Restoring selinux mode for /etc/yum.repos.d/zoo.repo (recursive=False)
2019-03-06 09:03:19,017 - util.py[DEBUG]: Restoring selinux mode for /etc/yum.repos.d/zoo.repo (recursive=False)
2019-03-06 09:03:19,017 - handlers.py[DEBUG]: finish: modules-config/config-yum-add-repo: SUCCESS: config-yum-add-repo ran successfully

Comment 19 errata-xmlrpc 2019-05-14 12:36:36 UTC
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-2019:1222


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