mtpti5iD/redhat-docs_dataset huggingface dataset:
3.3. Non-blocking Statement Execution JDBC query execution can indefinitely block the calling thread when a statement is executed or a resultset is being iterated. In some situations you may wish to have your calling threads held in these blocked states. When using embedded connections, you may optionally use the org.teiid.jdbc.TeiidStatement and org.teiid.jdbc.TeiidPreparedStatement interfaces to execute queries with a callback org.teiid.jdbc.StatementCallback that will be notified of statement events, such as an available row, an exception, or completion. Your calling thread will be free to perform other work. The callback will be executed by an engine processing thread as needed. If your results processing is blocking and you want query processing to run concurrently with results processing, then your callback should implement onRow handling in a multi-threaded manner to allow the engine thread to continue. Note The non-blocking logic is limited to statement execution only. Other JDBC operations, such as connection creation or batched executions do not yet have non-blocking options. If you access forward positions in the onRow method (calling , isLast, isAfterLast, absolute), they may not yet be valid and a org.teiid.jdbc.AsynchPositioningException will be thrown. That exception is recoverable if caught or can be avoided by calling TeiidResultSet.available() to determine if your desired positioning will be valid.

Commands:
PreparedStatement stmt = connection.prepareStatement(sql); TeiidPreparedStatement tStmt = stmt.unwrap(TeiidPreparedStatement.class); tStmt.submitExecute(new StatementCallback() { @Override public void onRow(Statement s, ResultSet rs) { //any logic that accesses the current row System.out.println(rs.getString(1)); } @Override public void onException(Statement s, Exception e) throws Exception { s.close(); } @Override public void onComplete(Statement s) throws Exception { s.close(); }, new RequestOptions() });
4.250. python-slip 4.250.1. RHBA-2012:0413 - python-slip bug fix update Updated python-slip packages that fix one bug are now available for Red Hat Enterprise Linux 6. The Simple Library for Python (SLIP) packages contain miscellaneous code for convenience, extension and workaround purposes. The python-slip packages have been upgraded to upstream version 0.2.20, which provides a number of bug fixes over the version. In addition, this update fixes a bug causing versions of python-slip to incorrectly determine whether SELinux was enabled or not. Therefore, convenience functions for writing files always attempted to set SELinux labels even if SELinux was disabled. This could cause for example the system-config-date tool to fail to change settings. (BZ# 796323 ) All users of python-slip are advised to upgrade to these updated packages, which fix this bug.

Commands:
function::user_string_n2 Name function::user_string_n2 - Retrieves string of given length from user space Synopsis Arguments addr the user space address to retrieve the string from n the maximum length of the string (if not null terminated) err_msg the error message to return when data isn't available Description Returns the C string of a maximum given length from a given user space address. Returns the given error message string on the rare cases when userspace data is not accessible at the given address.

Commands:
user_string_n2:string(addr:long,n:long,err_msg:string)
Chapter 8. Monitoring a high availability Red Hat Ceph Storage cluster When you deploy an overcloud with Red Hat Ceph Storage, Red Hat OpenStack Platform uses the ceph-mon monitor daemon to manage the Ceph cluster. Director deploys the daemon on all Controller nodes. 8.1. Checking Red Hat Ceph monitoring service status To check the status of the Red Hat Ceph Storage monitoring service, log in to a Controller node and run the service ceph status command. Procedure Log in to a Controller node and check that the Ceph Monitoring service is running: 8.2. Checking Red Hat Ceph monitoring configuration To check the configuration of the Red Hat Ceph Storage monitoring service, log in to a Controller node or a Red Hat Ceph node and open the /etc/ceph/ceph.conf file. Procedure Log in to a Controller nodes or on a Ceph node and open the /etc/ceph/ceph.conf file to view the monitoring configuration parameters: This example shows the following information: All three Controller nodes are configured to monitor the Red Hat Ceph Storage cluster with the mon_initial_members parameter. The 172.19.0.11/24 network is configured to provide a communication path between the Controller nodes and the Red Hat Ceph Storage nodes. The Red Hat Ceph Storage nodes are assigned to a separate network from the Controller nodes, and the IP addresses for the monitoring Controller nodes are 172.18.0.15 , 172.18.0.16 , and 172.18.0.17 . 8.3. Checking Red Hat Ceph node status To check the status of a specific Red Hat Ceph Storage node, log in to the node and run the ceph -s command. Procedure Log in to the Ceph node and run the ceph -s command: This example output shows that the health parameter value is HEALTH_OK , which indicates that the Ceph node is active and healthy. The output also shows three Ceph monitor services that are running on the three overcloud-controller nodes and the IP addresses and ports of the services. 8.4. Additional resources Red Hat Ceph product page

Commands:
sudo service ceph status === mon. overcloud-controller-0 === mon. overcloud-controller-0 : running {"version":"0.94.1"}
[global] osd_pool_default_pgp_num = 128 osd_pool_default_min_size = 1 auth_service_required = cephx mon_initial_members = overcloud-controller-0 , overcloud-controller-1 , overcloud-controller-2 fsid = 8c835acc-6838-11e5-bb96-2cc260178a92 cluster_network = 172.19.0.11/24 auth_supported = cephx auth_cluster_required = cephx mon_host = 172.18.0.17,172.18.0.15,172.18.0.16 auth_client_required = cephx osd_pool_default_size = 3 osd_pool_default_pg_num = 128 public_network = 172.18.0.17/24
ceph -s cluster 8c835acc-6838-11e5-bb96-2cc260178a92 health HEALTH_OK monmap e1: 3 mons at { overcloud-controller-0 =172.18.0.17:6789/0, overcloud-controller-1 =172.18.0.15:6789/0, overcloud-controller-2 =172.18.0.16:6789/0} election epoch 152, quorum 0,1,2 overcloud-controller-1 , overcloud-controller-2 , overcloud-controller-0 osdmap e543: 6 osds: 6 up, 6 in pgmap v1736: 256 pgs, 4 pools, 0 bytes data, 0 objects 267 MB used, 119 GB / 119 GB avail 256 active+clean
Appendix C. Using AMQ Broker with the examples The AMQ Python examples require a running message broker with a queue named examples . Use the procedures below to install and start the broker and define the queue. C.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . C.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... C.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named examples . USD <broker-instance-dir> /bin/artemis queue create --name examples --address examples --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. C.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2020-10-08 11:25:07 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name examples --address examples --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
Chapter 15. Testing Your Models 15.1. Manage Connection Profiles 15.1.1. Manage Connection Profiles As described earlier, you can test your models in Teiid Designer by using the Preview Data action or test your models via your deployable VDB. Teiid Designer utilizes the Eclipse Data Tools Platform (DTP) Connection Profile framework for connection management. Connection Profiles provide a mechanism to connect to JDBC and non-JDBC sources to access metadata for constructing metadata source models. Teiid Designer also provides a custom Teiid connection profile template designed as a JDBC source to a deployed VDB. By selecting various Teiid Designer Import options, any applicable Connection Profiles you have defined in your Database Development perspective will be available to use as your import source. From these import wizards you can also create new connection profiles or edit existing connection profiles without leaving the wizard. The Server view provides access to running Teiid instances and shows data source and VDB artifacts deployed there. The Create Data Source action available on this view utilizes the available and applicable connection profiles. 15.1.2. Set Connection Profile for Source Model Teiid Designer integrates Data Tools Connection Profiles by persisting pertinent connection information in each source model. This can occur through Importing process or through the Modeling > Set Connection Profile action. 15.1.3. View Connection Profile for Source Model In addition to setting the connection profile on a source model you can also view a source model's connection profile information via the Modeling > View Connection Profile Info action which displays the detailed properties of the connection. Figure 15.1. Connection Profile Information Dialog (in this image is used flat file connection profile) Note If a source model has no associated connection profile the following dialog will be displayed. Figure 15.2. No Connection Info Dialog 15.1.4. Remove Connection Profile from Source Model As a user, you may not want this connection information (i.e. URL, username, etc...) shared through your VDB. Designer provides a means to remove this connection information via a Modeling > Remove Connection Info action. When adding a source model without connection information will require the user to supply or select the correct translator type.

Commands:
6.3. Upgrading from Red Hat Enterprise Linux 6.X to Red Hat Enterprise Linux 7.X Install migration tool Disable all repositories Disable all the enabled repositories: Download the operating system as an ISO file Follow these steps to download the latest ISO file for one of the following operating systems. Red Hat Enterprise Linux 7 based Red Hat Gluster Storage 3.5 Visit the Red Hat Customer Service Portal at https://access.redhat.com/login and enter your user name and password to log in. Click Downloads to go to the Software & Download Center. Click Red Hat Gluster Storage. Select 3.5 for RHEL 7 (latest) from the Version dropdown menu. Important If you are upgrading to Red Hat Gluster Storage 3.5, select version 3.4 for RHEL 7 . Bug 1762637 means that the Preupgrade Assistant only allows upgrading to Red Hat Enterprise Linux 7.6 at this time. Click Download Now beside the Red Hat Gluster Storage Server 3.5 on RHEL 7 Installation DVD. Red Hat Enterprise Linux 7 Visit the Red Hat Customer Service Portal at https://access.redhat.com/login and enter your user name and password to log in. Click Downloads to go to the Software & Download Center. Click Versions 7 and below, beside Red Hat Enterprise Linux. Select 7. x (latest) from the Version dropdown menu. Important If you are upgrading to Red Hat Gluster Storage 3.5, select version 7.6 . Bug 1762637 means that the Preupgrade Assistant only allows upgrading to Red Hat Enterprise Linux 7.6 at this time. Click Download Now beside the Red Hat Enterprise Linux 7.x Binary DVD. Upgrade to Red Hat Enterprise Linux 7 using ISO Upgrade to Red Hat Enterprise Linux 7 using the Red Hat upgrade tool and reboot after the upgrade process is completed: Important The upgrade process is time-consuming depending on your system's configuration and amount of data.

Commands:
yum install redhat-upgrade-tool yum install yum-utils
yum-config-manager --disable \*
redhat-upgrade-tool --iso ISO_filepath --cleanup-post reboot
Chapter 27. Email Notifications Different events related to billing trigger email notifications for API providers and developers. 27.1. Provider notifications The users of the 3scale account (admins and members with Billing permission) can subscribe to or unsubscribe from the notifications related to billing at Account Settings (gear icon on the top-right) > Personal > Notification Preferences , under Billing section: Action required: review invoices Sent a few days before end of billing cycle so you can review invoices before they are being sent to customers. Customer downgraded Sent when a customer changes to a plan with a lower monthly fixed price. Expiring credit card Sent when a customer's credit card is about to expire. Payment error (retry) Sent when payment fails, resulting in an unpaid invoice and a retry. Payment error (final) Sent when the final retry of a payment fails, resulting in a failed invoice. All admin users of the 3scale account will receive notifications regarding billing, if they are subscribed to them. 27.2. Developer emails The email notifications sent to the developer accounts can be configured at Audience > Messages > Email Templates . The following emails are available: Credit card expired notification for buyer Sent when the credit card is due to expire soon. Invoice charged successfully for buyer Sent when the invoice has been successfully charged. Invoice charge failure for buyer with retry Sent when the invoice charge has failed, and the invoice is in Failed state, which means that the charging will be retried again. Invoice charge failure for buyer without retry Invoice charge has failed for the 3rd time, the invoice has passed to Unpaid state and will not be retried again. Upcoming invoice charge for buyer Sent when the invoice is issued for the developer. All admin users of the developer account will receive the above notifications. 27.2.1. Billing email address You can configure an email address that your customers can contact for resolving any issues with billing, for example, billing@example.com, in Audience > Messages > Support Emails in the Finance support email field. The email templates reference the email address with the Liquid drop {{ provider.finance_support_email }} .

Commands:
4.6. RHEA-2012:0840 - new packages: java-1.7.0-ibm New java-1.7.0-ibm packages are now available for Red Hat Enterprise Linux 6. The java-1.7.0-ibm packages provide the IBM Java 7 Runtime Environment and the IBM Java 7 Software Development Kit. This update adds the java-1.7.0-ibm packages to Red Hat Enterprise Linux 6. (BZ# 693783 ) Note: Before applying this update, make sure that any IBM Java packages have been removed. All users who require java-1.7.0-ibm should install these new packages.

Commands:
9.4.4. Using LDAP to Store Automounter Maps LDAP client libraries must be installed on all systems configured to retrieve automounter maps from LDAP. On Red Hat Enterprise Linux, the openldap package should be installed automatically as a dependency of the automounter . To configure LDAP access, modify /etc/openldap/ldap.conf . Ensure that BASE, URI, and schema are set appropriately for your site. The most recently established schema for storing automount maps in LDAP is described by rfc2307bis . To use this schema it is necessary to set it in the autofs configuration /etc/autofs.conf by removing the comment characters from the schema definition. Example 9.4. Setting autofs configuration Note As of Red Hat Enterprise Linux 6.6, LDAP autofs is set in the /etc/autofs.conf file instead of the /etc/systemconfig/autofs file as was the case in releases. Ensure that these are the only schema entries not commented in the configuration. The automountKey replaces the cn attribute in the rfc2307bis schema. An LDIF of a sample configuration is described below: Example 9.5. LDIF configuration

Commands:
map_object_class = automountMap entry_object_class = automount map_attribute = automountMapName entry_attribute = automountKey value_attribute = automountInformation
extended LDIF # LDAPv3 base <> with scope subtree filter: (&(objectclass=automountMap)(automountMapName=auto.master)) requesting: ALL # auto.master, example.com dn: automountMapName=auto.master,dc=example,dc=com objectClass: top objectClass: automountMap automountMapName: auto.master extended LDIF # LDAPv3 base <automountMapName=auto.master,dc=example,dc=com> with scope subtree filter: (objectclass=automount) requesting: ALL # /home, auto.master, example.com dn: automountMapName=auto.master,dc=example,dc=com objectClass: automount cn: /home automountKey: /home automountInformation: auto.home extended LDIF # LDAPv3 base <> with scope subtree filter: (&(objectclass=automountMap)(automountMapName=auto.home)) requesting: ALL # auto.home, example.com dn: automountMapName=auto.home,dc=example,dc=com objectClass: automountMap automountMapName: auto.home extended LDIF # LDAPv3 base <automountMapName=auto.home,dc=example,dc=com> with scope subtree filter: (objectclass=automount) requesting: ALL # foo, auto.home, example.com dn: automountKey=foo,automountMapName=auto.home,dc=example,dc=com objectClass: automount automountKey: foo automountInformation: filer.example.com:/export/foo /, auto.home, example.com dn: automountKey=/,automountMapName=auto.home,dc=example,dc=com objectClass: automount automountKey: / automountInformation: filer.example.com:/export/&
Chapter 2. Storage 2.1. Storage Domains Overview A storage domain is a collection of images that have a common storage interface. A storage domain contains complete images of templates and virtual machines (including snapshots), ISO files, and metadata about themselves. A storage domain can be made of either block devices (SAN - iSCSI or FCP) or a file system (NAS - NFS, GlusterFS, or other POSIX compliant file systems). On NAS, all virtual disks, templates, and snapshots are files. On SAN (iSCSI/FCP), each virtual disk, template or snapshot is a logical volume. Block devices are aggregated into a logical entity called a volume group, and then divided by LVM (Logical Volume Manager) into logical volumes for use as virtual hard disks. See the Red Hat Enterprise Linux Logical Volume Manager Administration Guide for more information on LVM. Virtual disks can have one of two formats, either QCOW2 or raw. The type of storage can be either sparse or preallocated. Snapshots are always sparse but can be taken for disks of either format. Virtual machines that share the same storage domain can be migrated between hosts that belong to the same cluster.

Commands:
Chapter 5. Validating your OpenStack cloud with the Integration Test Suite (tempest) You can run Integration Test Suite validations in many ways with the tempest run command. You can also combine multiple options in a single tempest run command. 5.1. Prerequisites An OpenStack environment that contains the Integration Test Suite packages. An Integration Test Suite configuration that corresponds to your OpenStack environment. For more information, see Creating a workspace . 5.2. Listing available tests Use the --list-tests option to list all available tests. Procedure Enter the tempest run command with either the --list-tests or -l options to get a list of available tempest tests: 5.3. Running smoke tests Smoke testing is a type of preliminary testing which covers only the most important functionality. Although these tests are not comprehensive, running smoke tests can save time if they do identify a problem. Procedure Enter the tempest run command with the --smoke option: 5.4. Passing tests by using allowlist files An allowlist file is a file that contains regular expressions to select tests that you want to include. If you use one or more regular expressions, specify each expression on a separate line. Procedure Enter the tempest run command with either the --whitelist-file or -w options to use an allowlist file: 5.5. Skipping tests by using blocklist files A blocklist file is a file that contains regular expressions to select tests that you want to exclude. If you use one or more regular expressions, specify each expression on a separate line. Procedure Enter the tempest run command with either the --blacklist-file or -b options to use a blocklist file: 5.6. Running tests in parallel or in series You can run tests in parallel, or in series. You can also define the number of workers that you want to use when you run parallel tests. By default, the Integration Test Suite uses one worker for each CPU available. Choose to run the tests serially or in parallel: Run the tests serially: Run the tests in parallel (default): Use the --concurrency or -c option to specify the number of workers to use when you run tests in parallel: 5.7. Running specific tests Run specific tests with the --regex option. The regular expression must be Python regular expression: Procedure Enter the following command: For example, use the following example command to run all tests that have names that begin with tempest.scenario : 5.8. Deleting Integration Test Suite objects Enter the tempest cleanup command to delete all Integration Test Suite (tempest) resources. This command also deletes projects, but the command does not delete the administrator account: Procedure Delete the tempest resources:

Commands:
tempest run -l
tempest run --smoke
tempest run -w <whitelist_file>
tempest run -b <blacklist_file>
tempest run --serial
tempest run --parallel
tempest run --concurrency <workers>
tempest run --regex <regex>
tempest run --regex ^tempest.scenario
tempest cleanup --delete-tempest-conf-objects
Chapter 2. Installing the Red Hat Quay Operator from the OperatorHub Use the following procedure to install the Red Hat Quay Operator from the OpenShift Container Platform OperatorHub. Procedure Using the OpenShift Container Platform console, select Operators OperatorHub . In the search box, type Red Hat Quay and select the official Red Hat Quay Operator provided by Red Hat. This directs you to the Installation page, which outlines the features, prerequisites, and deployment information. Select Install . This directs you to the Operator Installation page. The following choices are available for customizing the installation: Update Channel: Choose the update channel, for example, stable-3.12 for the latest release. Installation Mode: Choose All namespaces on the cluster if you want the Red Hat Quay Operator to be available cluster-wide. It is recommended that you install the Red Hat Quay Operator cluster-wide. If you choose a single namespace, the monitoring component will not be available by default. Choose A specific namespace on the cluster if you want it deployed only within a single namespace. Approval Strategy: Choose to approve either automatic or manual updates. Automatic update strategy is recommended. Select Install .

Commands: