Bug 1104351
| Summary: | pulp node metadata generation (for capsule sync) should be asynchronous to publish/promote | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Erik M Jacobs <ejacobs> |
| Component: | Content Management | Assignee: | Justin Sherrill <jsherril> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Corey Welton <cwelton> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.0.3 | CC: | cwelton, inecas, jmontleo, jsherril, mdavis, mmccune, omaciel |
| Target Milestone: | Unspecified | Keywords: | Regression, Triaged |
| Target Release: | Unused | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://projects.theforeman.org/issues/6051 | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-07-02 14:08:30 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Erik M Jacobs
2014-06-03 19:40:03 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release. Created redmine issue http://projects.theforeman.org/issues/6051 from this bug The question is: let's say I have a lifecycle environment assigned to a capsule? Should I be told that the promotion was finished, when the capsule still does not have the content? It would look very strange to me. We could however do the the node metadata generation as part of the sync to capsule process, instead of doing every time, which would avoid doing that if there is no capsule in use at all, and would be done only for lifecycle environments that are assigned to some capsule. The UI should indicate the current status of all capsules from a content perspective. There is another "question" that arises out of this -- If you are not using the default installation and you have a capsule outside of your Satellite, but only that one capsule, at what point is the publish/promotion "finished"? The bottom line here, I suppose, is that publishing/promoting takes entirely too long for a large repo like 6Server without providing any real feedback on what is going on. On decently fast hardware (SATA drives, fast CPU) it takes an average of 16-30 minutes to publish/promote a change to 6Server. If there was more status being presented to the user in the UI (percentages, estimated time to completion, what's actually happening, etc), longer times might be tolerable. But, right now, a publish/promote gets to about 99% complete as indicated by the bar in the UI, and then nothing happens for anywhere from 5-10 minutes. The steps that we can do to make it better are: 1. Doing the capsule-related tasks only when the capsule is relevant to the promotion 2. to play more with tuning the substasks weights (the support is already there), to provide better percentages. 3. provide more description on the progress of the task: should be not hard to do, we already do something similar when syncing the repositories 4. provide more detail on the content status on the capsule: it also might be optional to automatically sync the content to the capsule if the user prefers to have control over the synchronization of the capsule. 1. We could do this, we'd just have to delay the metadata generation until a node syncs. What happens if two nodes try to sync around the same time? Would both queue up a metadata generation, or would the 2nd wait for the generation initiated by the 1st capsule? What about: 5. For a content view, have it opt in to being placed on a capsule. It would default to no, but as soon as you 'check' the box, it would initiate a node metadata generation and sync to all the applicable nodes. Afterwards any publish/promotion would include the metadata generation step (and thus take longer) 6. We still do the metadata generation (and sync) as a 2nd task, but display it in the UI (somehow) as tracked separately on the versions page. It would then no longer block promotions. or we could do 2 & 3 & 4 & 5 & 6, as they would all go well together. Previously we made it async not just because it took a long time, but also because it blocked promotions from occuring (kept the user from continuing). 1. Good point, is it possible to ask Pulp about the tasks running against some repo, finding out if the task is not already running and if so, instead of initiating new one, just wait for it? If not, we could still dig the info out from foreman-tasks/dynflow. 5. maybe recommanding not to attach library to external capsule (due to slowing down the process) might be enough: people should be aware what does it mean to have a capsule attached to a lifecycle environment. But yeah, we could have this additional flag. Meybe having possibility to do the final decision about what capsule should be used when publishing/promoting. 6. better with it than without it, if we decide to go the async way Moving to POST since upstream bug http://projects.theforeman.org/issues/6051 has been closed This seems to be ok. Added some content to a view and published/promoted, things seem to be ok with nodes. Satellite-6.0.3-RHEL-7-20140612.1 Verified. This was delivered with 6.0.3, which is the Satellite 6 Beta. This was delivered in 6.0.3, the Beta version of Satellite 6.0 |