Bug 1715355

Summary: Internal capsule not in Default organization and location on fresh install of Sat 6.6
Product: Red Hat Satellite Reporter: Peter Ondrejka <pondrejk>
Component: Foreman ProxyAssignee: Lukas Zapletal <lzap>
Status: CLOSED DUPLICATE QA Contact: Lukas Pramuk <lpramuk>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.6.0CC: aruzicka, inecas
Target Milestone: Unspecified   
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-06 16:38:08 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:
Attachments:
Description Flags
screenshot1
none
screenshot2 none

Description Peter Ondrejka 2019-05-30 07:53:56 UTC
Description of problem:

On freshly installed Satellite 6.6, the internal capsule does not appear under Infrastructure > Capsules under Default Org/Loc context.

When viewing it under any context, it doesn't appear to have org and loc assigned (see screenshot1). Though when editing a capsule, default org and loc are selected under respective tabs (see screenshot2). 

Note that when hitting Submit in the Capsule edit mode (without actually making any changes), the capsule is correctly assigned to default org and loc and the issue disappears.

Version-Release number of selected component (if applicable):
satellite-6.6.0-5.beta.el7sat.noarch

How reproducible:
always

Actual results:
Internal capsule not treated as belonging to a default context 

Expected results:
capsuel in def org/loc by default

Additional info:

This hurts us for example when testing remote execution on fresh satellite, all jobs fail with: "RuntimeError - Could not use any Capsule. Consider configuring remote_execution_global_proxy, remote_execution_fallback_proxy in settings" even though the setttings are correctly set

Comment 3 Peter Ondrejka 2019-05-30 07:54:35 UTC
Created attachment 1575136 [details]
screenshot1

Comment 4 Peter Ondrejka 2019-05-30 07:55:10 UTC
Created attachment 1575137 [details]
screenshot2

Comment 5 Brad Buckingham 2019-06-06 16:38:08 UTC

*** This bug has been marked as a duplicate of bug 1709695 ***