Address other areas of docs that need change

Author: bangelic

guides/common/modules/con_host-collections-overview.adoc

@@ -4,6 +4,6 @@
 A host collection is a group of content hosts.
 
 With host collections, you can perform the same action on multiple hosts at once.
-These actions include the installation, removal, and update of packages and errata, change of assigned lifecycle environment, and change of content view.
+These actions include the installation, removal, and update of packages and errata, and the change of content view(s).
 
 For example, you can use host collections to group hosts by function, department, or business unit.

guides/common/modules/con_managing-activation-keys.adoc

@@ -13,14 +13,14 @@ The changes are not made to existing hosts.
 Activation keys can define the following properties for content hosts:
 
 * Available products and repositories
-* A lifecycle environment and a content view
+* Content view(s)
 * Host collection membership
 * System purpose
 
 .Content view conflicts between host creation and registration
 When you provision a host, {Project} uses provisioning templates and other content from the content view that you set in the host group or host settings.
-When the host is registered, the content view from the activation key overwrites the original content view from the host group or host settings.
-Then {Project} uses the content view from the activation key for every future task, for example, rebuilding a host.
+When the host is registered, the content view environment(s) from the activation key overwrite the original content view from the host group or host settings.
+Then {Project} uses the content view environment(s) from the activation key for every future task, for example, rebuilding a host.
 
 When you rebuild a host, ensure that you set the content view that you want to use in the activation key and not in the host group or host settings.
 

guides/common/modules/con_restricting-hosts-access-to-content.adoc

@@ -35,6 +35,10 @@ For more information about adding content overrides to hosts, see {ManagingHosts
 +
 For more information about adding content overrides to activation keys, see xref:enabling-and-disabling-repositories-on-activation-key_{context}[].
 
+Multiple content view environments::
+Assign hosts to multiple content view environments to provide access to content from more than one content view.
+For more information about multiple content view environments, see xref:managing-content-view-environments[].
+
 Composite content views::
 You can use composite content views to combine and give hosts access to the content from multiple content views.
 For more information about composite content views, see xref:Creating_a_Composite_Content_View_{context}[].
@@ -72,7 +76,7 @@ endif::[]
 .Incorporating all strategies
 A particular package or repository is available to a host only if all of the following are true:
 
-* The repository is included in the content view environment(s) of a host.
+* The repository is included in the content view environment(s) of the host.
 * The host's content view has been published after the repository was added to it.
 * The repository has not been filtered out by a content view filter.
 * The repository is enabled by default or overridden to *Enabled* by using a content override.
@@ -90,7 +94,7 @@ endif::[]
 Using activation keys can simplify the workflow for some of these strategies.
 You can use activation keys to perform the following actions:
 
-* Assign hosts to content views and lifecycle environments.
+* Assign hosts to content view(s).
 * Add content overrides to hosts.
 * Set system purpose attributes on hosts, including release version.
 

guides/common/modules/proc_changing-the-repository-sets-status-for-a-host-in-project.adoc

@@ -15,6 +15,6 @@ On the tab, there is a set of repositories available to each host with a status
 ====
 For hosts not in the default content view environment, the *Repository sets* tab shows a toggle group with two options, *Limit to environment* and *Show all*.
 The *Limit to environment* option shows only repositories that are relevant to the host.
-The *Show all* option shows all available repositories including those that may not be included in the content view environment(s) of a host.
+The *Show all* option shows all available repositories including those that may not be included in the content view environment(s) of the host.
 On the *Overview* tab, click *Content view details* to view the environment for the host.
 ====

guides/common/modules/proc_creating-an-activation-key.adoc

@@ -32,7 +32,6 @@ $ hammer activation-key create \
 --name "_My_Activation_Key_" \
 --unlimited-hosts \
 --description "_Example Stack in the Development Environment_" \
---lifecycle-environment "_Development_" \
 --content-view "_Stack_" \
 --organization "_My_Organization_"
 ----

guides/common/modules/proc_viewing-errata-by-applicable-and-installable.adoc

@@ -9,6 +9,6 @@ Use the following procedure to view errata by applicable or installable.
 . Click the *Overview* tab.
 Under the Errata card, there are two types of Errata.
 . Click *Applicable* to view errata that apply to a package installed on your host.
-. Click *Installable* to view applicable errata that are available in the content view environment(s) of a host.
+. Click *Installable* to view applicable errata that are available in the content view environment(s) of the host.
 . Click the link with number of errata under each type to see the list of all available errata of that type.
 . Click *security advisories*, *bug fixes*, or *enhancements* under each type to view only the respective type of errata.

guides/common/modules/ref_best-practices-for-content-views.adoc

@@ -4,7 +4,7 @@
 * Content views that bundle content, such as {client-os} and additional software like `Apache-2.4` or `PostgreSQL-16.2`, are easier to maintain.
 Content views that are too small require more maintenance.
 * If you require daily updated content, use the content view `Default Organization View`, which contains the latest synchronized content from all repositories and is available in the Library lifecycle environment.
-* Restrict composite content views to situations that require greater flexibility, for example, if you update one content view on a weekly basis and another content view on a monthly basis.
+* Restrict composite content views to situations that require greater flexibility, for example, if you update one content view weekly, another monthly, or assign hosts to multiple content view environments.
 * If you use composite content views, first publish the content views and then publish the composite content views.
 The more content views you bundle into composite content views, the more effort is needed to change or update content.
 * Setting a lifecycle environment for content views is unnecessary if they are solely bundled to a composite content view.

guides/common/modules/ref_best-practices-for-patching-content-hosts.adoc

@@ -11,5 +11,5 @@ When patching packages on hosts using the default package manager, {Project} rec
 This allows you to run commands or execute scripts on hosts.
 * When running bulk actions on hosts, bundle them by major operating system version, especially when upgrading packages.
 * Select *via remote execution {endash} customize first* to define the time when patches are applied to hosts when performing bulk actions.
-* You cannot apply errata to packages that are not part of the repositories on {Project} and the attached content view.
+* You cannot apply errata to packages that are not part of the repositories on {Project} and the attached content view(s).
 * Modifications to installed packages using `rpm` or `dpkg` are sent to {Project} with the next run of `apt`, `yum`, or `zypper`.