Katello-nightly-rpm-pipeline 509 failed

Katello nightly pipeline failed:

https://ci.theforeman.org/job/katello-nightly-rpm-pipeline/509/

Current failure is in the registration:

not ok 18 register subscription manager with username and password
# (in test file fb-content-katello.bats, line 141)
#   `subscription-manager register --force --org="${ORGANIZATION_LABEL}" --username=admin --password=changeme --env=Library' failed with status 70
# rc=1
# This system is currently not registered.
# rc=0
# All local data removed
# rc=0
# Loaded plugins: fastestmirror, product-id, search-disabled-repos, subscription-
#               : manager
# This system is not registered with an entitlement server. You can use subscription-manager to register.
# No Match for argument: katello-ca-consumer-*
# No Packages marked for removal
# rc=0
# Retrieving http://localhost/pub/katello-ca-consumer-latest.noarch.rpm
# Preparing...                          ########################################
# Updating / installing...                  
# katello-ca-consumer-pipeline-katello-n########################################
# Validation failed: Environment with id 1 doesn't exist or is not assigned to proper organization and/or location
# Registering to: pipeline-katello-nightly-centos7.n45.example.com:443/rhsm
not ok 19 register subscription manager with activation key
# (in test file fb-content-katello.bats, line 154)
#   `subscription-manager list --consumed | grep "${PRODUCT}"' failed
# rc=1  
# This system is currently not registered.
# rc=0
# All local data removed
# rc=70
# Validation failed: Environment with id 1 doesn't exist or is not assigned to proper organization and/or location

@katello Could you please investigate this nightly test failure

The 3.9 RC is blocked by this same failure.

to shed some light on the failure - the bats test creates an org (“Test Organization”) which comes with an id 4.
The subscription-manager register... command sends a correct GET request to:
/rhsm/owners/Test_Organization/environments?name=Library

This endpoint replies with the id and subman creates another PST request using it:
/rhsm/environments/83480f729a55d54a840028bae1baf584/consumers

Completed 422 Unprocessable Entity in 268ms (Views: 0.3ms | ActiveRecord: 27.4ms)
[D|app|95e68] With body: {"displayMessage":"Validation failed: Environment with id 1 doesn't exist or is not assigned to proper organization and/or location","errors":{"environment_id":["with id 1 doesn't exist or is not assigned to proper organization and/or location"]}}

The problem is, the Library env of the Test Organization does NOT have the id 1.
In fact, every single Organization has its own “Library” environment, but the id differs:

# hammer lifecycle-environment list
---|---------|--------
ID | NAME    | PRIOR  
---|---------|--------
3  | Library |        
2  | Library |        
1  | Library |        
4  | Test    | Library
---|---------|--------
# hammer lifecycle-environment info --id 3
ID:                          3
Name:                        Library
Label:                       Library
Description:                 
Organization:                Test Organization
Library:                     true
Prior Lifecycle Environment:

Does rhsm endpoint evaluate the LCE id correctly? from the behaviour I’d say it returns the first of the returned list.

What is the response of this endpoint? Looking at the code doesn’t look like anything in the controller changed since 3.7, so most likely either 1. something in bats changed, or 2. Rails 5.2 broke it somehow.

ok, so we (together with @jsherrill) managed to trace this down to a problem with a production puppet environment not belonging to the test org. In fact, the installer seems not to add it to any org/loc whatsoever. But at the same time, it sets the 'default puppet environmentglobal setting toproduction`.
Not sure what is the desired behaviour but i would say it should belong to a Default Org at least (if orgs are enabled).
If the behavior is ok, the bats tests need to be updated to create/assign the Puppet env to the org.

I dug around a bit and figured out the problem, although i’m not sure
why this is a recent issue.

The environment ‘1’ mentioned isn’t referring to lifecycle environments,
its referring to the puppet environment. This only is a problem if the
host checked in via puppet prior to registering with sub-man and thus
(in this case) associated with the ‘production’ environment.

I would have expected this to be a problem for quite a while (although I
haven’t dug through the commit history too much). The last passing build
was on october 17th. Will dig into a solution tomorrow, unless someone
has suggestions sooner (And this issue has a very big deja-vu feeling to
it).

Justin

Is this maybe related to the fix in puppet-foreman_proxy we did in puppet-foreman_proxy#456? This makes sure the machine can check in to puppet.

Ah! That plus this commit:

probably both contributed to this issue popping up. Will brainstorm
some possible fixes.

Justin

1 Like

PR open: https://github.com/theforeman/forklift/pull/855

looks like it worked.