[katello-devel] Proposed change to meaning of an environment's "current changeset"

[Justin Sherrill]

On 05/18/2011 11:34 AM, Bryan Kearney wrote:
> On 05/18/2011 11:12 AM, Justin Sherrill wrote:
>> Hi,
>>
>> So currently an environment has a changeset (KPEnvironment#changeset)
>> and a changeset history (KPEnvironment#changeset_history).
>>
>> Say we have environments A->B->C
>>
>> Currently the meaning of B.changeset is the set of content that will be
>> promoted FROM B TO C. That is when you promote the changeset in B
>> everything is added to C.
>>
>>
>> I'm proposing a change to make it so that B.changeset is actually the
>> content that will be promoted FROM A to B. To me it makes more sense
>> logically as B.changeset is the changeset for B, not for C.
>>
>> This really comes into play with multiple paths, as currently the Locker
>> only has 1 changeset for an environment. So it doesn't really work if
>> you can promote from locker to multiple places. That is:
>>
>> Locker -> A
>> Locker -> B
>>
>> Today, we only have Locker.changeset, so the same changeset used when
>> deciding what content should be promoted to A or to B doesn't really
>> make any sense.
>>
>
> Why does this not make sense? If my changeset is "Latest RHEL" I could 
> see wanting to move it to both A and B.
>
> Is hte issue that we are getting too fancy looking into the next 
> environemnt to see what to move? If so, I would be willing to hold 
> back on that stuff.
>
> -- bk

That could make sense, but the current promotion UI is not really 
designed around that.  We had discussed re-using changesets as well, so 
you could 'copy' a changeset to allow you to re-use them when promoting 
through a path.  No reason you couldn't reuse them across paths.

To me it doesn't make sense to have Locker only have a single changeset, 
because say Admin1 goes and prepares a changeset for Environment A but 
waits to promote it,  admin 1 (or any other user) can't prepare another 
changeset for B until the first one is promoted.   For that one case 
where a user would want to promote a changeset into 2 environments, he 
could copy as i mention above, or we could incorporate the copy into the 
promotion process, so he'd still be promoting to two environments, it 
would just be copying the changeset and promoting for B as well in a 
single step (so this change does not preclude your use case necessarily).

We also don't allow you to select some content for a changeset if it 
already exists in the 'next' environment.  This would allow you to 
select content for A that already exists in B and then promote it to 
B.   It seems more confusing to the user if the locker's working 
changeset is shared across the next environments.

-Justin