From a5d940d61b03de6fd17fa2dd346a7524731964f3 Mon Sep 17 00:00:00 2001 From: Pino Toscano Date: Wed, 30 Oct 2024 08:58:46 +0100 Subject: [PATCH] chore: typo fixes - "accomodate" -> "accommodate" - "accomodates" -> "accommodates" - "accomodating" -> "accommodating" - "acutally" -> "actually" - "becuase" -> "because" - "cant" -> "can't" - "certficate" -> "certificate" - "compatability" -> "compatibility" - "contining" -> "containing" - "convinience" -> "convenience" - "convinient" -> "convenient" - "defiend" -> "defined" - "dependecy" -> "dependency" - "excange" -> "exchange" - "expored" -> "exported" - "heirarchy" -> "hierarchy" - "immediatelly" -> "immediately" - "implementions" -> "implementations" - "implmentation" -> "implementation" - "informations" -> "information" - "instatiated" -> "instantiated" - "instatiation" -> "instantiation" - "manfest" / "manfiest" -> "manifest" - "manger" -> "manager" - "neesds" -> "needs" - "noticably" -> "noticeably" - "postgresSQL" -> "postgreSQL" - "relys" -> "relies" - "resoruce" -> "resource" - "retrictions" -> "restrictions" - "seperate" -> "separate" - "standlone" -> "standalone" - "struture" -> "structure" - "subcriptions" -> "subscriptions" - "succesful" / "successfull" / "sucessful" -> "successful" - "susbcription" -> "subscription" - "utitlity" -> "utility" - "wont" -> "won't" - "worfklow" -> "workflow" --- README.md | 4 ++-- docs/candlepin/amqp.md | 2 +- docs/candlepin/api_version_design.md | 2 +- docs/candlepin/artemis_jobs.md | 2 +- docs/candlepin/autoattach.md | 4 ++-- docs/candlepin/batch_binding.md | 4 ++-- docs/candlepin/caching.md | 4 ++-- docs/candlepin/constraints.md | 2 +- docs/candlepin/crl.md | 4 ++-- docs/candlepin/disable_autoattach.md | 2 +- docs/candlepin/dtos.md | 4 ++-- docs/candlepin/external_artemis_setup.md | 6 +++--- docs/candlepin/fail_fast.md | 4 ++-- docs/candlepin/glossary.md | 2 +- docs/candlepin/hibernate.md | 2 +- docs/candlepin/how_subscriptions_work.md | 4 ++-- docs/candlepin/manifest_consumer_association.md | 2 +- docs/candlepin/manifest_export.md | 4 ++-- docs/candlepin/manifest_extensions.md | 2 +- docs/candlepin/manifest_import.md | 2 +- docs/candlepin/mode_agnostic_spec_testing.md | 2 +- docs/candlepin/multi_version_products_design.md | 2 +- docs/candlepin/overview.md | 2 +- docs/candlepin/owner_hierarchy.md | 2 +- docs/candlepin/pre_entitlement_rules_check.md | 14 +++++++------- docs/candlepin/revoke_entitlements.md | 2 +- docs/candlepin/setup.md | 2 +- docs/candlepin/subscription_types.md | 2 +- docs/subscription-manager/dbus.md | 4 ++-- docs/subscription-manager/dbus_objects.md | 2 +- docs/subscription-manager/debug_http_traffic.md | 2 +- 31 files changed, 49 insertions(+), 49 deletions(-) diff --git a/README.md b/README.md index b44c6bf..05d8396 100644 --- a/README.md +++ b/README.md @@ -75,9 +75,9 @@ # Navigation In order for a page to appear on the left-hand navigation column, it needs to be listed in `_data/toc.yaml`. Use the basename of the page (e.g. 'foo' if the -page is 'foo.md') and insert it into YAML heirarchy under the appropriate +page is 'foo.md') and insert it into YAML hierarchy under the appropriate project and appropriate topic. If you forget to include your page in the -heirarchy, Jekyll will issue a warning when it is rendering the site. +hierarchy, Jekyll will issue a warning when it is rendering the site. # Deployment 1. Submit your changes as a PR. The GitHub Actions continuous integration hook diff --git a/docs/candlepin/amqp.md b/docs/candlepin/amqp.md index db0293a..c01de1c 100644 --- a/docs/candlepin/amqp.md +++ b/docs/candlepin/amqp.md @@ -157,7 +157,7 @@ If you have set up a standalone qpid server, the ssl certificate can be found in $ sudo qpid-config --ssl-certificate=path/to/cert --ssl-key path/to/key -b amqps://localhost:5671 del exchange event ``` -* Create an excange. +* Create an exchange. ```console $ sudo qpid-config --ssl-certificate=path/to/cert --ssl-key path/to/key -b amqps://localhost:5671 add exchange topic event --durable diff --git a/docs/candlepin/api_version_design.md b/docs/candlepin/api_version_design.md index 0aabd2a..810046c 100644 --- a/docs/candlepin/api_version_design.md +++ b/docs/candlepin/api_version_design.md @@ -133,7 +133,7 @@ Please add your questions and comments to the bottom with your username. it to be able to talk to _all_ versions. Candlepin, on the other hand, would need to speak to all versions of python-rhsm. * zeus: +1 new versions know how to talk to their version of candlepin. But the server needs to speak all versions (up to a point). * dgoodwin: What constitutes a new *version* of the API? Any behavioral change? Any release? Any major release? - * jbowes: if we can support minor api rev bumps that are backwards compatible (ie adding a new field onto a json struture makes the api 1.1, but 1.0 clients can still speak to it), then I'd + * jbowes: if we can support minor api rev bumps that are backwards compatible (ie adding a new field onto a json structure makes the api 1.1, but 1.0 clients can still speak to it), then I'd bump for any new feature. for major api revs, we'd bump whenever we have to make a change that old clients couldn't understand, for example a new certificate format. * dgoodwin: How do we maintain test coverage across all versions? * zeus: from a spec test perspective, this will involve adding NEW tests when we bump versions for an api method diff --git a/docs/candlepin/artemis_jobs.md b/docs/candlepin/artemis_jobs.md index 83cdeca..960600e 100644 --- a/docs/candlepin/artemis_jobs.md +++ b/docs/candlepin/artemis_jobs.md @@ -25,7 +25,7 @@ be aware: This leaves the responsibility of timing, conversion and compatibility to Satellite's upgrade process or the manual upgrade process followed for non-standard deployments (i.e. hosted). However, this sounds -worse than it acutally is: At the time of writing, both Satellite and hosted currently wait for manually +worse than it actually is: At the time of writing, both Satellite and hosted currently wait for manually executed jobs to complete before performing an upgrade, most job configurations have only changed location, not value, and the API changes have been minimized or duplicated to avoid compatibility issues where possible. diff --git a/docs/candlepin/autoattach.md b/docs/candlepin/autoattach.md index d9a60ac..2e6384c 100644 --- a/docs/candlepin/autoattach.md +++ b/docs/candlepin/autoattach.md @@ -282,7 +282,7 @@ adjusting quantity to consume, starting at the minimum increment, up to max available, until the stack is compliant. return a map of pool id to pool quantity for candlepin to interpret. -### Accomodating Guests +### Accommodating Guests When a guest attempts to Auto Attach, the host will first attempt to Auto Attach, with some significant changes: 1. The host will be handed the guests list of installed products, and attempt to Auto Attach with these @@ -303,7 +303,7 @@ Caveats: 1. The quantity the guest will need is not considered, we only attempt to get a pool available. Usually the guest just needs one. But with issues like - one sub-pool per stack, trying to add more entitlements becomes noticably + one sub-pool per stack, trying to add more entitlements becomes noticeably more difficult. diff --git a/docs/candlepin/batch_binding.md b/docs/candlepin/batch_binding.md index f92c3a0..0f86d25 100644 --- a/docs/candlepin/batch_binding.md +++ b/docs/candlepin/batch_binding.md @@ -4,7 +4,7 @@ title: Batch binding exact pools {% include toc.md %} ## Overview -* Candlepin 2.0 provides a convinience API to bind a batch of exact pools by respective quantities. This document shows the usage and example responses of that API. +* Candlepin 2.0 provides a convenience API to bind a batch of exact pools by respective quantities. This document shows the usage and example responses of that API. * Batch bind requests are asynchronous only. * The requests are atomic. If any of the pools and respective quantities requested fails for any reason ( including JavaScript validation ), the entire operation fails and none of the pools are consumed. @@ -50,7 +50,7 @@ title: Batch binding exact pools url: GET https://localhost:8443/candlepin/jobs/bind_by_pool_1cfdedb3-05aa-444a-814a-aabc5afedba4?result_data=true ``` -## Succesful Response +## Successful Response * Upon success, the `resultData` on the `JobStatus` enlists a `PoolIdAndQuantity` for each pool consumed with the respective quantity consumed ```text diff --git a/docs/candlepin/caching.md b/docs/candlepin/caching.md index 17e3e7f..5942fb2 100644 --- a/docs/candlepin/caching.md +++ b/docs/candlepin/caching.md @@ -89,7 +89,7 @@ In Candlepin, we mainly cache `Product`/`Content` entities and all the collectio Very simplified view of when Hibernate uses 2LC can be summarized as follows: * When entity is looked up by its `Id` column - * When entity is defiend as ManyToOne attribute and isn't referenced in the query (when the attribute is referenced in the query, Hibernate will usually issue a Sql Join to load the attribute value) + * When entity is defined as ManyToOne attribute and isn't referenced in the query (when the attribute is referenced in the query, Hibernate will usually issue a Sql Join to load the attribute value) * When persistent collection is cached (`Cache` annotation on the collection), the entities in that collection will be loaded from 2LC * A query is cached and the results are cached entities - this is quite obvious * When using old Hibernate Criteria - this is a bit odd, but when using old Hibernate Criteria, Hibernate is sometimes less proactive doing Sql Joins and instead it is loading associated relationship using separate selects. Which means you may get more cache hits @@ -149,7 +149,7 @@ Even though `Product` is not taken from cache here, we are still getting benefit * Query for `OwnerProduct` entity and set `OwnerProduct.product` as EAGER with Fetch style SELECT * Query for `OwnerProduct` entity and then manually query for `Product` using its UUID -Lets discuss the first option. Becuase we set `OwnerProduct.product` to LAZY, Hibernate is not going to join when we execute the query. Then, because `OwnerProduct.product` is a relationship that retrieves just one Product, Hibernate will utilize 2LC. The code might look like this: +Lets discuss the first option. Because we set `OwnerProduct.product` to LAZY, Hibernate is not going to join when we execute the query. Then, because `OwnerProduct.product` is a relationship that retrieves just one Product, Hibernate will utilize 2LC. The code might look like this: ``` public Product getProductByIdJpql(String ownerId, String productId) { diff --git a/docs/candlepin/constraints.md b/docs/candlepin/constraints.md index 8b5ed1f..1b7fa74 100644 --- a/docs/candlepin/constraints.md +++ b/docs/candlepin/constraints.md @@ -60,6 +60,6 @@ Could be based on unit of time, cpu cycles, any other criteria accessible. Draw down is probably best used for things like training. Here is a set number of hours or usage period. Once you have used it up, there is no more. -## Cloud Subcriptions +## Cloud Subscriptions Similar to quantity based, but the consumers are potentially shorted lived. This is similar to "Concurrent users" as a licensing model. diff --git a/docs/candlepin/crl.md b/docs/candlepin/crl.md index 8bdb16b..ca7b52f 100644 --- a/docs/candlepin/crl.md +++ b/docs/candlepin/crl.md @@ -184,7 +184,7 @@ performed when the caller first constructs the streaming reader: `seqLength` (the length of the *revokedCertificates* sequence). 5. We are now within the *revokedCertificates* sequence. -With the preliminary operations complete, we return the instatiated reader and +With the preliminary operations complete, we return the instantiated reader and the caller can begin streaming sequences within *revokedCertificates* using the `next` method. This method returns one revoked certificate sequence each time it is called. @@ -213,7 +213,7 @@ The caller would need to pass in some type of memo object to the streaming reader when the reader is instantiated. As the reader moves through the meta-data items in the *tbsCertList* during initialization, it would simply populate the memo object with the values. The caller could then look in the -memo object once the reader has finished instatiation. +memo object once the reader has finished instantiation. Signature verification is more complex. Since the signature algorithm used is required for the verification process and the algorithm information is towards diff --git a/docs/candlepin/disable_autoattach.md b/docs/candlepin/disable_autoattach.md index da116cf..980fcbf 100644 --- a/docs/candlepin/disable_autoattach.md +++ b/docs/candlepin/disable_autoattach.md @@ -6,7 +6,7 @@ title: Disabling Auto Attach # Disabling Auto Attach For An Owner _This feature is available in both candlepin-0.9.54.11+ and candlepin-2.0.20+_ -Candlepin allows disabling the Auto Attach functionality, on a per Owner basis, to accomodate entitlement stability +Candlepin allows disabling the Auto Attach functionality, on a per Owner basis, to accommodate entitlement stability for Consumers of an Owner/Organisation during subscription renewals and/or other maintenance. In many circumstances, Candlepin's Auto Attach functionality is not the greatest at selecting the most diff --git a/docs/candlepin/dtos.md b/docs/candlepin/dtos.md index b9c4cef..f2be3d1 100644 --- a/docs/candlepin/dtos.md +++ b/docs/candlepin/dtos.md @@ -107,7 +107,7 @@ Direct instantiation: this.modelTranslator = new StandardTranslator(...); ``` -Dependecy injection: +Dependency injection: ``` @Inject public MyResource(ModelTranslator modelTranslator) { @@ -197,7 +197,7 @@ Similarly, the populate methods take a source object and a destination object, a object with data from the source object. Both methods have a overloaded definition which also accepts a model translator which can be used to translate nested objects within the source object. -The overlapping nature of the translate and populate operations allows most object translator implementions to +The overlapping nature of the translate and populate operations allows most object translator implementations to simply chain the translate operation into the populate operation rather than duplicate code. For example: ``` diff --git a/docs/candlepin/external_artemis_setup.md b/docs/candlepin/external_artemis_setup.md index 07c7101..b00396c 100644 --- a/docs/candlepin/external_artemis_setup.md +++ b/docs/candlepin/external_artemis_setup.md @@ -4,7 +4,7 @@ title: Configuring A Remote Artemis Server {% include toc.md %} # Configuring A Remote Artemis Server -By default, candlepin runs with an embedded Artemis server. Candlepin does however support running against a remote Artemis server. The following guide will walk you through installing a remote Artemis server with basic configuration. Because candlepin relys on very specific queues and addresses, it is not advised to mess with these configuration settings. +By default, candlepin runs with an embedded Artemis server. Candlepin does however support running against a remote Artemis server. The following guide will walk you through installing a remote Artemis server with basic configuration. Because candlepin relies on very specific queues and addresses, it is not advised to mess with these configuration settings. ## Installing Artemis First, stop tomcat so that the embedded Artemis instance is shut down to avoid port conflicts. @@ -52,7 +52,7 @@ sudo useradd artemis --home /var/lib/artemis sudo chown -R artemis:artemis /var/lib/artemis ``` -Setup an SELinux policy for the artemis service. In a temp directory, create an ***artemisservice.te*** file contining the following. +Setup an SELinux policy for the artemis service. In a temp directory, create an ***artemisservice.te*** file containing the following. ```bash module artemisservice 1.0; @@ -107,7 +107,7 @@ sudo systemctl start artemis sudo systemctl status artemis ``` -In a seperate terminal, tail and grep the logs to make sure that candlepin is running against the remote Artemis server when it starts. +In a separate terminal, tail and grep the logs to make sure that candlepin is running against the remote Artemis server when it starts. ```bash tail -f /var/log/candlepin/candlepin.log | grep "Candlepin will connect" diff --git a/docs/candlepin/fail_fast.md b/docs/candlepin/fail_fast.md index 7687fb6..30a2e45 100644 --- a/docs/candlepin/fail_fast.md +++ b/docs/candlepin/fail_fast.md @@ -12,7 +12,7 @@ Fail Fast mechanism is a set of defensive measures that Candlepin automatically Fail Fast mechanism currently defends against problems with Qpid Broker. It uses feature called Suspend Mode to temporarily stop Candlepin's operations. ## Suspend Mode -Candlepin can operate in two modes: NORMAL mode and SUSPEND mode. The NORMAL corresponds to standard Candlepin operation. SUSPEND mode is a state in which Candlepin stops responding to most of the requests. When in SUSPEND mode, Candlepin will return HTTP code 503. Also, all the scheduled jobs are suspended. The only available resoruce is `/status` endpoint. Thus, when in SUSPEND mode, clients cannot use Candlepin. The current mode of Candlepin can be discovered using `/status` endpoint. It is recommended that this endpoint is used for polling the Candlepin mode. +Candlepin can operate in two modes: NORMAL mode and SUSPEND mode. The NORMAL corresponds to standard Candlepin operation. SUSPEND mode is a state in which Candlepin stops responding to most of the requests. When in SUSPEND mode, Candlepin will return HTTP code 503. Also, all the scheduled jobs are suspended. The only available resource is `/status` endpoint. Thus, when in SUSPEND mode, clients cannot use Candlepin. The current mode of Candlepin can be discovered using `/status` endpoint. It is recommended that this endpoint is used for polling the Candlepin mode. The feature is enabled by default and can be controlled using config property `candlepin.suspend_mode_enabled` @@ -55,4 +55,4 @@ The spec tests assume existence of special queue. To create it, it is necessary Qpid Management Framework is proprietary Qpid, message base, protocol. It is used to manage Qpid Broker and also to retrieve information about the broker. Candlepin uses QMF (implementation in `QpidQmf.java`) in order to figure out whether an exchange is flow stopped. ### Startup Check -At the startup of Candlepin, Qpid QMF is used to check for the connectivity to the broker. If it is not CONNECTED, then Candlepin immediatelly fails and stops the startup. This behavior can be controlled by property `candlepin.amqp.qmf.startup_check_enabled` +At the startup of Candlepin, Qpid QMF is used to check for the connectivity to the broker. If it is not CONNECTED, then Candlepin immediately fails and stops the startup. This behavior can be controlled by property `candlepin.amqp.qmf.startup_check_enabled` diff --git a/docs/candlepin/glossary.md b/docs/candlepin/glossary.md index 94ea546..6b22601 100644 --- a/docs/candlepin/glossary.md +++ b/docs/candlepin/glossary.md @@ -29,7 +29,7 @@ Entitlement Pool You will also see the other terms used throughout the wiki Entitlement Certificate -: By default, an x.509 certficate which represents you right to consume a subscription. This certificate can be used to access software. +: By default, an x.509 certificate which represents you right to consume a subscription. This certificate can be used to access software. Identity Certificate : By default, an x.509 certificate which unique identifies a single consumer. diff --git a/docs/candlepin/hibernate.md b/docs/candlepin/hibernate.md index a2a44f2..0988902 100644 --- a/docs/candlepin/hibernate.md +++ b/docs/candlepin/hibernate.md @@ -197,7 +197,7 @@ So the complete test method now looks like this: ``` {:.numbered} -Given the refresh on line 09, you would expect the code will pass. It wont. Instead you will get [0] again. Now the problem why this code doesn't work is much more intricate. The implementation of on createEntitlement (our standard functional test prepare method) on line 6 is: +Given the refresh on line 09, you would expect the code will pass. It won't. Instead you will get [0] again. Now the problem why this code doesn't work is much more intricate. The implementation of on createEntitlement (our standard functional test prepare method) on line 6 is: [6] diff --git a/docs/candlepin/how_subscriptions_work.md b/docs/candlepin/how_subscriptions_work.md index 346ace4..d94ee69 100644 --- a/docs/candlepin/how_subscriptions_work.md +++ b/docs/candlepin/how_subscriptions_work.md @@ -79,7 +79,7 @@ When a subscription object is imported, depending on the attributes of its main #### Derived Products -Pools can also carry a "derived" product and provided products. This accomodates scenarios where the host is intended to get access to different (or no) content than the guests. The parent or primary pool will use the normal product and provided products on the subscription. However any derived or unmapped guest pools will flip to use the derived product and provided products instead of the normal set. +Pools can also carry a "derived" product and provided products. This accommodates scenarios where the host is intended to get access to different (or no) content than the guests. The parent or primary pool will use the normal product and provided products on the subscription. However any derived or unmapped guest pools will flip to use the derived product and provided products instead of the normal set. ## Entitlements @@ -106,7 +106,7 @@ Pools can also carry a "derived" product and provided products. This accomodates ## Exporting Subscriptions to a Downstream Candlepin Server -Candlepin has been designed to allow for exporting subscriptions from a main/upstream Candlepin server for use in a standlone on-premises environment. (i.e. Katello, Satellite, SAM) This process involves a number of steps: +Candlepin has been designed to allow for exporting subscriptions from a main/upstream Candlepin server for use in a standalone on-premises environment. (i.e. Katello, Satellite, SAM) This process involves a number of steps: 1. A "distributor" consumer is created in the upstream candlepin server by some UI. (also sometimes referred to as a "Subscription Management Application") 1. A user assigns entitlements to the distributor consumer for export in whatever quantities they wish to use downstream. Once assigned those are marked as consumed in the upstream server. diff --git a/docs/candlepin/manifest_consumer_association.md b/docs/candlepin/manifest_consumer_association.md index 8a9b298..57e31b5 100644 --- a/docs/candlepin/manifest_consumer_association.md +++ b/docs/candlepin/manifest_consumer_association.md @@ -4,7 +4,7 @@ title: Manifest Consumer Association {% include toc.md %} # Manifest Consumer Association Design -Katello neesds the ability to associate a given manifest with the distributor (consumer). The following information needs to be accessible. +Katello needs the ability to associate a given manifest with the distributor (consumer). The following information needs to be accessible. * consumer uuid * consumer id cert pub/priv pair diff --git a/docs/candlepin/manifest_export.md b/docs/candlepin/manifest_export.md index 6376654..68f5b49 100644 --- a/docs/candlepin/manifest_export.md +++ b/docs/candlepin/manifest_export.md @@ -5,7 +5,7 @@ title: Exporting A Manifest # Exporting A Manifest -In order for a consumer to be exported, it must be manfest enabled. We refer to this type of consumer as a distributor. A consumer is considered to be a distributor if its ConsumerType defines 'manifest':true. Any entitlements attached to a distributor will be included in the manifest when it is exported. +In order for a consumer to be exported, it must be manifest enabled. We refer to this type of consumer as a distributor. A consumer is considered to be a distributor if its ConsumerType defines 'manifest':true. Any entitlements attached to a distributor will be included in the manifest when it is exported. To export a manifest for a distributor, you use the [GET /consumers/:uuid/export/async]({{ site.url }}/swagger/?url=candlepin/swagger-2.0.13.json#!/owners/exportDataAsync){:target="_blank"} API. When the export request is made, candlepin will start an asynchronous job that will perform the export. When the job is complete, the job status will provide the details of how the export can be obtained using the [GET /consumers/:uuid/export/:export_id]({{ site.url }}/swagger/?url=candlepin/swagger-2.0.13.json#!/owners/downloadExistingExport){:target="_blank"} API. @@ -76,7 +76,7 @@ A manifest file contains all of the data from the upstream candlepin required to Extracting a manifest file yields: -- **consumer_export.zip:** An archive of the expored consumer data. +- **consumer_export.zip:** An archive of the exported consumer data. - **signature:** The signature for the consumer_export.zip file. The contents of the consumer_export.zip file are as follows: diff --git a/docs/candlepin/manifest_extensions.md b/docs/candlepin/manifest_extensions.md index 6cd0a2b..26115b4 100644 --- a/docs/candlepin/manifest_extensions.md +++ b/docs/candlepin/manifest_extensions.md @@ -59,7 +59,7 @@ package org.candlepin.example; import com.google.inject.AbstractModule; /** - * When overriding service implmentation, a custom guice module must be created. In this + * When overriding service implementation, a custom guice module must be created. In this * example, we simply bind the ExportExtensionAdapter interface to our custom extension * adapter class so that candlepin will inject our adapter whenever the interface is * injected. diff --git a/docs/candlepin/manifest_import.md b/docs/candlepin/manifest_import.md index 6353b99..4abb2af 100644 --- a/docs/candlepin/manifest_import.md +++ b/docs/candlepin/manifest_import.md @@ -57,7 +57,7 @@ $ curl -k -X POST -F "application/zip=@1dc9d30a-cb39-4155-8789-c6efb0061b42-expo } # Monitor the job status to see when the job has completed -# and if it was successfull. +# and if it was successful. $ curl -k -u USERNAME:PASSWORD https://localhost:8443/candlepin/jobs/import_8b018fd9-679a-4e2e-8704-2eac757b35a8?result_data=true { "id" : "import_8b018fd9-679a-4e2e-8704-2eac757b35a8", diff --git a/docs/candlepin/mode_agnostic_spec_testing.md b/docs/candlepin/mode_agnostic_spec_testing.md index f2551fc..194a5de 100644 --- a/docs/candlepin/mode_agnostic_spec_testing.md +++ b/docs/candlepin/mode_agnostic_spec_testing.md @@ -26,7 +26,7 @@ One of the ways that the two modes differ is in the manner by which pools are cr ## How to test in hosted mode -* The most convinient way to deploy candlepin in hosted mode is to simply use the deploy script: +* The most convenient way to deploy candlepin in hosted mode is to simply use the deploy script: ```console $ ./server/bin/deploy -Ha diff --git a/docs/candlepin/multi_version_products_design.md b/docs/candlepin/multi_version_products_design.md index 52ac4a6..e0a93f1 100644 --- a/docs/candlepin/multi_version_products_design.md +++ b/docs/candlepin/multi_version_products_design.md @@ -26,7 +26,7 @@ Soon it will be possible to have multiple versions of the same product installed cert.write(filename) * Prevent duplicates from getting written. (probably helped by pushing the write logic into `ProductDirectory`) - * Handle backward compatability, likely by having `ProductDirectory` do a + * Handle backward compatibility, likely by having `ProductDirectory` do a quick check on load for old filenames and if any are found, write them in the new fashion. * Examine usage of certificate directory findByProduct vs findAllByProduct. diff --git a/docs/candlepin/overview.md b/docs/candlepin/overview.md index b3acc19..21d0100 100644 --- a/docs/candlepin/overview.md +++ b/docs/candlepin/overview.md @@ -78,7 +78,7 @@ Clients (called consumers) go through the following standard lifecycle: 1. Clients register with candlepin. They are given identity certificates which contain their UUID. This identity certificate can be used for future communication. 1. Clients can search for pools of subscriptions. -1. Clients consume susbcription(s). This is also called binding to a subscription or creating an entitlement. This results in entitlement certificates being provided to the client. +1. Clients consume subscription(s). This is also called binding to a subscription or creating an entitlement. This results in entitlement certificates being provided to the client. 1. Clients can retrieve updated certificates to handle cases where data has changed server side. 1. Clients can unbind, or stop consuming certificates. 1. Clients can unregister, or delete themselves from the system. diff --git a/docs/candlepin/owner_hierarchy.md b/docs/candlepin/owner_hierarchy.md index 209244b..0a0cc9c 100644 --- a/docs/candlepin/owner_hierarchy.md +++ b/docs/candlepin/owner_hierarchy.md @@ -47,7 +47,7 @@ title: Owner Hierarchy This was the first option to come to mind but I think it quickly begins to look infeasible and messy. For one, much of the data in an export is already there (products / consumer types / rules), only the Entitlement importer would be -re-usable. If so, then the process would become an upstream subscription +reusable. If so, then the process would become an upstream subscription becomes an upstream pool, an on-site Candlepin is deployed and registered as an upstream consumer, who then binds and obtains entitlments with a quantity. The export is generated and then imported on-site, those entitlements now translate diff --git a/docs/candlepin/pre_entitlement_rules_check.md b/docs/candlepin/pre_entitlement_rules_check.md index 21f88cd..fe5fd31 100644 --- a/docs/candlepin/pre_entitlement_rules_check.md +++ b/docs/candlepin/pre_entitlement_rules_check.md @@ -13,20 +13,20 @@ The following are the checks candlepin performs based on consumer facts and pool * if required consumer type is not specified, consumer type should be either system or hypervisor. * if the pool is restricted to username, ensure it matches the request * **do_pre_virt_only**: - * manifests cant consume virt pools if they are also pool_derived. - * non guests and non manifests cant consume virt pools. + * manifests can't consume virt pools if they are also pool_derived. + * non guests and non manifests can't consume virt pools. * **do_pre_physical_only**: - * guests ( unless they are distributors ) cant consume physical only pools + * guests ( unless they are distributors ) can't consume physical only pools * **do_pre_unmapped_guests_only**: * virtual guests cannot use unmapped guest pool if we know which host it belongs to. * virtual guests cannot use unmapped guest pool if they are new newly registered. * virtual guests cannot bind future unmapped guest pools * **do_pre_requires_host**: - * manifests cant consume required_host pools + * manifests can't consume required_host pools * if consumer does not have a virt.uuid fact, and the pool has a requires_host, do not allow bind. * the pool owner must match the host of the virtual guest ( identified by the requires_host pool attribute ). * **do_pre_requires_consumer**: - * manifests cant consume required_consumer pools + * manifests can't consume required_consumer pools * the pool owner must match the consumer uuid (identified by the requires_consumer pool attribute). * **do_pre_requires_consumer_type**: * if a consumer_type attribute is on the pool, ensure it matches that of the consumer requesting the bind @@ -38,7 +38,7 @@ The following are the checks candlepin performs based on consumer facts and pool * for non manifests and non guests, if consumer has a socket fact and pool is not stacked, ensure the pool provides enough sockets. * **do_pre_cores**: * for non manifest non guests, if consumers has a cores fact, and pool is not stacked, ensure consumer has enough cores. - * for manifest consumers, make sure manfiest consumer has cores capability. + * for manifest consumers, make sure manifest consumer has cores capability. * **do_pre_ram**: * for non manifests, if pool is non stacking, ensure pool has enough ram. * for manifests, ensure manifest has ram capability @@ -47,4 +47,4 @@ The following are the checks candlepin performs based on consumer facts and pool * for manifests, ensure manifest has storage capability * **do_pre_instance_multiplier**: * for non manifests, non guests, for direct binds, verify quantity is divisible by pool's instance multiplier. - * verify manfest consumers have instance multiplier capability. + * verify manifest consumers have instance multiplier capability. diff --git a/docs/candlepin/revoke_entitlements.md b/docs/candlepin/revoke_entitlements.md index b0ef3a9..c9038d8 100644 --- a/docs/candlepin/revoke_entitlements.md +++ b/docs/candlepin/revoke_entitlements.md @@ -13,7 +13,7 @@ Revoking an entitlement is an operation that will remove an entitlement from its The revocation must ensure that other database objects such as associated Pool quantities are updated. Revocation might also trigger removal of other Entitlements and deletion of other pools. -## Revocation Worfklow +## Revocation Workflow The following diagram shows highlevel steps that need to take place during the revocation of a set of entitlements. diff --git a/docs/candlepin/setup.md b/docs/candlepin/setup.md index 44d2842..e98414b 100644 --- a/docs/candlepin/setup.md +++ b/docs/candlepin/setup.md @@ -15,7 +15,7 @@ The following instructions assume use of RHEL/Fedora (tested on EL5/6 and Fedora # PostgreSQL -1. Install PostgresSQL. +1. Install PostgreSQL. ```console $ sudo yum install -y postgresql-server postgresql diff --git a/docs/candlepin/subscription_types.md b/docs/candlepin/subscription_types.md index f4808fc..8687501 100644 --- a/docs/candlepin/subscription_types.md +++ b/docs/candlepin/subscription_types.md @@ -32,7 +32,7 @@ Example: * virt_limit: 4 / unlimited -When a physical host consumes a virt_limit subscription, a sub-pool is created that is only visible/usable by guests who are running on that host. The virt-who utitlity is typically what reports the host/guest mapping information and allows this functionality to work. Revoking the physical host entitlement will result in revoking the sub-pool and all its existing entitlements. +When a physical host consumes a virt_limit subscription, a sub-pool is created that is only visible/usable by guests who are running on that host. The virt-who utility is typically what reports the host/guest mapping information and allows this functionality to work. Revoking the physical host entitlement will result in revoking the sub-pool and all its existing entitlements. Note that guests can still consume the main pool, provided the product does not also carry the physical_only attribute. diff --git a/docs/subscription-manager/dbus.md b/docs/subscription-manager/dbus.md index 646648a..1862143 100644 --- a/docs/subscription-manager/dbus.md +++ b/docs/subscription-manager/dbus.md @@ -5,7 +5,7 @@ title: D-Bus use in Subscription Manager # D-Bus -Subscription Manger creates D-Bus messages when the entitlement status changes. +Subscription Manager creates D-Bus messages when the entitlement status changes. ## Signals @@ -123,4 +123,4 @@ Entitlement Status employs the standard Properties interface methods: def GetAll(self, interface_name): ``` -As the available information is read-only, no other access retrictions have been implemented. If the capabilities are expanded in the future to include system manipulation, then access control will be added. +As the available information is read-only, no other access restrictions have been implemented. If the capabilities are expanded in the future to include system manipulation, then access control will be added. diff --git a/docs/subscription-manager/dbus_objects.md b/docs/subscription-manager/dbus_objects.md index 5874437..7618057 100644 --- a/docs/subscription-manager/dbus_objects.md +++ b/docs/subscription-manager/dbus_objects.md @@ -310,7 +310,7 @@ creates. * `proxy_password` The call returns the JSON response body from the subscription management - server. Example of JSON document returned after sucessful registration: + server. Example of JSON document returned after successful registration: ```json { diff --git a/docs/subscription-manager/debug_http_traffic.md b/docs/subscription-manager/debug_http_traffic.md index 26f37f1..879abe5 100644 --- a/docs/subscription-manager/debug_http_traffic.md +++ b/docs/subscription-manager/debug_http_traffic.md @@ -22,7 +22,7 @@ Every RHSM application using `rhsm` Python package can set following environment * `SUBMAN_DEBUG_PRINT_RESPONSE` * `SUBMAN_DEBUG_TCP_IP` -When you set these environment variables (`1`, `true`, ...), the client application using rhsm module will start to print informations to standard output about HTTP requests. Subscription-manager currently considers all non-empty variables as `True`, but that may change in the future. We recommend unsetting these variables by passing empty string or by deleting the variable from the environment completely. +When you set these environment variables (`1`, `true`, ...), the client application using rhsm module will start to print information to standard output about HTTP requests. Subscription-manager currently considers all non-empty variables as `True`, but that may change in the future. We recommend unsetting these variables by passing empty string or by deleting the variable from the environment completely. NOTE: This debugging functionality was introduced in RHEL8.3 in subscription-manager-1.27.11-1.