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.
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.
Is there any sort of solution or workaround for this that I can add to the rel notes? thanks
The workaround is re-enabling the repository or re-promoting the content view.
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 ```
Reset docs contact <> daobrien
Created redmine issue http://projects.theforeman.org/issues/16400 from this bug
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.