When I try the following curl command, I get "Name can't be blank": <pre> $ curl -k -u admin:changeme -H "Content-Type: application/json" -X POST http://localhost:3000/api/v2/hosts -d '{"name": "TEST"}' </pre> It looks like the name param is getting wrapped in params[:base] instead of params[:host].
Created from redmine issue http://projects.theforeman.org/issues/6674
Upstream bug assigned to tomckay
Connecting redmine issue http://projects.theforeman.org/issues/6696 from this bug
Moving to POST since upstream bug http://projects.theforeman.org/issues/6696 has been closed ------------- Joseph Magen Applied in changeset commit:a2610e980c66663db2a200cedceb2a0b53918f3a.
Currently failed because of https://bugzilla.redhat.com/show_bug.cgi?id=1135651.
Failed based on Comment 8
Comment 8 refers to https://bugzilla.redhat.com/show_bug.cgi?id=1135651 which is fixed by https://github.com/theforeman/foreman/pull/1732 However, fix to this bug was already merged with commit a2610e980c66663db2a200cedceb2a0b53918f3a
PR #1732 reached an impasse. The parameters are technically required on all situations. It depends on various scenarios. See also http://projects.theforeman.org/issues/6997
POSTing to `api/v2/host` with this JSON payload: { u'host': { 'architecture_id': 73, 'domain_id': 67, 'environment_id': 105, 'location_id': 341, 'mac': u'12:16:49:91:72:21', 'medium_id': 68, 'operatingsystem_id': 67, 'organization_id': 342, 'ptable_id': 64, 'root_pass': u'…', }, 'name': u'dPRwSiClzbUNZeLLApBC', } Results in this JSON response: { u'error': { u'errors': {u'name': [u"can't be blank", u'is invalid']}, u'id': None, u'full_messages': [u"Name can't be blank", u'Name is invalid'] } } Moving the "name" parameter into the inner hash succeeds: { u'host': { 'architecture_id': 73, 'domain_id': 67, 'environment_id': 105, 'location_id': 341, 'mac': u'12:16:49:91:72:21', 'medium_id': 68, 'name': u'dPRwSiClzbUNZeLLApBC', 'operatingsystem_id': 67, 'organization_id': 342, 'ptable_id': 64, 'root_pass': u'…', } } This bug has not been fixed. Placing "name" in the outer hash still prevents API users from creating hosts. However, it's worth noting that the API doc specifically shows that the "name" parameter should be in the inner hash in the first place, along with all other parameters: > host[name] > required > Value: String If you do try to create a host by plaing all parameters in an outer hash, you'll receive this response: { u'error': { u'message': u'operatingsystem_id is not allowed as nested parameter for hosts. Allowed parameters are hostgroup_id, location_id, organization_id, environment_id' } } I do not think that this bug is valid. It is possible to create a host via the API, and this bug describes an action which is not listed as being possible.
Ah, I forgot to mention that this bug was tested against systems running: * Satellite-6.1.0-RHEL-6-20150310.0 * Satellite-6.1.0-RHEL-7-20150310.0
Automated tests should be added to QE's test suite shortly. See: https://github.com/SatelliteQE/robottelo/pull/1978
Per #c14, I am closing this out. Discussions wit Jmagen agree.