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

[Todd B Sanders]

On 05/20/2011 10:02 AM, Bryan Kearney wrote:
> 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.

Yes, it is stored in the updateinfo.xml files as part of the repo metadata.

+1 to unique permission for the "apply all" case.
>
>>
>> 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.

Fair.
>
>>
>> Does it make sense to pull together a brief meeting to discuss?
>
> Yes.. good idea.

Scheduling for Monday.

-Todd
>
> -- bk
>