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

Summary: Unable to create location with organization_ids: [1] - Organizations is invalid
Product: Red Hat Satellite 6 Reporter: Roman Plevka <rplevka>
Component: Organizations and LocationsAssignee: Tomer Brisker <tbrisker>
Status: CLOSED ERRATA QA Contact: Roman Plevka <rplevka>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.3.0CC: bbuckingham, dlobatog, ehelms, jsherril, rplevka, sghai, sjagtap, tbrisker
Target Milestone: UnspecifiedKeywords: 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: ---

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