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

[Todd B Sanders]

On 05/18/2011 11:53 AM, Justin Sherrill wrote:
> 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
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel

Been thinking about this a bit....

1. I think we need to support multiple working change-sets at any given 
point in time.  It seems to me that especially in the lesser 
"locked-down" environments more folks will have the ability to promote 
products.  With that, I think we will see a lot of promotion of products 
individually.  Also, not all users users will have access to all 
products, thus, a user should only be able to see change-sets that 
include products that they can promote.  A single working change-set 
between any two unique environments is going to be very limiting for our 
users.  So, I think we need to have CRUD around change-sets. However, 
once they are applied/promoted, they are only available as history items.

2. We need to scope package and errata within the change-set.  i.e. does 
the promotion apply to all products, or given a specific set.  
Currently, we assume all products in the environment, again, I think 
this is going to be limiting for our users.

3. Originally, I had suggested that we *only* support a single path of 
promotion through our set of environments; with only one unique "next" 
environment. One "branch" vs multiple "branches" so to speak.  This was 
an effort to reduce scope and complexity in v1.0.  Any reason why we 
shouldn't go back to this?

Does it make sense to pull together a brief meeting to discuss?

-Todd