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

[Todd Sanders]

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
> 
> 
> 
> 
>> 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-devel