Bug 1207642

Summary: Race-condition on enabling repositories or promoting to the same environment.
Product: Red Hat Satellite Reporter: Ivan Necas <inecas>
Component: RepositoriesAssignee: Ivan Necas <inecas>
Status: CLOSED WONTFIX QA Contact: Katello QA List <katello-qa-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.0.4CC: bbuckingham, cwelton, dymurray, inecas, jmatthew, jmontleo, rplevka
Target Milestone: UnspecifiedKeywords: ReleaseNotes, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-09-04 17:42:54 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:
Bug Depends On:    
Bug Blocks: 1190823, 1212602    

Description Ivan Necas 2015-03-31 11:57:01 UTC
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 1 RHEL 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.

Comment 3 David O'Brien 2015-07-31 04:03:32 UTC
Is there any sort of solution or workaround for this that I can add to the rel notes?

thanks

Comment 4 Ivan Necas 2015-07-31 08:29:55 UTC
The workaround is re-enabling the repository or re-promoting the content view.

Comment 7 Roman Plevka 2016-03-23 10:06:30 UTC
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
```

Comment 10 David O'Brien 2016-04-18 00:47:39 UTC
Reset docs contact <> daobrien

Comment 12 Brad Buckingham 2016-08-31 20:45:26 UTC
Created redmine issue http://projects.theforeman.org/issues/16400 from this bug

Comment 13 Bryan Kearney 2018-09-04 17:42:54 UTC
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.