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

[Mike McCune]

On 05/31/2011 04:13 PM, Todd Sanders wrote:
> Another reason for choosing the locking approach.
>
> -Todd
>
> Sent from my iPhone
>
> On May 31, 2011, at 7:07 PM, Partha Aji<paji at redhat.com>  wrote:
>
>>
>>
>> ----- Original Message -----
>>> From: "Mike McCune"<mmccune at redhat.com>
>>> To: "Partha Aji"<paji at redhat.com>
>>> Cc: katello-devel at redhat.com
>>> Sent: Tuesday, May 31, 2011 6:54:02 PM
>>> Subject: Re: [katello-devel] Approaches on Changeset Manipulation by multiple users
>>> 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.
>>>
>>>
>> One thing I hadn't thought of in the polling case was when will "promote" be acceptable.
>> As in
>> User A ->  Updates Changeset C
>> User B ->  updates the same
>> Now user A hits promote before the polling interval.
>>
>> So if we added the smarts to do a check here, the behaviour should be
>> "User A - Your changeset has been updated by some one else. Reloading the changeset. Click promote again if you happy with it."
>>
>> Now when User A is happy and clicks "promote", User B needs to know that the changeset has been promoted already. This is a kind of oddity. Have to think of how to solve this one next I guess.
>>
>> Partha
>>

I talked to Todd on the phone for a bit and I'm now leaning towards a 
locking mechanism so each user is aware someone else is editing the 
changeset and can't step on each other's changes.

The thought was we would have buttons to lock or unlock a changeset for 
editing or at least some mechanism to manage the changes to the changeset.

Partha, can you setup a meeting tomorrow so we can finalize some 
solutions for this issue?

Mike