Bug 1045484 - REST API cloud init: can't set root password [using json]
Summary: REST API cloud init: can't set root password [using json]
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-api
Version: 3.3
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
: 3.4.0
Assignee: Omer Frenkel
QA Contact: Pavel Novotny
URL:
Whiteboard: virt
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-20 14:52 UTC by Sven Kieske
Modified: 2015-10-27 23:56 UTC (History)
7 users (show)

Fixed In Version: ovirt-3.4.0-alpha1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-31 12:25:59 UTC
oVirt Team: ---


Attachments (Terms of Use)

Description Sven Kieske 2013-12-20 14:52:20 UTC
Description of problem:

I'm trying to use the REST-API do create vms and then start them
with cloud-init provided data through rest-api.

the data gets passed fine so far, except for the password, this does not
show up in the user_data or any other file of the attached iso in the vm.
Version-Release number of selected component (if applicable):
engine 3.3.2

How reproducible:
provide cloud-init information via REST-API, including password

Steps to Reproduce:
1.
2.
3.

Actual results:
the password gets not passed

Expected results:
the password shows up in the user_data section

Additional info:
as far as my devs could tell me, the responsible UserMapper.java
does not set the password:

gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/restapi/types/src/main/java/org/ovirt/engine/api/restapi/types/UserMapper.java;h=a6aa3a5a5e0dca0ef6a54a38824c7da17228d041;hb=refs/heads/ovirt-engine-3.3.2

I can not see the required model there, so I guess they are right.

Comment 1 Omer Frenkel 2013-12-22 13:33:09 UTC
can you share the xml you used to start the vm?

did you follow the wiki [1]:
<vm>
    <initialization>
     <cloud_init>
       <users>
         <user>
           <user_name>root</user_name>
           <password>myPass</password>
         </user>
       </users>
     </cloud_init>
    </initialization>
</vm>

[1] http://www.ovirt.org/Features/Cloud-Init_Integration

Comment 2 Sven Kieske 2014-01-02 08:50:33 UTC
Hi,
sorry for the late reply.
I was on vacation.

First:
We do not use XML but JSON, but this should not matter, should it?

Here is our JSON:

{"async":false,"vm":{"initialization":{"cloudInit":{"host":{"address":"vr00001"},"networkConfiguration":{"nics":{"nics":[{"name":"eth0","bootProtocol":"STATIC","network":{"ip":{"address":"$VALID-IPV4","netmask":"$VALID-NETMASK","gateway":"$VALID-GW"}},"onBoot":true}]},"dns":{"servers":{"hosts":[{"address":"$VALID-IPV4"},{"address":"$VALID-IPV4"},{"address":"$VALID-IPV4"}]}}},"users":{"users":[{"name":"root","password":"$RANDOM_PASSWORD"}]},"files":{"files":[{"name":"\/foo","content":"$CONTENT","type":"PLAINTEXT"}]}}}}}

Comment 3 Sven Kieske 2014-01-02 08:58:17 UTC
To track this further down:
I checked the content of the "user_data" file, the username (root)
is correctly submitted, but the password does not show up, it reads like this
(from a different start:

#cloud-config
ssh_deletekeys: 'True'
output:
  all: '>> /var/log/cloud-init-output.log'
user: root
runcmd:
- 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo ''datasource_list:
  ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg'


but between "user:" and "runcmd:" should be the field "password:"
but it doesn't get transmitted.

Btw, if we try this syntax from the wiki:
"<users><user>" it doesn't work at all, you need "<users><users>" at least
if you are using json instead of xml.

Comment 4 Omer Frenkel 2014-01-02 11:02:15 UTC
its ok using json, although what you pasted didnt really work for me as is, maybe because i work on latest master (i had to change "cloudInit" to "cloud_init" and '"users":{"users":' to '"users":{"user":' and so on)

but the problem is that you need to use 'user_name' and not 'name' for 'root'
as name is the name of the user, and user_name is, well, the user-name :)

please try with this and see if it helps

Comment 5 Sven Kieske 2014-01-02 11:22:47 UTC
Thanks for your fast reply.
I have some comments on this:

Could you, or anybody else, try to reproduce this on 3.3.2 ?

if "name" is not correct and "user_name" should be used, why does the name
'root' get passed to the user_data into the vm?

if this option is not named correctly I would expect ovirt to report an error, as it does with different option names at other locations in the json.

But the username gets passed, just the password doesn't get passed. so I doubt this is causing the error.
We also verified that this works by passing a different username than 'root'.
But I will test it anyway, as soon as my developer comes back from lunch and then
report back.

But I really need someone to tell me the correct syntax for 3.3.2

I doubt that the password gets processed in any way since there seems to be no
code for this option in:

gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/restapi/types/src/main/java/org/ovirt/engine/api/restapi/types/UserMapper.java;h=a6aa3a5a5e0dca0ef6a54a38824c7da17228d041;hb=refs/heads/ovirt-engine-3.3.2

if you are right, this is still an error in the API, because it should report
wrong arguments back and not fail silently.

I'll report back as soon as I can test it (ca. 1 hour I guess).

Comment 6 Sven Kieske 2014-01-02 11:36:14 UTC
Hi,

we tested it with 'user_name' instead of 'name' and get the following error:

"<html><head><title>JBoss Web\/7.0.13.Final - Error report<\/title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--><\/style> <\/head><body><h1>HTTP Status 400 - org.codehaus.jackson.map.exc.UnrecognizedPropertyException: Unrecognized field &quot;user_name&quot; (Class org.ovirt.engine.api.model.User), not marked as ignorable\n at [Source: org.apache.catalina.connector.CoyoteInputStream@150622ff; line: 1, column: 394] (through reference chain: org.ovirt.engine.api.model.Action[&quot;vm&quot;]-&gt;org.ovirt.engine.api.model.VM[&quot;initialization&quot;]-&gt;org.ovirt.engine.api.model.Initialization[&quot;cloudInit&quot;]-&gt;org.ovirt.engine.api.model.CloudInit[&quot;users&quot;]-&gt;org.ovirt.engine.api.model.Users[&quot;users&quot;]-&gt;org.ovirt.engine.api.model.User[&quot;user_name&quot;])<\/h1><HR size=\"1\" noshade=\"noshade\"><p><b>type<\/b> Status report<\/p><p><b>message<\/b> <u>org.codehaus.jackson.map.exc.UnrecognizedPropertyException: Unrecognized field &quot;user_name&quot; (Class org.ovirt.engine.api.model.User), not marked as ignorable\n at [Source: org.apache.catalina.connector.CoyoteInputStream@150622ff; line: 1, column: 394] (through reference chain: org.ovirt.engine.api.model.Action[&quot;vm&quot;]-&gt;org.ovirt.engine.api.model.VM[&quot;initialization&quot;]-&gt;org.ovirt.engine.api.model.Initialization[&quot;cloudInit&quot;]-&gt;org.ovirt.engine.api.model.CloudInit[&quot;users&quot;]-&gt;org.ovirt.engine.api.model.Users[&quot;users&quot;]-&gt;org.ovirt.engine.api.model.User[&quot;user_name&quot;])<\/u><\/p><p><b>description<\/b> <u>The request sent by the client was syntactically incorrect (org.codehaus.jackson.map.exc.UnrecognizedPropertyException: Unrecognized field &quot;user_name&quot; (Class org.ovirt.engine.api.model.User), not marked as ignorable\n at [Source: org.apache.catalina.connector.CoyoteInputStream@150622ff; line: 1, column: 394] (through reference chain: org.ovirt.engine.api.model.Action[&quot;vm&quot;]-&gt;org.ovirt.engine.api.model.VM[&quot;initialization&quot;]-&gt;org.ovirt.engine.api.model.Initialization[&quot;cloudInit&quot;]-&gt;org.ovirt.engine.api.model.CloudInit[&quot;users&quot;]-&gt;org.ovirt.engine.api.model.Users[&quot;users&quot;]-&gt;org.ovirt.engine.api.model.User[&quot;user_name&quot;])).<\/u><\/p><HR size=\"1\" noshade=\"noshade\"><h3>JBoss Web\/7.0.13.Final<\/h3><\/body><\/html>"

to quote the error-part:

"Unrecognized field &quot;user_name&quot;"

so there is in fact no field 'user_name' as you suggest.

Please have a look.

Comment 7 Sven Kieske 2014-01-02 14:33:02 UTC
Ok I spoke directly to Omer via IRC, here is what we found out:

According to Omer this works using XML in 3.3.2 and master branch

Omer was able to reproduce this error in 3.3.2 using JSON, but unable
to reproduce this using JSON in master.

According to Omer the following patches for JSON (which seems not to
be fully supported, although it is nowhere mentioned in the documentation)
fix this problem:

http://gerrit.ovirt.org/#/c/20704/
http://gerrit.ovirt.org/#/c/20093/

Currently applying patches by hand is no option for me, as I don't know
what side-effects may be introduced and if future upgrades work.

I will evaluate if we can use XML instead of JSON as a workaround.

Maybe such errors could be prevented in the future by adding jenkins jobs
which test if a feature does work via different APIs using different formated
data (xml, json).

Also the API does not report the correct error: the missing/wrong/incomplete JSON implementation.

Instead it silently fails.

Comment 8 Omer Frenkel 2014-01-02 14:47:39 UTC
i verified that using xml works correctly in 3.3.2 with the xml mentioned in comment 1

i also verified on master using json works as well with:
{"async":false,"vm":{"initialization":{"cloud_init":{"host":{"address":"vr00001"},"users":{"user":[{"user_name":"root","password":"123456"}]},"files":{"file":[{"name":"/tmp/file.txt","content":"some content","type":"PLAINTEXT"}]}}}}}}


im setting this to modified for 3.4 so we could verify its really solved once 3.4 is available.

Comment 9 Itamar Heim 2014-01-03 14:01:55 UTC
its incorrect documentation around json - only xml is supported. json, though not disabled, had various issues, and shouldn't have been supported till finally fixed in 3.4 (previously, we were assuming we need a new RESTEasy version to fix the json issues)

Comment 10 Sandro Bonazzola 2014-01-13 13:56:16 UTC
oVirt 3.4.0 alpha has been released including the fix for this issue.

Comment 11 Pavel Novotny 2014-02-18 16:57:25 UTC
Verified in ovirt-engine-3.4.0-0.7.beta2.el6.noarch.

Verification steps:
1. Create new VM.
2. Run it via REST API / JSON with cloud-init data:
-~- POST /ovirt-engine/api/vms/<uuid>/start
{ "async": false,
  "vm": {
    "initialization": {
      "cloud_init": {
        "host": {
          "address": "vr00001"
        },
        "users": {
          "user": [
            {
              "user_name": "root",
              "password": "123456"
            }
          ]
        },
        "files": {
          "file": [
            {
              "name": "",
              "content": "custom script",
              "type": "PLAINTEXT"
}]}}}}
-~-

Results:
The VM is started, payload contains data with generated cloud-init config-drive.

Content of the config-drive CD attached to the VM:
-~-
# cat meta_data.json 
{
  "launch_index" : "0",
  "availability_zone" : "nova",
  "name" : "vr00001",
  "hostname" : "vr00001",
  "uuid" : "f30b8357-6f91-4e40-82ef-259ba8b55b20",
  "meta" : {
    "essential" : "false",
    "role" : "server",
    "dsmode" : "local"
  }
}

# cat user_data 
#cloud-config
customScript: custom script
output:
  all: '>> /var/log/cloud-init-output.log'
user: root
password: '123456'
runcmd:
- 'sed -i ''/^datasource_list: /d'' /etc/cloud/cloud.cfg; echo ''datasource_list:
  ["NoCloud", "ConfigDrive"]'' >> /etc/cloud/cloud.cfg'
-~-

The 'password' section is now present.

Comment 12 Sandro Bonazzola 2014-03-31 12:25:59 UTC
this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released


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