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
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 to
production`.
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
looks like it worked.