mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 3. Updating the Undercloud This process updates the undercloud and its overcloud images to the latest Red Hat OpenStack Platform 16.0 version. 3.1. Performing a minor update of a containerized undercloud The director provides commands to update the packages on the undercloud node. This allows you to perform a minor update within the current version of your OpenStack Platform environment. Procedure Log into the director as the stack user. Run dnf to upgrade the director's main packages: The director uses the openstack undercloud upgrade command to update the undercloud environment. Run the command: Wait until the undercloud upgrade process completes. Reboot the undercloud to update the operating system's kernel and other system packages: Wait until the node boots. 3.2. Updating the overcloud images You need to replace your current overcloud images with new versions. The new images ensure the director can introspect and provision your nodes using the latest version of OpenStack Platform software. Prerequisites You have updated the undercloud to the latest version. Procedure Source the stackrc file: Remove any existing images from the images directory on the stack user's home ( /home/stack/images ): Extract the archives: Import the latest images into the director: Configure your nodes to use the new images: Verify the existence of the new images: Important When deploying overcloud nodes, ensure the overcloud image version corresponds to the respective heat template version. For example, only use the OpenStack Platform 16 images with the OpenStack Platform 16 heat templates. Important The new overcloud-full image replaces the old overcloud-full image. If you made changes to the old image, you must repeat the changes in the new image, especially if you want to deploy new nodes in the future. 3.3. Undercloud Post-Upgrade Notes If using a local set of core templates in your stack users home directory, ensure you update the templates using the recommended workflow in Using Customized Core Heat Templates in the Advanced Overcloud Customization guide. You must update the local copy before upgrading the overcloud. 3.4. Steps The undercloud upgrade is complete. You can now update the overcloud.

Commands:
sudo dnf update -y python3-tripleoclient* openstack-tripleo-common openstack-tripleo-heat-templates tripleo-ansible
openstack undercloud upgrade
sudo reboot
source ~/stackrc
rm -rf ~/images/*
cd ~/images for i in /usr/share/rhosp-director-images/overcloud-full-latest-16.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-16.0.tar; do tar -xvf USDi; done cd ~
openstack overcloud image upload --update-existing --image-path /home/stack/images/
openstack overcloud node configure USD(openstack baremetal node list -c UUID -f value)
openstack image list ls -l /var/lib/ironic/httpboot
Deploying and managing OpenShift Data Foundation using Red Hat OpenStack Platform Red Hat OpenShift Data Foundation 4.14 Instructions on deploying and managing OpenShift Data Foundation on Red Hat OpenStack Platform Red Hat Storage Documentation Team Abstract Read this document for instructions about how to install and manage Red Hat OpenShift Data Foundation using Red Hat OpenShift Container Platform on Red Hat OpenStack Platform (RHOSP). Important Deploying and managing OpenShift Data Foundation on Red Hat OpenStack Platform is a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

Commands:
Chapter 54. CertificateAuthority schema reference Used in: KafkaSpec Configuration of how TLS certificates are used within the cluster. This applies to certificates used for both internal communication within the cluster and to certificates used for client access via Kafka.spec.kafka.listeners.tls . Property Property type Description generateCertificateAuthority boolean If true then Certificate Authority certificates will be generated automatically. Otherwise the user will need to provide a Secret with the CA certificate. Default is true. generateSecretOwnerReference boolean If true , the Cluster and Client CA Secrets are configured with the ownerReference set to the Kafka resource. If the Kafka resource is deleted when true , the CA Secrets are also deleted. If false , the ownerReference is disabled. If the Kafka resource is deleted when false , the CA Secrets are retained and available for reuse. Default is true . validityDays integer The number of days generated certificates should be valid for. The default is 365. renewalDays integer The number of days in the certificate renewal period. This is the number of days before the a certificate expires during which renewal actions may be performed. When generateCertificateAuthority is true, this will cause the generation of a new certificate. When generateCertificateAuthority is true, this will cause extra logging at WARN level about the pending certificate expiry. Default is 30. certificateExpirationPolicy string (one of [replace-key, renew-certificate]) How should CA certificate expiration be handled when generateCertificateAuthority=true . The default is for a new CA certificate to be generated reusing the existing private key.

Commands:
7.6. NotifyingFutures Methods in Red Hat JBoss Data Grid do not return Java Development Kit (JDK) Futures , but a sub-interface known as a NotifyingFuture . Unlike a JDK Future , a listener can be attached to a NotifyingFuture to notify the user about a completed future. Note NotifyingFutures are only available in JBoss Data Grid Library mode. Report a bug 7.6.1. NotifyingFutures Example The following is an example depicting how to use NotifyingFutures in Red Hat JBoss Data Grid: Example 7.6. Configuring NotifyingFutures Report a bug

Commands:
FutureListener futureListener = new FutureListener() { public void futureDone(Future future) { try { future.get(); } catch (Exception e) { // Future did not complete successfully System.out.println("Help!"); } } }; cache.putAsync("key", "value").attachListener(futureListener);
Chapter 18. Registering RHEL by using Subscription Manager Post-installation, you must register your system to get continuous updates. 18.1. Registering RHEL 9 using the installer GUI You can register a Red Hat Enterprise Linux 9 by using the RHEL installer GUI. Prerequisites You have a valid user account on the Red Hat Customer Portal. See the Create a Red Hat Login page . You have a valid Activation Key and Organization id. Procedure From the Installation Summary screen, under Software , click Connect to Red Hat . Authenticate your Red Hat account using the Account or Activation Key option. Optional: In the Set System Purpose field select the Role , SLA , and Usage attribute that you want to set from the drop-down menu. At this point, your Red Hat Enterprise Linux 9 system has been successfully registered. 18.2. Registration Assistant Registration Assistant is designed to help you choose the most suitable registration option for your Red Hat Enterprise Linux environment. Additional resources For assistance with using a username and password to register RHEL with the Subscription Manager client, see the RHEL registration assistant on the Customer Portal. For assistance with registering your RHEL system to Red Hat Insights, see the Insights registration assistant on the Hybrid Cloud Console. 18.3. Registering your system using the command line You can register your Red Hat Enterprise Linux 9 subscription by using the command line. For an improved and simplified experience registering your hosts to Red Hat, use remote host configuration (RHC). The RHC client registers your system to Red Hat making your system ready for Insights data collection and enabling direct issue remediation from Insights for Red Hat Enterprise Linux. For more information, see RHC registration . Prerequisites You have an active, non-evaluation Red Hat Enterprise Linux subscription. Your Red Hat subscription status is verified. You have not previously received a Red Hat Enterprise Linux 9 subscription. You have successfully installed Red Hat Enterprise Linux 9 and logged into the system as root. Procedure Open a terminal window as a root user. Register your Red Hat Enterprise Linux system by using the activation key: When the system is successfully registered, an output similar to the following is displayed: Additional resources Using an activation key to register a system with Red Hat Subscription Manager Getting Started with RHEL System Registration

Commands:
subscription-manager register --activationkey= <activation_key_name> --org= <organization_ID>
The system has been registered with id: 62edc0f8-855b-4184-b1b8-72a9dc793b96
B.24. gdb B.24.1. RHBA-2011:0145 - gdb bug fix update Updated gdb packages that fix a bug are now available for Red Hat Enterprise Linux 6. The GNU debugger, gdb, allows the debugging of programs written in C, C++, and other languages by executing them in a controlled fashion and then printing out their data. Bug Fix BZ# 662218 After you issued the command 'info program', GDB could have terminated unexpectedly, because a change of the shared library list corrupted the data in the internal GDB structure 'bpstat'. With this update, the 'bpstat' structure contains after a change in the shared library list the correct data and the command 'info program' works as expected. All users of gdb are advised to upgrade to these updated packages, which fix this bug.

Commands:
Chapter 2. Architectures Red Hat Enterprise Linux 8.6 is distributed with the kernel version 4.18.0-372, which provides support for the following architectures: AMD and Intel 64-bit architectures The 64-bit ARM architecture IBM Power Systems, Little Endian 64-bit IBM Z Make sure you purchase the appropriate subscription for each architecture. For more information, see Get Started with Red Hat Enterprise Linux - additional architectures . For a list of available subscriptions, see Subscription Utilization on the Customer Portal.

Commands:
3.4. Creating a system image with Image Builder in the command-line interface This procedure describes how to edit an existing Image Builder blueprint in the command-line interface. Prerequisites You have a blueprint prepared for the image. Procedure 1. Start the compose: Replace BLUEPRINT-NAME with name of the blueprint, and IMAGE-TYPE with the type of image. For possible values, see output of the composer-cli compose types command. The compose process starts in the background and the UUID of the compose is shown. 2. Wait until the compose is finished. Please, notice that this may take several minutes. To check the status of the compose: A finished compose shows a status value FINISHED . Identify the compose in the list by its UUID. 3. Once the compose is finished, download the resulting image file: Replace UUID with the UUID value shown in the steps. Alternatively, you can access the image file directly under the path /var/lib/lorax/composer/results/UUID/ . You can also download the logs using the composer-cli compose logs UUID command, or the metadata using the composer-cli compose metadata UUID command.

Commands:
composer-cli compose start BLUEPRINT-NAME IMAGE-TYPE
composer-cli compose status
composer-cli compose image UUID
Chapter 1. Overview This guide describes how to manage Instance High Availability (Instance HA) . Instance HA allows Red Hat OpenStack Platform to automatically evacuate and re-spawn instances on a different Compute node when their host Compute node fails. The evacuation process that is triggered by Instance HA is similar to what users can do manually, as described in Evacuate Instances . Instance HA works on shared storage or local storage environments, which means that evacuated instances maintain the same network configuration (static IP, floating IP, and so on) and the same characteristics inside the new host, even if they are spawned from scratch. Instance HA is managed by the following resource agents: Agent name Name inside cluster Role fence_compute fence-nova Marks a Compute node for evacuation when the node becomes unavailable. NovaEvacuate nova-evacuate Evacuates instances from failed nodes. This agent runs on one of the Controller nodes. Dummy compute-unfence-trigger Releases a fenced node and enables the node to run instances again.

Commands:
8.150. perl-Test-MockObject 8.150.1. RHBA-2013:0836 - perl-Test-MockObject bug fix update Updated perl-Test-MockObject packages that fix one bug are now available for Red Hat Enterprise Linux 6. Test::MockObject is a highly polymorphic testing object, capable of looking like all sorts of objects. This makes white-box testing much easier, as you can concentrate on what the code being tested sends to and receives from the mocked object, instead of worrying about making up your own data. Bug Fix BZ# 661804 Building a perl-Test-MockObject source RPM package without an installed perl-CGI package failed on test execution. To fix this bug, build-time dependencies on the CGI, Test::Builder, and Test::More Perl modules have been declared in the RPM package. As a result, it is possible to rebuild the perl-Test-MockObject source RPM package in a minimal environment. Users of perl-Test-MockObject are advised to upgrade to these updated packages, which fix this bug.

Commands:
6.14.5. Configuring Redundant Ring Protocol As of Red Hat Enterprise Linux 6.4, the Red Hat High Availability Add-On supports the configuration of redundant ring protocol. When using redundant ring protocol, there are a variety of considerations you must take into account, as described in Section 8.6, "Configuring Redundant Ring Protocol" . To specify a second network interface to use for redundant ring protocol, you add an alternate name for the node using the --addalt option of the ccs command: For example, the following command configures the alternate name clusternet-node1-eth2 for the cluster node clusternet-node1-eth1 : Optionally, you can manually specify a multicast address, a port, and a TTL for the second ring. If you specify a multicast for the second ring, either the alternate multicast address or the alternate port must be different from the multicast address for the first ring. If you specify an alternate port, the port numbers of the first ring and the second ring must differ by at least two, since the system itself uses port and port-1 to perform operations. If you do not specify an alternate multicast address, the system will automatically use a different multicast address for the second ring. To specify an alternate multicast address, port, or TTL for the second ring, you use the --setaltmulticast option of the ccs command: For example, the following command sets an alternate multicast address of 239.192.99.88, a port of 888, and a TTL of 3 for the cluster defined in the cluster.conf file on node clusternet-node1-eth1 : To remove an alternate multicast address, specify the --setaltmulticast option of the ccs command but do not specify a multicast address. Note that executing this command resets all other properties that you can set with the --setaltmulticast option to their default values, as described in Section 6.1.5, "Commands that Overwrite Settings" . When you have finished configuring all of the components of your cluster, you will need to sync the cluster configuration file to all of the nodes, as described in Section 6.15, "Propagating the Configuration File to the Cluster Nodes" .

Commands:
ccs -h host --addalt node_name alt_name
ccs -h clusternet-node1-eth1 --addalt clusternet-node1-eth1 clusternet-node1-eth2
ccs -h host --setaltmulticast [ alt_multicast_address ] [ alt_multicast_options ].
ccs -h clusternet-node1-eth1 --setaltmulticast 239.192.99.88 port=888 ttl=3
6.8. Dynamic VDB ZIP Deployment For more complicated scenarios you can deploy a VDB via a ZIP file similar. In a VDB ZIP deployment: The deployment must end with the extension .vdb . The VDB XML file must be named vdb.xml and placed in the ZIP under the META-INF directory. If a lib folder exists, any JARs found underneath will automatically be added to the VDB classpath. For backwards compatibility with Teiid Designer VDBs, if any .INDEX file exists, the default metadata repository will be assumed to be INDEX. Files within the VDB ZIP are accessible by a Custom Metadata Repository using the MetadataFactory.getVDBResources() method, which returns a map of all VDBResources in the VDB keyed by absolute path relative to the VDB root. See Red Hat JBoss Data Virtualization Development Guide: Server Development for more information about custom metadata repositories. The built-in DDL-FILE metadata repository type may be used to define DDL-based metadata in files outside of the vdb.xml . This improves the memory footprint of the VDB metadata and the maintainability of vdb.xml . Example 6.2. Example VDB Zip Structure In the above example the vdb.xml could use a DDL-FILE metadata type for schema1 :

Commands:
/META-INF vdb.xml /ddl schema1.ddl /lib some-udf.jar
<model name="schema1" <metadata type="DDL-FILE">/ddl/schema1.ddl<metadata> </model>
Chapter 4. Technology preview This section describes Technology Preview features in AMQ Broker 7.9. Important Technology Preview features are not supported with Red Hat production service-level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them for production. For more information, see Red Hat Technology Preview Features Support Scope . Quorum voting improvements In versions of AMQ Broker you needed to configure at least three live-backup pairs to use quorum voting to avoid having two live brokers when using replication high availability (HA) policy. Starting in 7.9, you can configure failover to use Apache Curator and Apache ZooKeeper to provide quorum voting using two brokers. For information about using this feature, see High Availability and Failover in the Apache ActiveMQ Artemis documentation. Client connection balancing improvements In releases, there was no method to balance client connections server-side. Starting in 7.9, you can specify pools of brokers and policies for balancing client connections. For example, you can specify a LEAST_CONNECTIONS policy that ensures that clients are redirected to brokers with the fewest active connections. For information about using this feature, see Broker Balancers in the Apache ActiveMQ Artemis documentation. Viewing brokers in Fuse Console You can configure an Operator-based broker deployment to use Fuse Console for OpenShift instead of AMQ Management Console. When you have configured your broker deployment appropriately, Fuse Console discovers the brokers and displays them on a dedicated Artemis tab. For more information, see Viewing brokers in Fuse Console in Deploying AMQ Broker on OpenShift . Note Viewing brokers in Fuse Console is a Technology Preview feature for Fuse 7.8 .

Commands:
19.2. Email Program Classifications In general, all email applications fall into at least one of three classifications. Each classification plays a specific role in the process of moving and managing email messages. While most users are only aware of the specific email program they use to receive and send messages, each one is important for ensuring that email arrives at the correct destination. 19.2.1. Mail Transport Agent A Mail Transport Agent ( MTA ) transports email messages between hosts using SMTP . A message may involve several MTAs as it moves to its intended destination. While the delivery of messages between machines may seem rather straightforward, the entire process of deciding if a particular MTA can or should accept a message for delivery is quite complicated. In addition, due to problems from spam, use of a particular MTA is usually restricted by the MTA's configuration or the access configuration for the network on which the MTA resides. Many modern email client programs can act as an MTA when sending email. However, this action should not be confused with the role of a true MTA. The sole reason email client programs are capable of sending email like an MTA is because the host running the application does not have its own MTA. This is particularly true for email client programs on non-UNIX-based operating systems. However, these client programs only send outbound messages to an MTA they are authorized to use and do not directly deliver the message to the intended recipient's email server. Since Red Hat Enterprise Linux offers two MTAs, Postfix and Sendmail , email client programs are often not required to act as an MTA. Red Hat Enterprise Linux also includes a special purpose MTA called Fetchmail . For more information on Postfix, Sendmail, and Fetchmail, see Section 19.3, "Mail Transport Agents" .

Commands:
Chapter 9. Troubleshooting and deleting remaining resources during Uninstall Occasionally some of the custom resources managed by an operator may remain in "Terminating" status waiting on the finalizer to complete, although you have performed all the required cleanup tasks. In such an event you need to force the removal of such resources. If you do not do so, the resources remain in the Terminating state even after you have performed all the uninstall steps. Check if the openshift-storage namespace is stuck in the Terminating state upon deletion. Output: Check for the NamespaceFinalizersRemaining and NamespaceContentRemaining messages in the STATUS section of the command output and perform the step for each of the listed resources. Example output : Delete all the remaining resources listed in the step. For each of the resources to be deleted, do the following: Get the object kind of the resource which needs to be removed. See the message in the above output. Example : message: Some content in the namespace has finalizers remaining: cephobjectstoreuser.ceph.rook.io Here cephobjectstoreuser.ceph.rook.io is the object kind. Get the Object name corresponding to the object kind. Example : Example output: Patch the resources. Example: Output: Verify that the openshift-storage project is deleted. Output: If the issue persists, reach out to Red Hat Support .

Commands:
oc get project -n <namespace>
NAME DISPLAY NAME STATUS openshift-storage Terminating
oc get project openshift-storage -o yaml
status: conditions: - lastTransitionTime: "2020-07-26T12:32:56Z" message: All resources successfully discovered reason: ResourcesDiscovered status: "False" type: NamespaceDeletionDiscoveryFailure - lastTransitionTime: "2020-07-26T12:32:56Z" message: All legacy kube types successfully parsed reason: ParsedGroupVersions status: "False" type: NamespaceDeletionGroupVersionParsingFailure - lastTransitionTime: "2020-07-26T12:32:56Z" message: All content successfully deleted, may be waiting on finalization reason: ContentDeleted status: "False" type: NamespaceDeletionContentFailure - lastTransitionTime: "2020-07-26T12:32:56Z" message: 'Some resources are remaining: cephobjectstoreusers.ceph.rook.io has 1 resource instances' reason: SomeResourcesRemain status: "True" type: NamespaceContentRemaining - lastTransitionTime: "2020-07-26T12:32:56Z" message: 'Some content in the namespace has finalizers remaining: cephobjectstoreuser.ceph.rook.io in 1 resource instances' reason: SomeFinalizersRemain status: "True" type: NamespaceFinalizersRemaining
oc get <Object-kind> -n <project-name>
oc get cephobjectstoreusers.ceph.rook.io -n openshift-storage
NAME AGE noobaa-ceph-objectstore-user 26h
oc patch -n <project-name> <object-kind>/<object-name> --type=merge -p '{"metadata": {"finalizers":null}}'
oc patch -n openshift-storage cephobjectstoreusers.ceph.rook.io/noobaa-ceph-objectstore-user --type=merge -p '{"metadata": {"finalizers":null}}'
cephobjectstoreuser.ceph.rook.io/noobaa-ceph-objectstore-user patched
oc get project openshift-storage
Error from server (NotFound): namespaces "openshift-storage" not found