Race-condition on enabling repositories or promoting to the same environment.
Fixed in Releases:
Found in Releases:
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
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] = : 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] = : adds the 4 into the ids of the cp environment; [1,2,3] - [1,2,4] = : 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.