Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1514915 - Unable to create location with organization_ids: [1] - Organizations is invalid
Summary: Unable to create location with organization_ids: [1] - Organizations is invalid
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Organizations and Locations
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium vote
Target Milestone: Unspecified
Assignee: Tomer Brisker
QA Contact: Roman Plevka
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-19 12:38 UTC by Roman Plevka
Modified: 2019-04-01 20:27 UTC (History)
8 users (show)

Fixed In Version: foreman-1.15.6.26-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-21 16:54:37 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 22043 None None None 2017-12-20 16:55:30 UTC

Description Roman Plevka 2017-11-19 12:38:01 UTC
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

Comment 1 Justin Sherrill 2017-11-20 16:13:24 UTC
Are you sure the organization has an id of 1?

Comment 4 Tomer Brisker 2017-11-21 09:53:51 UTC
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 ''"

Comment 5 Roman Plevka 2017-11-21 11:06:53 UTC
(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"]}
}

Comment 6 Roman Plevka 2017-11-22 19:27:41 UTC
(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.

Comment 8 Tomer Brisker 2017-12-20 14:47:40 UTC
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.

Comment 10 Tomer Brisker 2017-12-20 16:55:27 UTC
Created redmine issue http://projects.theforeman.org/issues/22043 from this bug

Comment 11 pm-sat@redhat.com 2017-12-20 17:24:59 UTC
Upstream bug assigned to tbrisker@redhat.com

Comment 12 pm-sat@redhat.com 2017-12-20 17:25:04 UTC
Upstream bug assigned to tbrisker@redhat.com

Comment 13 pm-sat@redhat.com 2018-01-02 17:26:47 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/22043 has been resolved.

Comment 14 Roman Plevka 2018-01-09 08:49:34 UTC
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  |            
---|-------|------|------------

Comment 15 Roman Plevka 2018-01-09 08:59:21 UTC
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

Comment 16 pm-sat@redhat.com 2018-02-21 16:54:37 UTC
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


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