notices once upon sync completion. This bug fixes makes a number of changes to how the most recent sync status is determined and stored in the database. Whenever a sync is started an object will be created in the databse to track the pulp task and be updated as the sync status is updated from pulp. Further, upon completion of a sync, a delayed job will kickoff that will generate a success or error notice and if there are errors dump the errors to the log. This change also reduces the number of calls to pulp when calculating the overall size of a product in the UI.798376 - Sync management page reworked to generate error and success notices once upon sync completion.
…ead of appending
Allows handling both "Red Hat Enterprise Linux" and "Red Hat Enterprise Linux Server" with a single configuration line.
Elasticsearch (by default) is configured to use 5 shards and 1 replica. That allows the server to grow scaling across up to 10 servers. While that is nice, it does come at the cost of some memory. We could reduce the number of shards to 1, given that our initial deployment configuration is only 1 node; however, that would not facilitate future growth/scalability. In order to strike a balance between scalability and minimize impact to memory, we are reducing the configuration to use 3 shards. Note: from some basic testing with 5 vs 3 shards, observed the following: - 3 shards : VIRT(~1650m), RES(~395m) - 5 shards : VIRT(~1720m), RES(~452m) Scenario run in both configurations before arriving at the above was: - define 2 providers (1 w/ rhel6 & 1 w/ rhel6.1) - sync both 2 times - promote both 2 times
… to load the ssl keystore - fixed thumbslug.conf to pint to /etc/pki/katello/keystore - /etc/pki/katello/keystore is owned by root.katello - user thumbslug was added to katello group
This commit makes minor changes to the usage of elasticsearch within Katello. The primary reason for these changes is to provide additional consistency across the search queries as well as provide slightly different behavior, in hopes that it'll help users. First thing users should be aware of: - They query syntax used on all pages (with a couple exceptions) is based entirely off of Lucene query syntax. - The couple of exceptions are on System Templates where a user may (from the right sliding tree) type in text to locate a repo or package name. Since those provide 'auto-complete', they don't really align with all of the other search queries in the UI. The following are a couple of key changes: 1. Provide a 'default_field' for queries that the user provides, but does not provide a term (e.g. "searchingtext" vs "name:searchtext"). The approach used for selecting the default_field is based on the context of where the query is performed. Generally, this is based on the data the user sees (e.g. provider names, user names...etc). There are several reasons for this approach; however, the key reasons were: 1. it should improve search performance (by not searching across all indexed fields by default and 2. we do not currently show the user all fields that are indexed; therefore, it could cause confusion to show matches on fields the user is not aware of. 2. Use the 'keyword' analyzer on the primary field (e.g name). This change should provide an improved behavior when data contains delimiters such as - or space. The keyword analyzer will essentially treat an entire name as a single token vs breaking it in to multiple tokens.
add "--description" option for changeset create add description to changeset list when --verbose
Otherwise there might be a conflict in promoting more templates.
Previously it was created after it was actually needed.