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

[Bryan Kearney]

On 05/20/2011 08:13 AM, Todd B Sanders wrote:
> 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.

+1

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

Is errata matata stored in the repomod files? If so, I agree that the 
user must pick the product(s) to apply the package/errata to or 
explicitly state "all products". I think the latter should be a unique 
permission.

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

I am fine for now, but I would prefer this to be a GUI thing. If we 
assume that you interrogate the next env to know what to put in change 
set... then we can never re-use. I would prefer a model where you 
construct a valid CS from your current env and then apply only what is 
needed to next.

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

Yes.. good idea.

-- bk