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

[Cliff Perry]

On 05/31/2011 07:09 PM, Todd Sanders wrote:
>
>
> On May 31, 2011, at 6:54 PM, Mike McCune<mmccune at redhat.com>  wrote:
>
>> 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
>>
>> _______________________________________________
>> katello-devel mailing list
>> katello-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/katello-
>
> I would actually prefer option 2.  I don't think since we are supporting multiple change sets, locking would be limiting. Users shouldn't need to edit change sets simultaneously. We do need to present the userid and name of the person currently editing.  Polling doesn't scale well.
>
> -Todd
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
What about something where who does a submit first wins. When user 2 
submits he is informed of other changes made, a diff of some sort 
displayed and prompted to remedy before they can proceed to submit.

Visual UI indicator that someone else is editing changeset should also 
be there, akin to a soft lock/warning vs hard only one person can be in 
a edit mode at a time.

Cliff