Bug 1138564

Summary: Cloud-init files are ignored
Product: [Retired] oVirt Reporter: Juan Hernández <juan.hernandez>
Component: ovirt-engine-apiAssignee: Michal Skrivanek <michal.skrivanek>
Status: CLOSED NOTABUG QA Contact: Pavel Stehlik <pstehlik>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.4CC: bugs, ecohen, gklein, iheim, michal.skrivanek, rbalakri, sbonazzo, shavivi, s.kieske, yeylon
Target Milestone: ---   
Target Release: 3.5.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: virt
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-26 07:35:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Juan Hernández 2014-09-05 08:11:39 UTC
In version 3.3 of the engine the "files" element provided as part of the "cloud-init" element was used to include files in the cloud-init disk, but this doesn't work in 3.4, the "files" element is ignored.

In addition, the content of the first "file" element is appended to the cloud-init configuration file, thus potentially rendering an incorrect file that may not work or cause unexpected results.

Bot these changes break backwards compatibility.

Comment 1 Juan Hernández 2014-09-05 08:15:41 UTC
For example, the following request, including the "files" element:

  <action>
    <vm>
      <initialization>
        <cloud_init>
          ...
          <files>
            <file>
              <name>myfile.txt</name>
              <content>***dangerous junk***</content>
              <type>plaintext</type>
            </file>
          </files>
        </cloud_init>
      </initialization>
    </vm>
  </action>

Results in the following content in the generated "user_data" file:

  #cloud-config
  ssh_pwauth: true
  disable_root: 0
  output:
    all: '>> /var/log/cloud-init-output.log'
  password: mypassword
  chpasswd:
    expire: false
  runcmd:
  - 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo ''datasource_list:
    ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg'
  ***dangerous junk***

Comment 2 Sven Kieske 2014-09-05 08:42:59 UTC
I'd say this is a regression and should block the 3.4.4. release

Comment 3 Michal Skrivanek 2014-09-05 12:09:01 UTC
it was wrong in 3.3, the original intent was to behave as in 3.4
For generic pushing of files one should use the already existing "vmpayload" 

Is there any reference suggesting the use as described in the bug?

Comment 4 Sven Kieske 2014-09-05 12:48:34 UTC
(In reply to Michal Skrivanek from comment #3)
> it was wrong in 3.3, the original intent was to behave as in 3.4
> For generic pushing of files one should use the already existing "vmpayload" 
> 
> Is there any reference suggesting the use as described in the bug?

Well yeah, the reference is the code in 3.3.

there was no documentation that this was wrong behaviour was there?

Am I expected to take every feature that ovirt has as a bug that was meant to work in a different way unless it's documented somewhere?

How should I, as a user, know that this is not intended behaviour, when you
don't document the bugs when the software gets released?

As for the docs:

http://www.ovirt.org/Features/Cloud-Init_Integration

see section "api design" I'm not aware of any other ovirt docs.

If you refer to rhev docs:

there is no documentation for 3.3. regarding the cloud-init api (i could not find anything regarding the file element inside cloud-init in the developer guide).


I'm not sure I'm providing the info you needed, please request more if you
need further answers.

Comment 5 Omer Frenkel 2014-09-07 12:22:13 UTC
I agree documentation is missing, but the thing is that in 3.4 we replaced the hacky option to attach files with the option to use custom script for cloud-init, where user can do that in addition to other stuff, and this is the right way to use cloud init.

Comment 6 Michal Skrivanek 2014-09-08 06:46:12 UTC
Sorry, the intent should have been documented, but it's too late now, we can't go back to 3.3 behavior since the "correct" behavior is already out since 3.4.

Comment 7 Sandro Bonazzola 2014-09-09 06:52:35 UTC
Removing from 3.4.4 blockers according to comment #3, comment #5 and comment #6.
As per above comments looks like this should be closed as not a bug. Michal?

Comment 8 Sandro Bonazzola 2014-09-09 06:53:03 UTC
Also dropping Regression keyword as per above comments.