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.
For example, the following request, including the "files" element:
Results in the following content in the generated "user_data" file:
all: '>> /var/log/cloud-init-output.log'
- 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo ''datasource_list:
["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg'
I'd say this is a regression and should block the 3.4.4. release
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?
(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:
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.
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.
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.
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?
Also dropping Regression keyword as per above comments.