Katello nightly pipeline failed:
https://ci.theforeman.org/job/katello-nightly-rpm-pipeline/142/
foreman-katello-upgrade-nightly-test (failed)
foreman-katello-nightly-test (passed)
The upgrade test fails because the Foreman Proxy with the Puppetserver is not assigned to the organization. That makes sense because Feature #26092: When only one taxonomy of specific type is defined, api should default to that taxonomy - Foreman works on new creations, but this is an upgrade so it already existed.
@tbrisker thoughts?
Could you point me to what stage this proxy is created in the upgrade scenario?
If i’m not mistaken, since katello always created taxonomies, the seed that assigns all existing resources to the taxonomies doesn’t execute, but i would expect that the older katello version should have already assigned the proxy properly - or this test would have failed already in older versions before the core change regarding taxonomies?
My theory would be that it fails during the 1.20/3.10 installation, but maybe it’d be best to try this out and see what’s in the database? https://github.com/theforeman/forklift/blob/master/docs/testing.md#pipeline-testing describes how to run it, but the tl;dr is:
ansible-playbook pipelines/upgrade_pipeline.yml -e forklift_state=up -e pipeline_os=centos7 -e pipeline_type=katello -e pipeline_version=nightly
I think its more that the environment isn’t associated:
# Environment with id 1 doesn't exist or is not assigned to proper
organization and/or location
which katello hasn’t ever done with the production environment
good point. I wonder how this worked in the past and why it no longer does, since the katello tests always ran with taxonomies enabled.
I wonder if we should just restore the environment assignment to the taxonomies and skip only the proxy assignment.
Why don’t we create every resource in default taxonomies now when it’s to use them mandatory? We already set context in Taxononix in after_initialize, let’s just add default one for new records if none is set. Perhaps too risky for current release though.
If there is only one taxonomy, we do now, but if there is more than one than we can’t really tell which one should be used easily. We could decide to use the same default as the one set for hosts, but it might lead to unexpected results.
I’m fine with assigning the environment in 1.23, but this isn’t limited to automation. Users do run into this on a fresh installation.
hmmm, we might need to handle environments created by the importer similar to how we do for api requests, but i think until that’s fixed we should change bats back to assign the environment so we unblock katello nightlies. no idea why this only occurs in katello upgrades and not elsewhere, but likely because the environment is created earlier with different taxonomies to the host.
It might also exist on Foreman, but we don’t do upgrade tests (yet) for that.
looks like this has finally been resolved with #146 passing.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.