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

[Partha Aji]

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