Bug 1514915
| Summary: | Unable to create location with organization_ids: [1] - Organizations is invalid | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Roman Plevka <rplevka> |
| Component: | Organizations and Locations | Assignee: | Tomer Brisker <tbrisker> |
| Status: | CLOSED ERRATA | QA Contact: | Roman Plevka <rplevka> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.3.0 | CC: | bbuckingham, dlobatog, ehelms, jsherril, rplevka, sghai, sjagtap, tbrisker |
| Target Milestone: | Unspecified | Keywords: | Triaged |
| Target Release: | Unused | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | foreman-1.15.6.26-1 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-02-21 16:54:37 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Are you sure the organization has an id of 1? I tested this with 6.3 and upstream, this does fail in 6.3 but not in upstream. I made sure the organization id existed before sending the request, if it doesn't the message is different - "Resource location not found by id ''" (In reply to Justin Sherrill from comment #1) > Are you sure the organization has an id of 1? yes. # hammer organization list --search="id=1" ---|----------------------|----------------------|-------------|----------------------|------------ ID | TITLE | NAME | DESCRIPTION | LABEL | DESCRIPTION ---|----------------------|----------------------|-------------|----------------------|------------ 1 | Default Organization | Default Organization | | Default_Organization | ---|----------------------|----------------------|-------------|----------------------|------------ [root@cisco-b200m1-04 ~]# curl -sku admin:changeme -d '{"location": {"name": "foo6", "organization_ids": [1]}}' -H 'Content-Type: application/json' https://$(hostname)/api/v2/locations { "error": {"id":null,"errors":{"organizations":["is invalid"]},"full_messages":["Organizations is invalid"]} } (In reply to Tomer Brisker from comment #4) > I tested this with 6.3 and upstream, this does fail in 6.3 but not in > upstream. I made sure the organization id existed before sending the > request, if it doesn't the message is different - "Resource location not > found by id ''" I have the reproducer: To make organization "invalid", just create 1 org and 1 loc and make sure, the org does NOT have the loc assigned. Now make the loc a default location for newly subscribed hosts. Then, register some content host to the Org. This will effectively bring inconsistency into the org, since its host is restricted to a location which does not belong to the Org. You can't use such organization for new location assignments until you fix the discrepency by assigning the loc to the org, or remove the the host. Correction, this is also present upstream. The condition is that the organization being assigned has to be invalid - eg. has a hosts that are assigned resources which aren't in the organization. Created redmine issue http://projects.theforeman.org/issues/22043 from this bug Upstream bug assigned to tbrisker Upstream bug assigned to tbrisker Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/22043 has been resolved. FAILED QA:
this now also accepts non-existent locations - if the location does not exist, it will automatically create it, which is most probably not a desired behavior (at least it's inconsistent with the rest of the resource behavior).
# hammer location list --search="name=foo"
---|-------|------|------------
ID | TITLE | NAME | DESCRIPTION
---|-------|------|------------
[root@zzzap ~]# curl -sku admin:changeme -d '{"location": {"name": "foo", "organization_ids": [6]}}' -H 'Content-Type: application/json' https://$(hostname)/api/v2/locations >/dev/null
[root@zzzap ~]# hammer location list --search="name=foo"
---|-------|------|------------
ID | TITLE | NAME | DESCRIPTION
---|-------|------|------------
10 | foo | foo |
---|-------|------|------------
VERIFIED on sat6.3.0-31 (In reply to Roman Plevka from comment #14) > FAILED QA: > > this now also accepts non-existent locations - if the location does not > exist, it will automatically create it, which is most probably not a desired > behavior (at least it's inconsistent with the rest of the resource behavior). > > # hammer location list --search="name=foo" > ---|-------|------|------------ > ID | TITLE | NAME | DESCRIPTION > ---|-------|------|------------ > [root@zzzap ~]# curl -sku admin:changeme -d '{"location": {"name": "foo", > "organization_ids": [6]}}' -H 'Content-Type: application/json' > https://$(hostname)/api/v2/locations >/dev/null > [root@zzzap ~]# hammer location list --search="name=foo" > ---|-------|------|------------ > ID | TITLE | NAME | DESCRIPTION > ---|-------|------|------------ > 10 | foo | foo | > ---|-------|------|------------ I'm sorry, (lack of coffee), i did not realized I'm doing POST request (thought i was doing PUT all the time). This is ofc the desired behavior and i can VERIFY this 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-2018:0336
|
Description of problem: this seems to be a regression since 6.2: # curl -sku admin:changeme -d '{"location": {"name": "foo6", "organization_ids": [1]}}' -H 'Content-Type: application/json' https://$(hostname)/api/v2/locations { "error": {"id":null,"errors":{"organizations":["is invalid"]},"full_messages":["Organizations is invalid"]} } - specifying other (existing) organization id(s) works as expected Version-Release number of selected component (if applicable): 6.3.0-25 How reproducible: always Actual results: Organizations is invalid Expected results: Location created and assigned to Default Organization