Test with logging into staging registry

[jamepark4]

Evaluating FR3 to FR4 updates on hybrid environments.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ciecierski]

According to latest mail announcement this registry.stage.redhat.io is correct one now.

[ciecierski]

Change pull request title and name of tasks in the tasks file. Other than that it looks good to me.

[danpawlik]

If that is a test, converting into a draft, otherwise change commit message and be more verbose. Thanks

[sathlan]

Kinda make sense. But I agree that more context is needed. I guess that the cifmw_registry_token credential now points to staging instead of redhat cdn hence the change, but that should be clarified.

[sathlan]

So this shoudn't work and you should have:

    - 'Error: copying system image from manifest list: Source image rejected: A signature
      was required, but no signature exists'

please confirm.

Furthermore I think the right solution is to activate redirection here.

Full working setup would be:

1. add those lines to /etc/containers/registries.conf:

[[registry]]
  prefix = ""
  location = "registry.redhat.io"

  [[registry.mirror]]
    location = "registry.stage.redhat.io"
    pull-from-mirror = "digest-only"

2. run those command as zuul user:

mkdir ~/.config/containers
echo '{"default":[{"type":"insecureAcceptAnything"}]}' > ~/.config/containers/policy.json

No need to rename the image.

Those are what we use to setup the compute node with staging.

[sathlan]

I mentionned in my comment I don't think this work (it should fail on signature verification) and is the right approach IMHO. We should use what we use on the edpm compute node: proxy registries setup and ignore signature.

Of course if changing the name just work, then I will reconsider ... please let me know.

For me doing the setup in the posted comment resolved the issue without changing the image name.

[jamepark4]

@sathlan I can confirm that my hybrid deployment is fully updating now with this image name change applied, but I also don't have a preference on how to unblock the updates job downstream. I can also test what you are recommending if that is the preferred route.

[sathlan]

Nice. I'm still wondering how does your deployment avoid the signature problem, do you know ?

[jamepark4]

@sathlan this is just to pull an image on the initial controller correct? I was under the impression that was already configured to handle the staging registry in this instance. I can redeploy and autohold to inspect it's registry configuration to confirm.

[ciecierski]

@jamepark4 you are correct, this login is to pull an image on the controller-0
I don't think controller-0 is configured to pull any image from registry.redhat.io/ registry.stage.redhat.io. Openstackclient is the only container we are pulling from there. Container is pulled only during update phase.

[jamepark4]

@sathlan @ciecierski yea it's strange I can't yet find what's applying the configuration to controller-0 but I didn't need to add the insecure policy to get the update to progress. It appears to already have been present:

[zuul@controller-0 containers]$ cat /etc/containers/policy.json | jq -r .default
[
  {
    "type": "insecureAcceptAnything"
  }
]
[zuul@controller-0 containers]$ podman ps | grep client
3a1f6100a93f  registry.stage.redhat.io/rhoso/openstack-openstackclient-rhel9@sha256:0b524618600a790fadb213e3421e4f3f45310a5706e656ffe5d6be51da252a6a  /usr/bin/sleep in...  4 days ago  Up 4 days                        lopenstackclient

I know downstream has some patches that add the policy to the computes, but I'm not using that in this deployment.