[katello-devel] Approaches on Changeset Manipulation by multiple users

[Mike McCune]

On 05/31/2011 02:25 PM, Partha Aji wrote:
> Justin and I have been looking for a method for enabling multiple users manipulate/update the same changeset simultaneously before promoting it to the next environment. Main issue here is that the updates made to the changeset should be transparent to both users. Before promotion they should exactly know what is getting promoted. Problem here is that when 2 users are updating the changeset at the same time or the same user has the same page opened in 2 browser windows and clicks promote, the last change wins. So to remedy this 2 approaches were suggested
>
> 1) Polling based approach. Here, every 2 or 3 seconds a check will be made to the server asking if the changeset changed at the server (similar to how notifications behave) and the changset UI will auto refresh if it changed. I guess the User will be given some notice saying "the changeset has been changed, refreshing your promotion tree and changset contents..."
>
> 2) Locking based approach. Only one user can change the changeset at a time. So user kinda acquires a lock on changeset and modifies it and unlocks it or unlocks on time out so that some other user can work on it. Before deciding to promote.
>
>
> Pros of approach 1
> Multiple users can update a changeset and be aware of changes happening actively.
>
> Cons
> It can be an annoying experience with contents you just changed automatically getting refreshed/overwritten with the updated stuff. The hard part from the coding perspective will be reconciling the changes you made with the changes in the updated changeset.
>
> Pros of approach 2
> No reconciling business as simultaneous updates on a changeset are forbidden.
>
> Cons
> When will the changeset lock get released. What happens if a user stays on the same changeset forever and wont allow others to update or promote. Locking/Unlocking has to be worked out from the coding perspective. We'd have to be cognizant of the fact that the same user may be updating the changeset from 2 different browsers (should we allow that or not ...).
>
> I prefer 1 for the simple reason it makes best use of the model based changes justin has made so that changeset can be updated by multiple users and also that we have methods to do polling :)... It also allows for User with permission to product A and user with permissions product B simultaneously update the changeset..
>
>
> Thoughts ??

I think locking it down to single user access would be prohibitively 
annoying for an end user.  We should implement a polling mechanism but I 
wouldn't do it as often as 2-3 seconds, I'd increase it to something 
like 60-120 seconds to reduce the load on the Katello server.  2-3 
second polling is a bit much even if the API call is very minimal. That 
could scale to be something pretty bad if you have hundreds or thousands 
of users on the site.


Mike
-- 
Mike McCune
mmccune AT redhat.com
Red Hat Engineering       | Portland, OR
Systems Management        | 650.254.4248