Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
There seems to be a race-condition when creating/enabling publishing or promoting different content view to the same environment. As a result, not all the repositories, that should be visible in the environment are really there.
The root cause of this we calculate the content ids in the cp environment in the plan phase (https://github.com/Katello/katello/blob/4d9312c8040607fcdab85d0c5a61fc76ab2a331f/app/lib/actions/katello/content_view/update_environment.rb#L24.
) and add/remove the ids according the input and write that back in the run
https://github.com/Katello/katello/blob/0e9bd2c6fa8e8387c5eee4c73eb39ca78e92b401/app/lib/actions/candlepin/environment/set_content.rb#L23-L40
Since this is not an atomic operation, in this case two concurrent actions try to do this: let's have an action UpdateEnvironment(id)
1. Action UpdateEnvironment(3), when planning, reads the list of content ids in candlepin (gets [1,2]) and plans SetContent([1,2,3])
2. Action UpdateEnvironment(4), when planning, reads the list of content ids in candlepin (gets [1,2]) and plans SetContent([1,2,4])
3. Action SetContent([1,2,3]) executes: reads the ids already in candlepin (gets [1,2]) [1,2,3] - [1,2] = [3]: adds the 3 into the ids of the cp environment; [1,2] - [1,2,3] = []: nothing to remove
4. Action SetContent([1,2,4]) executes: reads the ids already in candlepin (gets [1,2,3]) [1,2,4] - [1,2,3] = [4]: adds the 4 into the ids of the cp environment; [1,2,3] - [1,2,4] = [3]: removes the 3 from the cp environment
This logic is an artifact from the old orchestration, where there was almost imposible to get the information on what ids to add/remove at the particular orchestration.
The solution will be, instead of having the SetContent action, that takes the content ids to be in the environment), having AddContent and RemoveContent actions, that would operate on the deltas so that this race-condition is elinated.
Comment 1RHEL Program Management
2015-03-31 12:13:25 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.
Reproduced this bug on sat6.2 snap4 by simply creating 2 custom yum repositories from 2 sessions at the ~same time.
- tried more scenarios like creating the repos inside the same product and inside different products - for both i was able to reproduce the error.
one of the calls produced a SQL error, but i think it shares the same root cause:
```
ERROR org.candlepin.common.exceptions.mappers.CandlepinExceptionMapper - Runtime Error could not execute statement at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse:2,102
```
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.