Description

As a user, I want to invoke a Serverless function from the developer console. This action should be available as a page and as a modal.

Acceptance Criteria

1. A backend proxy to invoke a serverless function (or a k8s service in general) from the frontend without a public route.
2. The API endpoint should be only accessible to logged-in users.
3. Should also work when the bridge is running off-cluster (as developers start them mostly for local development)

Additional Details:

This will be similar to the web terminal proxy, except that no auth headers will be passed to the underlying service.

We need something similar to:

POST /proxy/in-cluster

{
  endpoint: string
  # Or just service: string ?? tbd.

  headers: Record<string, string | string[]>
  body: string
  timeout: number
}

• https://github.com/openshift/console/pull/12789

Description

As a user, I want to invoke a Serverless function from the developer console. This action should be available as a page and as a modal.

This story depends on ODC-7273, ODC-7274, and ODC-7288. This story should bring the backend proxy, and the frontend together and finalize the work.

Acceptance Criteria

1. Write proper types if they are missed
2. Connect the form and invoke a serverless function, consume and show the response
3. Unit testes
4. E2E tests

Additional Details:

• https://github.com/openshift/console/pull/12755

Description

Current YAMLEditor also supports other languages like JSON. Therefore need to rename the component.

Acceptance Criteria

1. Rename all instances of YAMLEditor to CodeEditor

Additional Details:

• https://github.com/openshift/console/pull/12708

Description

As a user, I want to invoke a Serverless function from the developer console. This action should be available as a page and as a modal.

This story is to evaluate a good UI for this and check this with our PM (Serena) and the Serverless team (Naina and Lance).

Acceptance Criteria

1. Add a new page with title "Invoke Serverless function {function-name}" and should be available via a new URL (/serverless/ns/:ns/invoke-function/:function-name/).
2. Implement a form with formik to "invoke" (console.log for now) Serverless functions, without writing the network call for this already. Focus on the UI to get feedback as early as possible. Use reusable, well-named components anyway.
3. The page should be also available as a modal. Add a new action to all Serverless Services with the label (tbd) to open this modal from the Topology graph or from the Serverless Service list view.
4. The page should have two tabs or two panes for the request and response. Each of this tabs/panes should have again two tabs, "similar" to the browser network inspector. See below for what we know currently.
5. Get confirmation from Christoph, Serena, Naina, and Lance.
6. Disable the action until we implement the network communication in ODC-7275 with the serverless function.
7. No e2e tests are needed for this story.

Additional Details:

Information the form should show:

1. Request tab shows "Body" and "Options" tab
   1. Body is just a full size editor. We should reuse our code editor.
   2. Options contains:
      1. Auto complete text field “Content type” with placeholder “application/json”, that will be used when nothing is entered
      2. Dropdown “Format” with values “cloudevent” (default) and “http”
      3. Text field “Type” with placeholder text “boson.fn”, that will be used when nothing is entered
      4. Text field “Source” with placeholder “/boson/fn”, that will be used when nothing is entered
2. Response tab shows Body and Info tab
   1. Body is a full size editor that shows the response. We should format a JSON string with JSON.stringify(data, null, 2)
   2. Info contains:
      1. Id (id)
      2. Type (type)
      3. Source (source)
      4. Time (time) (formatted)
      5. Content-Type: (datacontenttype)

• https://github.com/openshift/console/pull/12686

Description

This story is to add new Quick Start for installing the Cryostat Operator

Acceptance Criteria

1. Create new Quick Start for installing the Cryostat Operator

Additional Details:

• https://github.com/openshift/console-operator/pull/770

Description

Add below IDE extensions in create serverless form,

• VSCode Knative IDE extension: https://marketplace.visualstudio.com/items?itemName=redhat.vscode-knative
• IntelliJ Knative Plugin: https://plugins.jetbrains.com/plugin/16476-knative--serverless-functions-by-red-hat

Acceptance Criteria

1. In create serverless form add above IDE extensions
2. On click of the link, user needs to take to respective pages
3. Add e2e tests for that

Additional Details:

• https://github.com/openshift/console/pull/12846

Description 

Add OpenShift Quickstart for JBoss EAP 7

Acceptance Criteria

1. Add OpenShift Quickstart for JBoss EAP 7

Additional Details:

• https://github.com/openshift/console-operator/pull/760

This issue is to handle the PR comment - https://github.com/openshift/console-operator/pull/770#pullrequestreview-1501727662 for the issue https://issues.redhat.com/browse/ODC-7292

• https://github.com/openshift/console-operator/pull/773

Description

Update Terminal step of the Guided Tour to indicate that odo CLI is accessible - https://developers.redhat.com/products/odo/overview

Acceptance Criteria

1. Update Guided tour of Web Terminal to add odo CLI link
2. On click of link user has to redirected to respective page

Additional Details:

• https://github.com/openshift/console/pull/12848

Make the list of enabled/disable controllers in OAS reflect enabled/disabled capabilities.

Acceptance criteria:

• OAS allows to specify a list of enabled/disabled APIs (e.g. watches, caches, ...)
• OASO watches capabilities and generates the right configuration for OAS with enabled/disabled list of APIs
• Documentation is properly updated

QE:

• enabled/disable capabilities and validate a given API (DC, Builds, ...) is/is not managed by a cluster:
• checking the OAS logs do/do not log entries about affected API(s)
• DC/Builds objects are created/fail to be created

• https://github.com/openshift/cluster-openshift-apiserver-operator/pull/532
• https://github.com/openshift/openshift-apiserver/pull/366

Following on from https://issues.redhat.com/browse/HOSTEDCP-444 we need to add the steps to enable migration of the Node/CAPI resources to enable workloads to continue running during controlplane migration.

This will be a manual process where controlplane downtime will occur.

This must satisfy a successful migration criteria:

• All HC conditions are positive.
• All NodePool conditions are positive.
• All service endpoints kas/oauth/ignition server... are reachable.
• Ability to create/scale NodePools remains operational.

We need to validate and document this manually for starters.

Eventually this should be automated in the upcoming e2e test.

We could even have a job running conformance tests over a migrated cluster

• https://github.com/openshift/hypershift/pull/2598
• https://github.com/openshift/hypershift/pull/2481
• https://github.com/openshift/hypershift/pull/2358
• https://github.com/openshift/hypershift/pull/2276

• https://github.com/openshift/cluster-capi-operator/pull/117

{}USER STORY:{}

As an OpenShift administrator, I want to apply an IP configuration so that I can adhere to my organizations security guidelines.

{}DESCRIPTION:{}

The vSphere machine controller needs to be modified to convert nmstate to `guestinfo.afterburn.initrd.network-kargs` upon cloning the template for a new machine.  An example of this is here: https://github.com/openshift/machine-api-operator/pull/1079

{}Required:{}

• PR is approved
• Associated test(s) are created in https://github.com/openshift/cluster-api-actuator-pkg 

{}Nice to have:{}

{}ACCEPTANCE CRITERIA:{}

{}ENGINEERING DETAILS:{}

https://github.com/openshift/enhancements/pull/1267

• https://github.com/openshift/machine-api-operator/pull/1079

• https://github.com/openshift/cluster-authentication-operator/pull/608

e2e test in our ci to override kernel

Possibly repurpose https://github.com/openshift/os/tree/master/tests/layering

• https://github.com/openshift/machine-config-operator/pull/3558

User Story:

As a (user persona), I want to be able to:

• Add custom security groups for compute nodes
• Add custom security groups for control plane nodes

so that I can achieve

• Control Plane and Compute nodes can support operational specific security rules. For instance: specific traffic may be required for compute vs control plane nodes.

Acceptance Criteria:

Description of criteria:

• The control plane and compute machine sections of the install config accept user input as additionalSecurityGroupIDs (when using the aws platform).

(optional) Out of Scope:

Detail about what is specifically not being delivered in the story

Engineering Details:

•  

  additionalSecurityGroupIDs:
    description: AdditionalSecurityGroupIDs contains IDs of
      additional security groups for machines, where each ID
      is presented in the format sg-xxxx.
    items:
      type: string
    type: array 

This requires/does not require a design proposal.

• https://github.com/openshift/installer/pull/7151

We need to have an operator to inject dashboard jsonnet. E.g. etcd team injects their dashboard jsonnet using their operator in the form of a config map. 

https://redhat-internal.slack.com/archives/C027U68LP/p1683574004805639?thread_ts=1683573783.216759&cid=C027U68LP

We will need similar approach for node dashboard. 

• https://github.com/openshift/machine-config-operator/pull/3708

Enhancement proposed for Azure tags support in OCP, requires install-config CRD to be updated to include gcp userLabels for user to configure, which will be referred by the installer to apply the list of labels on each resource created by it and as well make it available in the Infrastructure CR created.

Below is the snippet of the change required in the CRD

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata: 
  name: installconfigs.install.openshift.io
spec: 
  versions: 
  - name: v1
    schema: 
      openAPIV3Schema: 
        properties: 
          platform: 
            properties: 
              gcp: 
                properties: 
                  userLabels: 
                    additionalProperties: 
                      type: string
                    description: UserLabels additional keys and values that the installer
                      will add as labels to all resources that it creates. Resources
                      created by the cluster itself may not include these labels.
                  type: object

This change is required for testing the changes of the feature, and should ideally get merged first.

Acceptance Criteria

• Code linting, validation and best practices adhered to
• User should be able to configure gcp user defined labels in the install-config.yaml
• Fields descriptions

• https://github.com/openshift/installer/pull/7126

Enhancement proposed for GCP labels and tags support in OCP requires making use of latest APIs made available in terraform provider for google and requires an update to use the same.

Acceptance Criteria

• Code linting, validation and best practices adhered to.

• https://github.com/openshift/installer/pull/7201

Enhancement proposed for GCP tags support in OCP, requires cluster-image-registry-operator to add gcp userTags available in the status sub resource of infrastructure CR, to the gcp storage resource created.

cluster-image-registry-operator uses the method createStorageAccount() to create storage resource which should be updated to add tags after resource creation.

Acceptance Criteria

• Code linting, validation and best practices adhered to
• UTs and e2e are added/updated

• https://github.com/openshift/cluster-image-registry-operator/pull/873

cluster-config-operator makes Infrastructure CRD available for installer, which is included in it's container image from the openshift/api package and requires the package to be updated to have the latest CRD.

• https://github.com/openshift/cluster-config-operator/pull/335

Installer creates below list of gcp resources during create cluster phase and these resources should be applied with the user defined labels and the default OCP label kubernetes-io-cluster-<cluster_id>:owned

Resources List

Acceptance Criteria:

• Code linting, validation and best practices adhered to
• List of gcp resources created by installer should have user defined labels and as well as the default OCP label.

• https://github.com/openshift/installer/pull/7153

Enhancement proposed for GCP labels support in OCP, requires cluster-image-registry-operator to add gcp userLabels available in the status sub resource of infrastructure CR, to the gcp storage resource created.

cluster-image-registry-operator uses the method createStorageAccount() to create storage resource which should be updated to add labels.

Acceptance Criteria

• Code linting, validation and best practices adhered to
• UTs and e2e are added/updated

• https://github.com/openshift/cluster-image-registry-operator/pull/872
• https://github.com/openshift/cluster-image-registry-operator/pull/887

Enhancement proposed for GCP labels support in OCP, requires machine-api-provider-gcp to add azure userLabels available in the status sub resource of infrastructure CR, to the gcp virtual machines resource and the sub-resources created.

Acceptance Criteria

• Code linting, validation and best practices adhered to
• UTs and e2e are added/updated

• https://github.com/openshift/machine-api-provider-gcp/pull/53
• https://github.com/openshift/machine-api-provider-gcp/pull/56

• https://github.com/openshift/gcp-pd-csi-driver-operator/pull/74

Installer generates Infrastructure CR in manifests creation step of cluster creation process based on the user provided input recorded in install-config.yaml. While generating Infrastructure CR platformStatus.gcp.resourceLabels should be updated with the user provided labels(installconfig.platform.gcp.userLabels).

Acceptance Criteria

• Code linting, validation and best practices adhered to
• Infrastructure CR created by installer should have gcp user defined labels if any, in status field.

• https://github.com/openshift/installer/pull/7138

As an engineer I want the capability to implement CI test cases that run at different intervals, be it daily, weekly so as to ensure downstream operators that are dependent on certain capabilities are not negatively impacted if changes in systems CCO interacts with change behavior.

Acceptance Criteria:

Create a stubbed out e2e test path in CCO and matching e2e calling code in release such that there exists a path to tests that verify working in an AWS STS workflow.

• https://github.com/openshift/origin/pull/27887

• https://github.com/openshift/oc-mirror/pull/627

Description of the problem:

Using FCP (multipath) devices for zVM node 
parmline:

rd.neednet=1 console=ttysclp0 coreos.live.rootfs_url=http://172.23.236.156:8080/assisted-installer/rootfs.img ip=10.14.6.8::10.14.6.1:255.255.255.0:master-0:encbdd0:none nameserver=10.14.6.1 ip=[fd00::8]::[fd00::1]:64::encbdd0:none nameserver=[fd00::1] zfcp.allow_lun_scan=0 rd.znet=qeth,0.0.bdd0,0.0.bdd1,0.0.bdd2,layer2=1 rd.zfcp=0.0.8007,0x500507630400d1e3,0x4000401e00000000 rd.zfcp=0.0.8107,0x50050763040851e3,0x4000401e00000000 random.trust_cpu=on rd.luks.options=discard ignition.firstboot ignition.platform.id=metal console=tty1 console=ttyS1,115200n8

shows disk limitation error in the UI. 

<see attached image>

How reproducible:

Attach two FCP devices to a zVM node. Create a cluster and boot zVM node into discovery service. Host discovery panel shows an error for discovered host.

Steps to reproduce:

1. Attach two FCP devices to the zVM.

2. Create new cluster using the AI UI and configure discovery image

3. Boot zVM node 

4. Waiting until node is showing up on the Host discovery panel.

5. FCP devices are not recognized as valid option

Actual results:

FCP devices can't be used as installable disk

Expected results:
FCP device can be used for installation (multipath must be activated after installation:
https://docs.openshift.com/container-platform/4.13/post_installation_configuration/ibmz-post-install.html#enabling-multipathing-fcp-luns_post-install-configure-additional-devices-ibmz)

• https://github.com/openshift/assisted-service/pull/5269

Discovering an regression on staging where default is set to minimal ISO preventing installation of OCP 4.13 for s390x architecture.

See following older bugs addressing the same issue I guess

1. MGMT-14298

• https://github.com/openshift/assisted-service/pull/5302

Description of the problem:

Using DASD devices are not recognized correctly if attached and used for a zVM node.
<see attached screenshot>

Attach two FCP devices to a zVM node. Create a cluster and boot zVM node into discovery service. Host discovery panel shows an error for discovered host.

Steps to reproduce:

1. Attach two DASD devices to the zVM.

2. Create new cluster using the AI UI and configure discovery image

3. Boot zVM node 

4. Waiting until node is showing up on the Host discovery panel.

5. DASD devices are not recognized as valid option

Actual results:

DASD devices can't be used as installable disk

Expected results:
DASD device can be used for installation. User can choose the on which device AI will install to.

• https://github.com/openshift/assisted-installer-agent/pull/549

Epic Goal

As an OpenShift infrastructure owner I need to deploy OCP on OpenStack with the installer-provisioned infrastructure workflow and configure my own load balancers

Why is this important?

Customers want to use their own load balancers and IPI comes with built-in LBs based in keepalived and haproxy. 

Scenarios

1. A large deployment routed across multiple failure domains without stretched L2 networks, would require to dynamically route the control plane VIP traffic through load-balancers capable of living in multiple L2.
2. Customers who want to use their existing LB appliances for the control plane.

Acceptance Criteria

• Should we require the support of migration from internal to external LB?
• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• QE - must be testing a scenario where we disable the internal LB and setup an external LB and OCP deployment is running fine.
• Documentation - we need to document all the gotchas regarding this type of deployment, even the specifics about the load-balancer itself (routing policy, dynamic routing, etc)

Dependencies (internal and external)

1. Fixed IPs would be very interesting to support, already WIP by vsphere (need to Spike on this): https://issues.redhat.com/browse/OCPBU-179
2. Confirm with customers that they are ok with external LB or they prefer a new internal LB that supports BGP

Previous Work:

vsphere has done the work already via https://issues.redhat.com/browse/SPLAT-409

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>

• https://github.com/openshift/installer/pull/7127

• https://github.com/openshift/installer/pull/6993

DoD:

Refactor the E2E tests following new pattern with 1 HostedCluster and targeted NodePools:

• nodepool_upgrade_test.go

• https://github.com/openshift/hypershift/pull/2256

Currently the `agent create image` command takes care to extract the agent-tui binary (and required libs) from the `assisted-installer-agent` image (shipped in the release as `agent-installer-node-agent`).
Once the agent-tui will be available instead from the `agent-installer-utils` image, it would be necessary to update accordingly the installer code (see https://github.com/openshift/installer/blob/56e85bee78490c18aaf33994e073cbc16181f66d/pkg/asset/agent/image/agentimage.go#L81)

• https://github.com/openshift/installer/pull/7212

agent-tui is currently built and shipped using the assisted-installer-agent repo. Since it will be move into its own repository (agent-installer-utils), it's necessary to cleanup the previous code.

• Remove agent-tui and nmstate dependencies from Docker image (https://github.com/openshift/assisted-installer-agent/blob/master/Dockerfile.ocp)
• Remove source (and vendored code) (https://github.com/openshift/assisted-installer-agent/tree/master/src/agent_tui)

• https://github.com/openshift/assisted-installer-agent/pull/563

Currently the agent-tui displays always the additional checks (nslookup/ping/http get), even when the primary check (pull image) passes. This may cause some confusion to the user, due the fact that the additional checks do not prevent the agent-tui to complete successfully but they are just informative, to allow a better troubleshooting of the issue (so not needed in the positive case).

The additional checks should then be shown only when the primary check fails for any reason.

• https://github.com/openshift/assisted-installer-agent/pull/512

When the UI is active in the console events messages that are generated will distort the interface and make it difficult for the user to view the configuration and select options. An example is shown in the attached screenshot.

• https://github.com/openshift/installer/pull/6925

When the agent-tui is shown during the initial host boot, if the pull release image check fails then an additional checks box is shown along with a details text view.
The content of the details view gets continuosly updated with the details of failed check, but the user cannot move the focus over the details box (using the arrow/tab keys), thus cannot scroll its content (using the up/down arrow keys)

• https://github.com/openshift/assisted-installer-agent/pull/514

The openshift-install agent create image will need to fetch the agent-tui executable so that it could be embedded within the agent ISO. For this reason the agent-tui must be available in the release payload, so that it could be retrieved even when the command is invoked in a disconnected environment.

• https://github.com/openshift/installer/pull/6978

• https://github.com/openshift/installer/pull/6919

This is a clone of issue OCPBUGS-17380. The following is the description of the original issue:
—
Description of problem:

Enable IPSec pre/post install on OVN IC cluster

$ oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"ipsecConfig":{ }}}}}'
network.operator.openshift.io/cluster patched


ovn-ipsec containers complaining:

ovs-monitor-ipsec | ERR | Failed to import certificate into NSS.
b'certutil:  unable to open "/etc/openvswitch/keys/ipsec-cacert.pem" for reading (-5950, 2).\n'



$ oc rsh ovn-ipsec-d7rx9
Defaulted container "ovn-ipsec" out of: ovn-ipsec, ovn-keys (init)
sh-5.1# certutil -L -d /var/lib/ipsec/nss Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPIovs_certkey_db961f9a-7de4-4f1d-a2fb-a8306d4079c5             u,u,u 

sh-5.1# cat /var/log/openvswitch/libreswan.log
Aug  4 15:12:46.808394: Initializing NSS using read-write database "sql:/var/lib/ipsec/nss"
Aug  4 15:12:46.837350: FIPS Mode: NO
Aug  4 15:12:46.837370: NSS crypto library initialized
Aug  4 15:12:46.837387: FIPS mode disabled for pluto daemon
Aug  4 15:12:46.837390: FIPS HMAC integrity support [disabled]
Aug  4 15:12:46.837541: libcap-ng support [enabled]
Aug  4 15:12:46.837550: Linux audit support [enabled]
Aug  4 15:12:46.837576: Linux audit activated
Aug  4 15:12:46.837580: Starting Pluto (Libreswan Version 4.9 IKEv2 IKEv1 XFRM XFRMI esp-hw-offload FORK PTHREAD_SETSCHEDPRIO GCC_EXCEPTIONS NSS (IPsec profile) (NSS-KDF) DNSSEC SYSTEMD_WATCHDOG LABELED_IPSEC (SELINUX) SECCOMP LIBCAP_NG LINUX_AUDIT AUTH_PAM NETWORKMANAGER CURL(non-NSS) LDAP(non-NSS)) pid:147
Aug  4 15:12:46.837583: core dump dir: /run/pluto
Aug  4 15:12:46.837585: secrets file: /etc/ipsec.secrets
Aug  4 15:12:46.837587: leak-detective enabled
Aug  4 15:12:46.837589: NSS crypto [enabled]
Aug  4 15:12:46.837591: XAUTH PAM support [enabled]
Aug  4 15:12:46.837604: initializing libevent in pthreads mode: headers: 2.1.12-stable (2010c00); library: 2.1.12-stable (2010c00)
Aug  4 15:12:46.837664: NAT-Traversal support  [enabled]
Aug  4 15:12:46.837803: Encryption algorithms:
Aug  4 15:12:46.837814:   AES_CCM_16         {256,192,*128} IKEv1:     ESP     IKEv2:     ESP     FIPS              aes_ccm, aes_ccm_c
Aug  4 15:12:46.837820:   AES_CCM_12         {256,192,*128} IKEv1:     ESP     IKEv2:     ESP     FIPS              aes_ccm_b
Aug  4 15:12:46.837826:   AES_CCM_8          {256,192,*128} IKEv1:     ESP     IKEv2:     ESP     FIPS              aes_ccm_a
Aug  4 15:12:46.837831:   3DES_CBC           [*192]         IKEv1: IKE ESP     IKEv2: IKE ESP     FIPS NSS(CBC)     3des
Aug  4 15:12:46.837837:   CAMELLIA_CTR       {256,192,*128} IKEv1:     ESP     IKEv2:     ESP                      
Aug  4 15:12:46.837843:   CAMELLIA_CBC       {256,192,*128} IKEv1: IKE ESP     IKEv2: IKE ESP          NSS(CBC)     camellia
Aug  4 15:12:46.837849:   AES_GCM_16         {256,192,*128} IKEv1:     ESP     IKEv2: IKE ESP     FIPS NSS(GCM)     aes_gcm, aes_gcm_c
Aug  4 15:12:46.837855:   AES_GCM_12         {256,192,*128} IKEv1:     ESP     IKEv2: IKE ESP     FIPS NSS(GCM)     aes_gcm_b
Aug  4 15:12:46.837861:   AES_GCM_8          {256,192,*128} IKEv1:     ESP     IKEv2: IKE ESP     FIPS NSS(GCM)     aes_gcm_a
Aug  4 15:12:46.837867:   AES_CTR            {256,192,*128} IKEv1: IKE ESP     IKEv2: IKE ESP     FIPS NSS(CTR)     aesctr
Aug  4 15:12:46.837872:   AES_CBC            {256,192,*128} IKEv1: IKE ESP     IKEv2: IKE ESP     FIPS NSS(CBC)     aes
Aug  4 15:12:46.837878:   NULL_AUTH_AES_GMAC {256,192,*128} IKEv1:     ESP     IKEv2:     ESP     FIPS              aes_gmac
Aug  4 15:12:46.837883:   NULL               []             IKEv1:     ESP     IKEv2:     ESP                      
Aug  4 15:12:46.837889:   CHACHA20_POLY1305  [*256]         IKEv1:             IKEv2: IKE ESP          NSS(AEAD)    chacha20poly1305
Aug  4 15:12:46.837892: Hash algorithms:
Aug  4 15:12:46.837896:   MD5                               IKEv1: IKE         IKEv2:                  NSS         
Aug  4 15:12:46.837901:   SHA1                              IKEv1: IKE         IKEv2: IKE         FIPS NSS          sha
Aug  4 15:12:46.837906:   SHA2_256                          IKEv1: IKE         IKEv2: IKE         FIPS NSS          sha2, sha256
Aug  4 15:12:46.837910:   SHA2_384                          IKEv1: IKE         IKEv2: IKE         FIPS NSS          sha384
Aug  4 15:12:46.837915:   SHA2_512                          IKEv1: IKE         IKEv2: IKE         FIPS NSS          sha512
Aug  4 15:12:46.837919:   IDENTITY                          IKEv1:             IKEv2:             FIPS             
Aug  4 15:12:46.837922: PRF algorithms:
Aug  4 15:12:46.837927:   HMAC_MD5                          IKEv1: IKE         IKEv2: IKE              native(HMAC) md5
Aug  4 15:12:46.837931:   HMAC_SHA1                         IKEv1: IKE         IKEv2: IKE         FIPS NSS          sha, sha1
Aug  4 15:12:46.837936:   HMAC_SHA2_256                     IKEv1: IKE         IKEv2: IKE         FIPS NSS          sha2, sha256, sha2_256
Aug  4 15:12:46.837950:   HMAC_SHA2_384                     IKEv1: IKE         IKEv2: IKE         FIPS NSS          sha384, sha2_384
Aug  4 15:12:46.837955:   HMAC_SHA2_512                     IKEv1: IKE         IKEv2: IKE         FIPS NSS          sha512, sha2_512
Aug  4 15:12:46.837959:   AES_XCBC                          IKEv1:             IKEv2: IKE              native(XCBC) aes128_xcbc
Aug  4 15:12:46.837962: Integrity algorithms:
Aug  4 15:12:46.837966:   HMAC_MD5_96                       IKEv1: IKE ESP AH  IKEv2: IKE ESP AH       native(HMAC) md5, hmac_md5
Aug  4 15:12:46.837984:   HMAC_SHA1_96                      IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS NSS          sha, sha1, sha1_96, hmac_sha1
Aug  4 15:12:46.837995:   HMAC_SHA2_512_256                 IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS NSS          sha512, sha2_512, sha2_512_256, hmac_sha2_512
Aug  4 15:12:46.837999:   HMAC_SHA2_384_192                 IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS NSS          sha384, sha2_384, sha2_384_192, hmac_sha2_384
Aug  4 15:12:46.838005:   HMAC_SHA2_256_128                 IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS NSS          sha2, sha256, sha2_256, sha2_256_128, hmac_sha2_256
Aug  4 15:12:46.838008:   HMAC_SHA2_256_TRUNCBUG            IKEv1:     ESP AH  IKEv2:         AH                   
Aug  4 15:12:46.838014:   AES_XCBC_96                       IKEv1:     ESP AH  IKEv2: IKE ESP AH       native(XCBC) aes_xcbc, aes128_xcbc, aes128_xcbc_96
Aug  4 15:12:46.838018:   AES_CMAC_96                       IKEv1:     ESP AH  IKEv2:     ESP AH  FIPS              aes_cmac
Aug  4 15:12:46.838023:   NONE                              IKEv1:     ESP     IKEv2: IKE ESP     FIPS              null
Aug  4 15:12:46.838026: DH algorithms:
Aug  4 15:12:46.838031:   NONE                              IKEv1:             IKEv2: IKE ESP AH  FIPS NSS(MODP)    null, dh0
Aug  4 15:12:46.838035:   MODP1536                          IKEv1: IKE ESP AH  IKEv2: IKE ESP AH       NSS(MODP)    dh5
Aug  4 15:12:46.838039:   MODP2048                          IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS NSS(MODP)    dh14
Aug  4 15:12:46.838044:   MODP3072                          IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS NSS(MODP)    dh15
Aug  4 15:12:46.838048:   MODP4096                          IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS NSS(MODP)    dh16
Aug  4 15:12:46.838053:   MODP6144                          IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS NSS(MODP)    dh17
Aug  4 15:12:46.838057:   MODP8192                          IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS NSS(MODP)    dh18
Aug  4 15:12:46.838061:   DH19                              IKEv1: IKE         IKEv2: IKE ESP AH  FIPS NSS(ECP)     ecp_256, ecp256
Aug  4 15:12:46.838066:   DH20                              IKEv1: IKE         IKEv2: IKE ESP AH  FIPS NSS(ECP)     ecp_384, ecp384
Aug  4 15:12:46.838070:   DH21                              IKEv1: IKE         IKEv2: IKE ESP AH  FIPS NSS(ECP)     ecp_521, ecp521
Aug  4 15:12:46.838074:   DH31                              IKEv1: IKE         IKEv2: IKE ESP AH       NSS(ECP)     curve25519
Aug  4 15:12:46.838077: IPCOMP algorithms:
Aug  4 15:12:46.838081:   DEFLATE                           IKEv1:     ESP AH  IKEv2:     ESP AH  FIPS             
Aug  4 15:12:46.838085:   LZS                               IKEv1:             IKEv2:     ESP AH  FIPS             
Aug  4 15:12:46.838089:   LZJH                              IKEv1:             IKEv2:     ESP AH  FIPS             
Aug  4 15:12:46.838093: testing CAMELLIA_CBC:
Aug  4 15:12:46.838096:   Camellia: 16 bytes with 128-bit key
Aug  4 15:12:46.838162:   Camellia: 16 bytes with 128-bit key
Aug  4 15:12:46.838201:   Camellia: 16 bytes with 256-bit key
Aug  4 15:12:46.838243:   Camellia: 16 bytes with 256-bit key
Aug  4 15:12:46.838280: testing AES_GCM_16:
Aug  4 15:12:46.838284:   empty string
Aug  4 15:12:46.838319:   one block
Aug  4 15:12:46.838352:   two blocks
Aug  4 15:12:46.838385:   two blocks with associated data
Aug  4 15:12:46.838424: testing AES_CTR:
Aug  4 15:12:46.838428:   Encrypting 16 octets using AES-CTR with 128-bit key
Aug  4 15:12:46.838464:   Encrypting 32 octets using AES-CTR with 128-bit key
Aug  4 15:12:46.838502:   Encrypting 36 octets using AES-CTR with 128-bit key
Aug  4 15:12:46.838541:   Encrypting 16 octets using AES-CTR with 192-bit key
Aug  4 15:12:46.838576:   Encrypting 32 octets using AES-CTR with 192-bit key
Aug  4 15:12:46.838613:   Encrypting 36 octets using AES-CTR with 192-bit key
Aug  4 15:12:46.838651:   Encrypting 16 octets using AES-CTR with 256-bit key
Aug  4 15:12:46.838687:   Encrypting 32 octets using AES-CTR with 256-bit key
Aug  4 15:12:46.838724:   Encrypting 36 octets using AES-CTR with 256-bit key
Aug  4 15:12:46.838763: testing AES_CBC:
Aug  4 15:12:46.838766:   Encrypting 16 bytes (1 block) using AES-CBC with 128-bit key
Aug  4 15:12:46.838801:   Encrypting 32 bytes (2 blocks) using AES-CBC with 128-bit key
Aug  4 15:12:46.838841:   Encrypting 48 bytes (3 blocks) using AES-CBC with 128-bit key
Aug  4 15:12:46.838881:   Encrypting 64 bytes (4 blocks) using AES-CBC with 128-bit key
Aug  4 15:12:46.838928: testing AES_XCBC:
Aug  4 15:12:46.838932:   RFC 3566 Test Case 1: AES-XCBC-MAC-96 with 0-byte input
Aug  4 15:12:46.839126:   RFC 3566 Test Case 2: AES-XCBC-MAC-96 with 3-byte input
Aug  4 15:12:46.839291:   RFC 3566 Test Case 3: AES-XCBC-MAC-96 with 16-byte input
Aug  4 15:12:46.839444:   RFC 3566 Test Case 4: AES-XCBC-MAC-96 with 20-byte input
Aug  4 15:12:46.839600:   RFC 3566 Test Case 5: AES-XCBC-MAC-96 with 32-byte input
Aug  4 15:12:46.839756:   RFC 3566 Test Case 6: AES-XCBC-MAC-96 with 34-byte input
Aug  4 15:12:46.839937:   RFC 3566 Test Case 7: AES-XCBC-MAC-96 with 1000-byte input
Aug  4 15:12:46.840373:   RFC 4434 Test Case AES-XCBC-PRF-128 with 20-byte input (key length 16)
Aug  4 15:12:46.840529:   RFC 4434 Test Case AES-XCBC-PRF-128 with 20-byte input (key length 10)
Aug  4 15:12:46.840698:   RFC 4434 Test Case AES-XCBC-PRF-128 with 20-byte input (key length 18)
Aug  4 15:12:46.840990: testing HMAC_MD5:
Aug  4 15:12:46.840997:   RFC 2104: MD5_HMAC test 1
Aug  4 15:12:46.841200:   RFC 2104: MD5_HMAC test 2
Aug  4 15:12:46.841390:   RFC 2104: MD5_HMAC test 3
Aug  4 15:12:46.841582: testing HMAC_SHA1:
Aug  4 15:12:46.841585:   CAVP: IKEv2 key derivation with HMAC-SHA1
Aug  4 15:12:46.842055: 8 CPU cores online
Aug  4 15:12:46.842062: starting up 7 helper threads
Aug  4 15:12:46.842128: started thread for helper 0
Aug  4 15:12:46.842174: helper(1) seccomp security disabled for crypto helper 1
Aug  4 15:12:46.842188: started thread for helper 1
Aug  4 15:12:46.842219: helper(2) seccomp security disabled for crypto helper 2
Aug  4 15:12:46.842236: started thread for helper 2
Aug  4 15:12:46.842258: helper(3) seccomp security disabled for crypto helper 3
Aug  4 15:12:46.842269: started thread for helper 3
Aug  4 15:12:46.842296: helper(4) seccomp security disabled for crypto helper 4
Aug  4 15:12:46.842311: started thread for helper 4
Aug  4 15:12:46.842323: helper(5) seccomp security disabled for crypto helper 5
Aug  4 15:12:46.842346: started thread for helper 5
Aug  4 15:12:46.842369: helper(6) seccomp security disabled for crypto helper 6
Aug  4 15:12:46.842376: started thread for helper 6
Aug  4 15:12:46.842390: using Linux xfrm kernel support code on #1 SMP PREEMPT_DYNAMIC Thu Jul 20 09:11:28 EDT 2023
Aug  4 15:12:46.842393: helper(7) seccomp security disabled for crypto helper 7
Aug  4 15:12:46.842707: selinux support is NOT enabled.
Aug  4 15:12:46.842728: systemd watchdog not enabled - not sending watchdog keepalives
Aug  4 15:12:46.843813: seccomp security disabled
Aug  4 15:12:46.848083: listening for IKE messages
Aug  4 15:12:46.848252: Kernel supports NIC esp-hw-offload
Aug  4 15:12:46.848534: adding UDP interface ovn-k8s-mp0 10.129.0.2:500
Aug  4 15:12:46.848624: adding UDP interface ovn-k8s-mp0 10.129.0.2:4500
Aug  4 15:12:46.848654: adding UDP interface br-ex 169.254.169.2:500
Aug  4 15:12:46.848681: adding UDP interface br-ex 169.254.169.2:4500
Aug  4 15:12:46.848713: adding UDP interface br-ex 10.0.0.8:500
Aug  4 15:12:46.848740: adding UDP interface br-ex 10.0.0.8:4500
Aug  4 15:12:46.848767: adding UDP interface lo 127.0.0.1:500
Aug  4 15:12:46.848793: adding UDP interface lo 127.0.0.1:4500
Aug  4 15:12:46.848824: adding UDP interface lo [::1]:500
Aug  4 15:12:46.848853: adding UDP interface lo [::1]:4500
Aug  4 15:12:46.851160: loading secrets from "/etc/ipsec.secrets"
Aug  4 15:12:46.851214: no secrets filename matched "/etc/ipsec.d/*.secrets"
Aug  4 15:12:47.053369: loading secrets from "/etc/ipsec.secrets"

sh-4.4# tcpdump -i any esp
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes^C
0 packets capturedsh-5.1# ovn-nbctl --no-leader-only get nb_global . ipsec
false
 

Version-Release number of selected component (if applicable):

openshift/cluster-network-operator#1874 

How reproducible:

Always

Steps to Reproduce:

1.Install OVN cluster and enable IPSec in runtime
2.
3.

Actual results:

no esp packets seen across the nodes

Expected results:

esp traffic should be seen across the nodes

Additional info:

• https://github.com/openshift/cluster-network-operator/pull/1997

As a oc-mirror user, I would like mirrored operator catalogs to have valid caches that reflect the contents of the catalog (configs folder) based on the filtering done in the ImageSetConfig for that catalog

so that the catalog image starts efficiently in a cluster.

Tasks:

• white-out /tmp on all manifests (per platform)
• Recreate the cache under /tmp/cache using
  • extract the whole catalog
  • use the opm binary included in the extracted catalog to call (command line)

opm serve /configs –-cache-dir /tmp/cache –-cache-only 

• Create a new layer from /configs and /tmp/cache
  • the /tmp is compatible with all platforms
• oc-mirror should not change the CMD nor ENTRYPOINT of the image
• Rebuild catalog image up to the index (manifest list)

Acceptance criteria:

• Run the catalog container with command opm serve <configDir> --cache-dir=<cacheDir> --cache-only --cache-enforce-integrity to verify the integrity of the cache
• 4.14 catalogs mirrored with oc-mirror v4.14 run correctly in a cluster
  • when mirrored with mirrorToMirror workflow
  • when mirrored with mirrorToMirror workflow with --include-oci-local-catalogs
  • when mirrored with mirrorToDisk + diskToMirror workflow
• 4.14 catalogs mirrored with oc-mirror v4.14 use the pre-computed cache (not sure how to test this)
• catalogs<= 4.13 mirrored with oc-mirror v4.14 run correctly in a cluster (this is not something we publish as supported)

• https://github.com/openshift/oc-mirror/pull/651

Description of problem:

Customer was able to limit the nested repository path with "oc adm catalog mirror" by using the argument "--max-components" but there is no alternate solution along with "oc-mirror" binary while we are suggesting to use "oc-mirror" binary for mirroring.for example:
Mirroring will work if we mirror like below
oc mirror --config=./imageset-config.yaml docker://registry.gitlab.com/xxx/yyy
Mirroring will fail with 401 unauthorized if we add one more nested path like below
oc mirror --config=./imageset-config.yaml docker://registry.gitlab.com/xxx/yyy/zzz

Version-Release number of selected component (if applicable):

How reproducible:

We can reproduce the issue by using a repository which is not supported deep nested paths

Steps to Reproduce:

1. Create a imageset to mirror any operator

kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
  local:
    path: ./oc-mirror-metadata
mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.12
    packages:
    - name: local-storage-operator
      channels:
      - name: stable

2. Do the mirroring to a registry where its not supported deep nested repository path, Here its gitlab and its doesnt not support netsting beyond 3 levels deep.

oc mirror --config=./imageset-config.yaml docker://registry.gitlab.com/xxx/yyy/zzz

this mirroring will fail with 401 unauthorized error
 
3. if  try to mirror the same imageset by removing one path it will work without any issues, like below

oc mirror --config=./imageset-config.yaml docker://registry.gitlab.com/xxx/yyy 

Actual results:

Expected results:

Need a alternative option of "--max-components" to limit the nested path in "oc-mirror"

Additional info:

• https://github.com/openshift/oc-mirror/pull/634
• https://github.com/openshift/oc-mirror/pull/623

Proposed title of this feature request

Achieve feature parity for recently introduced functionality for all modes of operation

Nature and description of the request

Currently there are gaps in functionality within oc mirror that we would like addressed.

1. Support oci: references within mirror.operators[].catalog in an ImageSetConfiguration when running in all modes of operation with the full functionality provided by oc mirror.

Currently oci: references such as the following are allowed only in limited circumstances:

mirror:
   operators:
   - catalog: oci:///tmp/oci/ocp11840
   - catalog: icr.io/cpopen/ibm-operator-catalog
 

Currently supported scenarios

• Mirror to Mirror

In this mode of operation the images are fetched from the oci: reference rather than being pulled from a source docker image repository. These catalogs are processed through similar (yet different) mechanisms compared to docker image references. The end result in this scenario is that the catalog is potentially modified and images (i.e. catalog, bundle, related images, etc.) are pushed to their final docker image repository. This provides the full capabilities offered by oc mirror (e.g. catalog "filtering", image pruning, metadata manipulation to keep track of what has been mirrored, etc.)

Desired scenarios
In the following scenarios we would like oci: references to be processed in a similar way to how docker references are handled (as close as possible anyway given the different APIs involved). Ultimately we want oci: catalog references to provide the full set of functionality currently available for catalogs provided as a docker image reference. In other words we want full feature parity (e.g. catalog "filtering", image pruning, metadata manipulation to keep track of what has been mirrored, etc.)

• Mirror to Disk

In this mode of operation the images are fetched from the oci: reference rather than being pulled from a docker image repository. These catalogs are processed through similar yet different mechanisms compared to docker image references. The end result of this scenario is that all mappings and catalogs are packaged into tar archives (i.e. the "imageset").

• Disk to Mirror

In this mode of operation the tar archives (i.e. the "imageset") are processed via the "publish mechanism" which means unpacking the tar archives, processing the metadata, pruning images, rebuilding catalogs, and pushing images to their destination. In theory if the mirror-to-disk scenario is handled properly, then this mode should "just work".

Below the line was the original RFE for requesting the OCI feature and is only provided for reference.

... so that I can use that along with the OCI FBC feature

• https://github.com/openshift/oc-mirror/pull/611

• https://github.com/openshift/cluster-ingress-operator/pull/872

• https://github.com/openshift/cluster-ingress-operator/pull/872

• https://github.com/openshift/router/pull/438

Bump the HAProxy version in dist-git so that OCP 4.13 ships HAProxy 2.6.13, with this patch added on top: https://git.haproxy.org/?p=haproxy-2.6.git;a=commit;h=2b0aafdc92f691bc4b987300c9001a7cc3fb8d08. The patch fixes the segfault that was being tracked as OCPBUGS-13232.

This patch is in HAProxy 2.6.14, so we can stop carrying the patch once we bump to HAProxy 2.6.14 or newer in a subsequent OCP release.

• https://github.com/openshift/router/pull/487
• https://github.com/openshift/images/pull/141

This requires messy/complex work of grepping through for prior references to ignition and updating golang types that reference other versions.

Assumption that existing tests are sufficient to catch discrepancies. 

• https://github.com/openshift/machine-config-operator/pull/3814

User Story

As a Red Hat Partner installing OpenShift using the External platform type, I would like to install my own Cloud Controller Manager(CCM). Having a field in the Infrastructure configuration object to signal that I will install my own CCM and that Kubernetes should be configured to expect an external CCM will allow me to run my own CCM on new OpenShift deployments.

Background

This work has been defined in the External platform enhancement , and had previously been part of openshift/api . The CCM API pieces were removed for the 4.13 release of OpenShift to ensure that we did not ship unused portions of the API.

In addition to the API changes, library-go will need to have an update to the  IsCloudProviderExternal function to detect the if the External platform is selected and if the CCM should be enabled for external mode.

We will also need to check the ObserveCloudVolumePlugin function to ensure that it is not affected by the external changes and that it continues to use the external volume plugin.

After updating openshift/library-go, it will need to be re-vendored into the MCO  , KCMO , and CCCMO  (although this is not as critical as the other 2).

Steps

• update openshift/api with new CCM fields (re-revert #1409)
• revendor api to library-go
• update IsCloudProviderExternal in library-go to observe the new API fields
• investigate ObserveCloudVolumePlugin to see if it requires changes
• revendor library-go to MCO, KCMO, and CCCMO
• update enhancement doc to reflect state

Stakeholders

• openshift eng
• oracle cloud install effort

Definition of Done

• openshift can be installed with External platform type with kubelet, and related components, using the external cloud provider flags.

• Docs

• this will need to be documented in the API and as part of OCPCLOUD-1581

• Testing

• this will need validation through unit test, integration testing may be difficult as we will need a new e2e built off the external platform with a ccm

• https://github.com/openshift/cluster-cloud-controller-manager-operator/pull/253
• https://github.com/openshift/cluster-config-operator/pull/331
• https://github.com/openshift/cluster-config-operator/pull/306
• https://github.com/openshift/cluster-kube-controller-manager-operator/pull/736
• https://github.com/openshift/machine-config-operator/pull/3745

User Story

As a user I want to use the openshift installer to create clusters of platform type External so that I can use openshift more effectively on a partner provider platform.

Background

To fully support the External platform type for partners and users, it will be useful to be able to have the installer understand when it sees the external platform type in the install-config.yaml, and then to properly populate the resulting infrastructure config object with the external platform type and platform name.

As defined in https://github.com/openshift/api/blob/master/config/v1/types_infrastructure.go#L241 , the external platform type allows the user to specify a name for the platform. This card is about updating the installer so that a user can provide both the external type and a platform name that will be expressed in the infrastructure manifest.

Aside from this information, the installer should continue with a normal platform "None" installation.

Steps

• update installer to allow platform "External" specified in the install-config.yaml
• update installer to allow platform name to specified as part of the External platform configuration

Stakeholders

• openshift cloud infra team
• openshift installer team
• openshift assisted installer team

Definition of Done

• user can specify external platform in the install-config.yaml and have a cluster with External platform type and a name for the platform.
• cluster installs as expected for platform external (similar to none)

• Docs

• the initial documentation for this will be contained in the developer generated docs defined by https://issues.redhat.com/browse/OCPCLOUD-1581

• Testing

• this feature should allow us to update our external platform tests to make the installation easier, tests should be updated to include this methodology

• https://github.com/openshift/installer/pull/7217

This is the "consumption" side of the security – rpm-ostree needs to be able to retrieve images from the internal registry seamlessly.

This will involve setting up (or using some existing) pull secrets, and then getting them to the proper location on disk so that rpm-ostree can use them to pull images.

• https://github.com/openshift/machine-config-operator/pull/3806

At the layering sync meeting on Thursday, August 10th, it was decided that for this to be considered ready for Dev / Tech Preview, cluster admins need a way to inject custom Dockerfiles into their on-cluster builds.

(Commentary: It was also decided 4 months ago that this was not an MVP requirement in https://docs.google.com/document/d/1QSsq0mCgOSUoKZ2TpCWjzrQpKfMUL9thUFBMaPxYSLY/edit#heading=h.jqagm7kwv0lg. And quite frankly, this requirement should have been known at that point in time as opposed to the week before tech preview.)

• https://github.com/openshift/machine-config-operator/pull/3847

The first phase of the layering effort involved creating a BuildController, whose job is to start and manage builds using the OpenShift Build API. We can use the work done to create the BuildController as the basis for our MVP. However, what we need from BuildController right now is less than BuildController currently provides. With that in mind, we need to remove certain parts of BuildController to create a more streamlined and simpler implementation ideal for an MVP.

Done when a version of BuildController is landed which does the following things:

• Listens for all MachineConfigPool events. If a MachineConfigPool with a specific label or annotation (e.g., machineconfiguration.openshift.io/layering-enabled), the BuildController should retrieve the latest rendered MachineConfig associated with the MachineConfigPool, generate a series of inputs to a builder backend (for now, the OpenShift Build API can be the first backend), then update the MachineConfigPool with the outcome of that action. In the case of a successful build, the MachineConfigPool should be updated with the image pullspec for the newly-built image. For now, this can come in the form of an annotation or a label (e.g., machineconfiguration.openshift.io/desired-os-image = "image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/coreos@sha256:abcdef1234567890...). But eventually, it should be a Status field on the MachineConfigPool object.
• Reads from a ConfigMap which contains the following items (let's call it machine-os-builder-config for now):
  • Name of the base OS image pull secret.
  • Name of the final OS image push secret.
  • Target container registry and org / repo information for where to push the final OS image (e.g., image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/coreos).

• All functionality around managing ImageStreams and OpenShift Builds is removed or decoupled. In the case of the OpenShift Build functionality, it will be decoupled instead of completely removed. Additionally, it should not use BuildConfigs. It should instead create and manage image Build objects directly.
• Use contexts for handling shutdowns and timeouts.
• Unit tests are written for the major BuildController functionalities using either FakeClient or EnvTest.
• The modified BuildController and its tests are merged into the master branch of the MCO. Note: This does not mean that it will be immediately active in the MCO's execution path. However, tests will be executed in CI.

• https://github.com/openshift/machine-config-operator/pull/3731

The second phase of the layering effort involved creating a BuildController, whose job is to start and manage builds of OS images. While it should be able to perform those functions on its own, getting the built OS image onto each of the cluster nodes involves modifying other parts of the MCO to be layering-aware. To that end, there are three pieces involve, some of which will require modification:

Render Controller

Right now, the render controller listens for incoming MachineConfig changes. It generates the rendered config which is comprised of all of the MachineConfigs for a given MachineConfigPool. Once rendered, the Render Controller updates the MachineConfigPool to point to the new config. This portion of the MCO will not likely need any modification that I'm aware of at the moment.

Node Controller

The Node Controller listens for MachineConfigPool config changes. Whenever it identifies that a change has occurred, it applies the machineconfiguration.openshift.io/desiredConfig annotation to all the nodes in the targeted MachineConfigPool which causes the Machine Config Daemon (MCD) to apply the new configs. With this new layering mechanism, we'll need to add the additional annotation of machineconfiguration.openshift.io/desiredOSimage which will contain the fully-qualified pullspec for the new OS image (referenced by the image SHA256 sum). To be clear, we will not be replacing the desiredConfig annotation with the desiredOSimage annotation; both will still be used. This will allow Config Drift Monitor to continue to function the way it does with no modification required.

Machine Config Daemon

Right now, the MCD listens to Node objects for changes to the machineconfiguration.openshift.io/desiredConfig annotation. With the new desiredOSimage annotation being present, the MCD will need to skip the parts of the update loop which write files and systemd units to disk. Instead, it will skip directly to the rpm-ostree application phase (after making sure the correct pull secrets are in place, etc.).

Done When:

• The above modifications are made.
• Each modification has been done with appropriate unit tests where feasible.

• https://github.com/openshift/machine-config-operator/pull/3848
• https://github.com/openshift/machine-config-operator/pull/3817

To speed development for on-cluster builds and avoid a lot of complex code paths, the decision was made to put all functionality related to building OS images and managing internal registries into a separate binary within the MCO.

Eventually, this binary will be responsible for running the productionized BuildController and know how to respond to Machine OS Builder API objects. However, until the productionized BuildController and opt-in portions are ready, the first pass of this binary will be much simpler: For now, it can connect to the API server and print a "Hello World".

Done When:

• We have a new binary under cmd/machine-os-builder. This binary will be built alongside the current MCO components and will be baked into the MCO image.
• The Dockerfile, Makefile, and build scripts will need some modification so that they how to build cmd/machine-os-builder.
• A Deployment manifest is created under manifests/ which is set up to start up a single instance of the new binary though we don't want it to start up by default right now since it won't do anything useful.

• https://github.com/openshift/machine-config-operator/pull/3834
• https://github.com/openshift/machine-config-operator/pull/3763

oc adm release extract --included ... or some such, that only works when no release pullspec is given, where oc connects to the cluster to ask after the current release image (as it does today when you leave off a pullspec) but also collects FeatureGates and cluster profile and all that sort of stuff so it can write only the manifests it expects the CVO to be attempting to reconcile.

This would be narrowly useful for ccoctl (see CCO-178 and CCO-186), because with this extract option, ccoctl wouldn't need to try to reproduce "which of these CredentialsRequests manifests does the cluster actually want filled?" locally.

It also seems like it would be useful for anyone trying to get a better feel for what the CVO is up to in their cluster, for the same reason that it reduces distracting manifests that don't apply.

The downside is that if we screw up the inclusion logic, we could have oc diverging from the CVO, and end up increasing confusion instead of decreasing confusion. If we move the inclusion logic to library-go, that reduces the risk a bit, but there's always the possibility that users are using an oc that is older or newer than the cluster's CVO. Some way to have oc warn when the option is used but the version differs from the current CVO version would be useful, but possibly complicated to implement, unless we take shortcuts like assuming that the currently running CVO has a version matched to the ClusterVersion's status.desired target.

Definition of done (more details in the OTA-692 spike comment):

• Add a new --included flag to $ oc adm release extract --to <dir path> <pull-spec or version-number>. The --included flag filters extracted manifests to those that are expected to be included with the cluster. 
  • Move overrides handling here and here into library-go.

 here is a sketch of code which W. Trevor King suggested

• https://github.com/openshift/oc/pull/1528
• https://github.com/openshift/oc/pull/1521
• https://github.com/openshift/cluster-version-operator/pull/934

While working on OTA-559, my oc#1237 broke JSON output, and needed a follow-up fix. To avoid destabilizing folks who consume the dev-tip oc, we should grow CI presubmits to exercise critical oc adm release ... pathways, to avoid that kind of accidental breakage.

• https://github.com/openshift/origin/pull/27822

So it's easier to make adjustments without having to copy/paste code between branches.

• https://github.com/openshift/oc/pull/1404

To enable the MCO to replace the node-ca, the registry operator needs to provide its own CAs in isolation.

Currently, the registry provides its own CAs via the "image-registry-certificates" configmap. This configmap is a merge of the service ca, storage ca, and additionalTrustedCA (from images.config.openshift.io/cluster).

Because the MCO already has access to additionalTrustedCA, the new secret does not need to contain it.

ACCEPTANCE CRITERIA

TBD

• https://github.com/openshift/cluster-image-registry-operator/pull/880

The new aesgcm encryption provider was added in 4.13 as techpreview, but as part of https://issues.redhat.com/browse/API-1509, the feature needs to be GA in OCP 4.13.

• https://github.com/openshift/cluster-authentication-operator/pull/601

AES-GCM encryption was enabled in cluster-openshift-apiserver-operator and cluster-openshift-autenthication-operator, but not in the cluster-kube-apiserver-operator. When trying to enable aesgcm encryption in the apiserver config, the kas-operator will produce an error saying that the aesgcm provider is not supported.

• https://github.com/openshift/cluster-kube-apiserver-operator/pull/1449

The new aesgcm encryption provider was added in 4.13 as techpreview, but as part of https://issues.redhat.com/browse/API-1509, the feature needs to be GA in OCP 4.13.

• https://github.com/openshift/cluster-openshift-apiserver-operator/pull/526

The new aesgcm encryption provider was added in 4.13 as techpreview, but as part of https://issues.redhat.com/browse/API-1509, the feature needs to be GA in OCP 4.13.

• https://github.com/openshift/cluster-config-operator/pull/289

The new aesgcm encryption provider was added in 4.13 as techpreview, but as part of https://issues.redhat.com/browse/API-1509, the feature needs to be GA in OCP 4.13.

• https://github.com/openshift/cluster-kube-apiserver-operator/pull/1462

User Story:

As a user, I want to be able to:

• generate the minimal ISO in the installer when the platform type is set to external/oci

so that I can achieve

• successful cluster installation
• any custom agent features such as network tui should be available when booting from minimal ISO

Acceptance Criteria:

Description of criteria:

• Upstream documentation
• Point 1
• Point 2
• Point 3

(optional) Out of Scope:

Detail about what is specifically not being delivered in the story

Engineering Details:

• (optional) https://github/com/link.to.enhancement/
• (optional) https://issues.redhat.com/link.to.spike
• Engineering detail 1
• Engineering detail 2

This requires/does not require a design proposal.
This requires/does not require a feature gate.

• https://github.com/openshift/installer/pull/7478

User Story:

As a user of the agent-based installer, I want to be able to:

• validate the external platform type in the agent cluster install by providing the external platform type in the install-config.yaml

so that I can achieve

• create agent artifacts ( ISO, PXE files)

Acceptance Criteria:

Description of criteria:

• install-config.yaml accepts the new platform type "external"
• agent-based installer validates the supported platforms
• agent ISO and PXE assets should be created successfully
• Required k8s API support is added

(optional) Out of Scope:

Detail about what is specifically not being delivered in the story

Engineering Details:

• (optional) https://github/com/link.to.enhancement/
• (optional) https://issues.redhat.com/link.to.spike
• Engineering detail 1
• Engineering detail 2

This requires/does not require a design proposal.
This requires/does not require a feature gate.

• https://github.com/openshift/assisted-service/pull/5438

User Story:

As a user of the agent-based installer, I want to be able to:

• create agent ISO as well as PXE assets by providing the install-config.yaml

so that I can achieve

• create a cluster for external cloud provider platform type (OCI)

Acceptance Criteria:

Description of criteria:

• install-config.yaml accepts the new platform type "external"
• validate install-config so that platformName can only be set to `oci` when platform is external 
• agent-based installer validates the supported platforms
• agent ISO and PXE assets should be created successfully
• necessary unit tests and integration tests are added

(optional) Out of Scope:

Detail about what is specifically not being delivered in the story

Engineering Details:

• (optional) https://github/com/link.to.enhancement/
• (optional) https://issues.redhat.com/link.to.spike
• Engineering detail 1
• Engineering detail 2

This requires/does not require a design proposal.
This requires/does not require a feature gate.

• https://github.com/openshift/installer/pull/7442

User Story:

I want

• the installer to check for appropriate permissions based on whether the installation is using an existing hosted zone and whether that hosted zone is in another account

so that I can

• be sure that my credentials have sufficient and minimal permissions before beginning install

Acceptance Criteria:

Description of criteria:

• When specifying platform.aws.hostedZoneRole. Route53:CreateHostedZone and Route53:DeleteHostedZone are not required

(optional) Out of Scope:

Detail about what is specifically not being delivered in the story

Engineering Details:

• https://github.com/openshift/installer/blob/master/pkg/asset/installconfig/aws/permissions.go
•  

This requires/does not require a design proposal.
This requires/does not require a feature gate.

• https://github.com/openshift/installer/pull/7253

Develop the implementation for supporting AWS Shared VPC pre-existing Route53 as it is described in the enhancement: https://github.com/openshift/enhancements/pull/1397 

• https://github.com/openshift/cluster-ingress-operator/pull/928

In order to secure token usage during oc login, we need to add the capability to oc to login using the OAuth2 Authorization Code Grant Flow through a browser. This will be possible by providing a command line option to oc:

oc login --web

• https://github.com/openshift/oc/pull/1402

Add e2e tests in the OSIN library for redirect URI validation without ports on non-loopback links.

• https://github.com/openshift/origin/pull/27922

In order for the OAuth2 Authorization Code Grant Flow to work in oc browser login, we need a new OAuthClient that can obtain tokens through [PKCE|https://datatracker.ietf.org/doc/html/rfc7636,] as the existing clients do not have this capability. The new client will be called openshift-cli-client and will have the loopback addresses as valid Redirect URIs.

• https://github.com/openshift/cluster-authentication-operator/pull/606

In order for the OAuth2 Authorization Code Grant Flow to work in oc browser login, the OSIN server must ignore any port used in the Redirect URIs of the flow when the URIs are the loopback addresses. This has already been added to OSIN; we need to update the oauth-server to use the latest version of OSIN in order to make use of this capability.

• https://github.com/openshift/oauth-server/pull/121

For interconnect upgrades - i.e when moving from OCP 4.13 to OCP 4.14 where IC is enabled, we do a 2 phase rollout of ovnkube-master and ovnkube-node pods in the openshift-ovn-kubernetes namespace. This is to ensure we have minimum disruption since major architectural components are being brought from control-plane down to the data-plane.

Since its a two phase roll out with each phase taking taking approximately 10mins, we effectively double the time it takes for OVNK component to upgrade thereby increasing the timeout thresholds on AWS.

See https://redhat-internal.slack.com/archives/C050MC61LVA/p1689768779938889 for some more details.

See sample runs:

https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/release-openshift-origin-installer-launch-aws-modern/1679589472833900544

https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/release-openshift-origin-installer-launch-aws-modern/1679589451010936832

https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/release-openshift-origin-installer-launch-aws-modern/1678480739743567872

I have noticed this happening once on GCP:

https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/release-openshift-origin-installer-launch-gcp-modern/1680563737225859072

This has not happened on Azure which has 95mins allowance. So this card tracks the work to increase the timers on AWS/GCP. This was brought up in the TRT team sync that happened yesterday (July 19th 2023) and Scott Dodson has agreed to approve this under the condition that we bring it down back to the current values in release 4.15.

SDN team is confident the time will drop back to normal for future upgrades going from 4.14 -> 4.15 and so on. This will be tracked via https://issues.redhat.com/browse/OTA-999 

• https://github.com/openshift/hypershift/pull/2881
• https://github.com/openshift/origin/pull/28074

Work with https://issues.redhat.com/browse/SDN-3654 card to get data from scale team as needed and continue to improvise the numbers.

• https://github.com/openshift/cluster-network-operator/pull/1971

• https://github.com/openshift/cluster-network-operator/pull/2008

In the non-IC world, we have centralised DB, running a trace is easy, in IC world, we'd need all the local DBs from each node to even run a pod2pod trace fully else we can only run half traces with one side DB.

Goal of this card:

• Open a PR against `oc` repo to get all dbs (minimum requirement)

• https://github.com/openshift/must-gather/pull/370

Background

In CAPI, the AWS provider supports the user supplying the name of a pre-existing placement group. Which will then be used to create the instances.

https://github.com/kubernetes-sigs/cluster-api-provider-aws/pull/4273

We need to add the same field to our API and then pass the information through in the same way, to allow users to leverage placement groups.

Steps

• Review the upstream code linked above
• Backport the feature
• Drop old code for placement group controller that is currently disabled

Stakeholders

• Cluster Infra

Definition of Done

• Users may provide a pre-existing placement group name and have their instances created within that placement group

• Docs

• <Add docs requirements for this card>

• Testing

• <Explain testing that will be added>

• https://github.com/openshift/machine-api-provider-aws/pull/77

Console operator should be building up a set of cluster nodes OS types, which he should supply to console, so it renders only operators that could be installed on the cluster.

This will be needed when we will support different OS types on the cluster.

We need to scan through the compute nodes and build a set of supported OS from those. Each node on the cluster has a label for its operating system: e.g. kubernetes.io/os=linux,

AC:

1. Implement logic in the console repo
   1. Add additional flag
   2. populate the supported OS types into SERVER_FLAGS
   3. update the filtering logic in the operator hub

• https://github.com/openshift/console/pull/12707

1. Proposed title of this feature request

    Add a scroll bar for the resource list in the Uninstall Operator pops-up window
2. What is the nature and description of the request?

   To make user easy to check the list of all resources
3. Why does the customer need this? (List the business requirements here)

   For customers, one operator may have multiple resources, it would be easy for them to check them all in Uninstall Operator pops-up window with the scroll bar
4. List any affected packages or components.

How reproducible:

Steps to Reproduce:

1.
2.
3.

Actual results:

Expected results:

Additional info:

• https://github.com/openshift/console/pull/12680

Console operator should be building up a set of cluster nodes OS types, which he should supply to console, so it renders only operators that could be installed on the cluster.

This will be needed when we will support different OS types on the cluster.

We need to scan through the compute nodes and build a set of supported OS from those. Each node on the cluster has a label for its operating system: e.g. kubernetes.io/os=linux,

AC:

1. Implement logic in the console-operator that will scan though all the nodes and build a set of all the OS types that the cluster nodes run on and pass it to the console-config.yaml . This set of OS types will be then used by console frontend.
2. Add unit and e2e test cases in the console-operator repository.

• https://github.com/openshift/console-operator/pull/742

Goal: OperatorHub/OLM users get a more intuitive UX around discovering and selecting Operator versions to install.

Problem statement: Today it's not possible to install an older version of an Operator unless the user exactly nows the CSV semantic version. This is not exposed however through any API. `packageserver` as of today only shows the latest version per channel.

Why is this important: There are many reasons why a user would want to choose not to install the latest version - whether it's lack of testing or known problems. It should be easy for a user to discovers what versions of an Operator OLM has in its catalogs and update graphs and expose this information in a consumable way to the user.

Acceptance Criteria:

• Users can choose from a list of "available versions" of an Operator based on the "selected channel" on the 'OperatorHub' page in the console.
• Users can see/examine Operator metadata (e.g. descriptions, version, capability level, links, etc) per selected channel/version to confirm the exact version they are going to install on the OperatorHub page.
• The selected channel/version info will be carried over from the 'OperatorHub' page to 'Install Operator' page in the console.
• Note that "installing an older version" means "no automatic update"; hence, when users select a non-latest Operator version, this implies the "Update" field would be changed to "Manual".
• Operator details sidebar data will update based on the selected channel. `createdAt` `containerImage` and `capability level`

Out of scope:

• provide a version selector for updatres in case of existing installed operators

Related info

UX designs: http://openshift.github.io/openshift-origin-design/designs/administrator/olm/select-install-operator-version/
linked OLM jira: https://issues.redhat.com/browse/OPRUN-1399
where you can see the downstream PR: https://github.com/openshift/operator-framework-olm/pull/437/files
specifically: https://github.com/awgreene/operator-framework-olm/blob/f430b2fdea8bedd177550c95ec[…]r/pkg/package-server/apis/operators/v1/packagemanifest_types.go i.e., you can get a list of available versions in PackageChannel stanza from the packagemanifest API
You can reach out to OLM lead Alex Greene for any question regarding this too, thanks

• https://github.com/openshift/console/pull/12743

• https://github.com/openshift/console-operator/pull/724

We need a way to show metrics for workloads running on spoke clusters. This depends on ACM-876, which lets the console discover the monitoring endpoints.

• Console operator must discover the external URLs for monitoring
• Console operator must pass the URLs and CA files as part of the cluster config to the console backend
• Console backend must set up proxies for each endpoint (as it does for the API server endpoints)
• Console frontend must include the cluster in metrics requests

Open Issues:

We will depend on ACM to create a route on each spoke cluster for the prometheus tenancy service, which is required for metrics for normal users.

Openshift console backend should proxy managed cluster monitoring requests through the MCE cluster proxy addon to prometheus services on the managed cluster. This depends on https://issues.redhat.com/browse/ACM-1188

Given that we have a controller that processes one time etcd backup requests via the "operator.openshift.io/v1alpha1 EtcdBackup" CR, we need another controller that processes the "config.openshift.io/v1alpha1 Backup" CR so we can have periodic backups according the the schedule in the CR spec.

See https://github.com/openshift/api/pull/1482 for the APIs

The workflow for this controller should roughly be:

• Watches the `config.openshift.io/v1alpha1 Backup` CR as created by an admin
• Creates a CronJob for the specified schedule and timezone that would in turn create `operator.openshift.io/v1alpha1 EtcdBackup` CRs at the desired schedule
• Updates the CronJob for any changes in the schedule or timezone

Along with this controller we would also need to provide the workload or Go command for the pod that is created periodically by the CronJob. This cmd e.g "create-etcdbackup-cr" effectively creates a new `operator.openshift.io/v1alpha1 EtcdBackup` CR via the following workflow:

• Read the Backup CR to get the pvcName (and anything else) required to populate an `EtcdBackup` CR

• Create the `operator.openshift.io/v1alpha1 EtcdBackup` CR

Lastly to fulfill the retention policy (None, number of backups saved, or total size of backups), we can employ the following workflow:

• Have another command e.g "prune-backups" cmd that runs prior to the "create-etcdbackup-cr" command that deletes existing backups per the retention policy.

• This cmd is run before the cmd to create the etcdbackup CR. This could be done via an init container on the CronJob execution pod.
• This would require the backup controller to populate the CronJob spec with the pvc name from the Backup spec that would allowing mounting the PV on the execution pod for pruning the backups in the init container.

For testing the automated backups feature we will require an e2e test that validates the backups by ensuring the restore procedure works for a quorum loss disaster recovery scenario.

See the following doc for more background:
https://docs.google.com/document/d/1NkdOwo53mkNBCktV5tkUnbM4vi7bG4fO5rwMR0wGSw8/edit?usp=sharing

This story targets the milestone 2,3 and 4 of the restore test to ensure that the test has the ability to perform a backup and then restore from that backup in a disaster recovery scenario.

While the automated backups API is still in progress, the test will rely on the existing backup script to trigger a backup. Later on when we have a functional backup API behind a feature gate, the test can switch over to using that API to trigger backups.

We're starting with a basic crash-looping member restore first. The quorum loss scenario will be done in ETCD-423.

• https://github.com/openshift/origin/pull/27875

We should add some basic backup e2e tests into our operator:

• one off backups can be run via API
• periodic backups can be run (also multiple times in succession)
  • retention should work

The e2e workflow should be TechPreview enabled already. 

• https://github.com/openshift/cluster-etcd-operator/pull/1089

For testing the automated backups feature we will require an e2e test that validates the backups by ensuring the restore procedure works for a quorum loss disaster recovery scenario.

See the following doc for more background:
https://docs.google.com/document/d/1NkdOwo53mkNBCktV5tkUnbM4vi7bG4fO5rwMR0wGSw8/edit?usp=sharing

This story targets the first milestone of the restore test to ensure we have a platform agnostic way to be able to ssh access all masters in a test cluster so that we can perform the necessary backup, restore and validation workflows.

The suggested approach is to create a static pod that can do those ssh checks and actions from within the cluster but other alternatives can also be explored as part of this story. 

• https://github.com/openshift/origin/pull/27869

To fulfill one time backup requests there needs to be a new controller that reconciles an EtcdBackup CustomResource (CR) object and executes and saves a one time backup of the etcd cluster.
 
Similar to the upgradebackupcontroller the controller would be triggered to create a backup pod/job which would save the backup to the PersistentVolume specified by the spec of the EtcdBackup CR object.

The controller would also need to honor the retention policy specified by the EtcdBackup spec and update the status accordingly.

See the following enhancement and API PRs for more details and potential updates to the API and workflow for the one time backup:
https://github.com/openshift/enhancements/pull/1370
https://github.com/openshift/api/pull/1482

• https://github.com/openshift/cluster-etcd-operator/pull/1066

Description

Hitting the Artifacthub.io search endpoint fails sometimes due to a CORS error and the Version API endpoint always fails due to a CORS error. So, we need a Proxy to hit the Artifacthub. end point to get the data.

Acceptance Criteria

1. Create a proxy to hit the Artifacthub.io endpoint.

Additional Details:

Search endpoint: https://artifacthub.io/docs/api/#/Packages/searchPackages

eg.: https://artifacthub.io/api/v1/packages/search?offset=0&limit=20&facets=false&ts_query_web=git&kind=7&deprecated=false&sort=relevance

Version endpoint: https://artifacthub.io/docs/api/#/Packages/getTektonTaskVersionDetails

eg: https://artifacthub.io/api/v1/packages/tekton-task/tekton-catalog-tasks/git-clone/0.9.0

• https://github.com/openshift/console/pull/12905

As a user, I would like to deploy a hypershift cluster to an x86 managed cluster with an arm nodepool.

Starting point:
https://github.com/openshift/hypershift/blob/main/hypershift-operator/controllers/nodepool/nodepool_controller.go

https://github.com/openshift/hypershift/blob/c7c2b57c98caa518231c15eceefe62e98eece832/hypershift-operator/controllers/nodepool/nodepool_controller.go#L1323

AC:

• Complete necessary code changes to allow ARM AWS nodepools to be added to an x86 managed cluster.

• https://github.com/openshift/hypershift/pull/1594

Add a new installer subcommand, openshift-install agent create config-image.

The should create a small ISO (i.e. not a CoreOS boot image) containing just the configuration files from the automation flow:

• rendezvousIP config file
• ClusterDeployment manifest
• AgentPullSecret manifest
• AgentClusterInstall manifest
• TLS certs for admin kubeconfig
• password hash for kubeadmin console password
• NMStateConfig
• extra manifests
• hostnames
• hostconfig (roles, root device hints)
• ClusterImageSet manifest (for version verification)

The contents in the disk could be in any format, but should be optimised to make it simple for the service in AGENT-562 to read.

• https://github.com/openshift/installer/pull/7157

Implement a systemd service in the unconfigured agent ISO (AGENT-558) that watches for disks to be mounted, then searches them for agent installer configuration. If such configuration is found, then copy it to the relevant places in the running system.

The rendezvousIP must be copied last, as the presence of this is what will trigger the services to start (AGENT-556).

To the extent possible, the service should be agnostic as to the method by which the config disk was mounted (e.g. virtual media, USB stick, floppy disk, &c.). It may be possible to get systemd to trigger on volume mount, avoiding the need to poll anything.

The configuration drive must contain:

• rendezvousIP config file
• ClusterDeployment manifest
• AgentPullSecret manifest
• AgentClusterInstall manifest
• TLS certs for admin kubeconfig
• password hash for kubeadmin console password
• ClusterImageSet manifest (for version verification)

it may optionally contain:

• NMStateConfig
• extra manifests
• hostnames
• hostconfig (roles, root device hints)

The ClusterImageSet manifest must match the one already present in the image for the config to be accepted.

• https://github.com/openshift/installer/pull/7200

Description of problem:

ARO needs to copy RHCOS image blobs to their own Azure Marketplace offering since, as a first party Azure service, they must not request anything from outside of Azure and must consume RHCOS VM images from a trusted source (marketplace).
To meet the requirements ARO team currently does the following as part of the release process:

 1. Mirror container images from quay.io to Azure Container Registry to avoid leaving Azure boundaries.
 2. Copy VM image from the blob in someone else's Azure subscription
 into the blob on the subscription ARO team manages and then we publish a VM image on Azure Marketplace (publisher: azureopenshift, offer: aro4. See az vm image list --publisher azureopenshift --all). We do not bill for these images.

The usage of Marketplace images in the installer was already implemented as part of CORS-1823. This single line [1] needs to be refactored to enable ARO from the installer code perspective: on ARO we don't need to set type to AzureImageTypeMarketplaceWithPlan.

However, in OCPPLAN-7556 and related CORS-1823 it was mentioned that using Marketplace images is out of scope for nodes other than compute. For ARO we need to be able to use marketplace images for all nodes.

[1] https://github.com/openshift/installer/blob/f912534f12491721e3874e2bf64f7fa8d44aa7f5/pkg/asset/machines/azure/machines.go#L107

Version-Release number of selected component (if applicable):

4.13

How reproducible:

Always

Steps to Reproduce:

1. Set RHCOS image from Azure Marketplace in the installconfig
2. Deploy a cluster
3.

Actual results:

Only compute nodes use the Marketplace image.

Expected results:

All nodes created by the Installer use RHCOS image coming from Azure Marketplace.

Additional info:

• https://github.com/openshift/installer/pull/6890

User Story:

Some background on the Licenses field:

https://github.com/openshift/installer/pull/3808#issuecomment-663153787

https://github.com/openshift/installer/pull/4696

So we do not want to allow licenses to be specified (it's up to customers to create a custom image with licenses embedded and supply that to the Installer) when pre-built images are specified (current behaviour). Since we don't need to specify licenses for RHCOs images anymore, the Licenses field is useless and should be deprecated.

Acceptance Criteria:

Description of criteria:

• License field deprecated
• Any dev docs mentioning Licenses is updated.

(optional) Out of Scope:

Detail about what is specifically not being delivered in the story

Engineering Details:

• (optional) https://github/com/link.to.enhancement/
• (optional) https://issues.redhat.com/link.to.spike
• Engineering detail 1
• Engineering detail 2

This requires/does not require a design proposal.
This requires/does not require a feature gate.

• https://github.com/openshift/installer/pull/7397

User Story:

As a user, I want to be able to:

• Specify a RHCOS image coming from a custom source in the install config to override the installer's internal choice of bootimage  

so that I can achieve

• a custom location in the install config for the RHCOS image to use for the Cluster Nodes

Acceptance Criteria:

A user is able to specify a custom location in the Installer manifest for the RHCOS image to be used for bootstrap and cluster Nodes. This is the similar approach we support already for AWS with the compute.platform.aws.amiID option

(optional) Out of Scope:

Engineering Details:

• https://github.com/openshift/installer/pull/7215
• https://github.com/openshift/installer/pull/7258