[Pulp-dev] Repo versions with no changes

[Mike DePaulo]

On Mon, Nov 4, 2019 at 4:50 PM Mike DePaulo <mikedep333 at redhat.com> wrote:

>
>
> On Mon, Nov 4, 2019 at 4:39 PM Brian Bouterse <bmbouter at redhat.com> wrote:
>
>> tl;dr I'm +1 to making this switch.
>>
>> On Mon, Nov 4, 2019 at 3:51 PM David Davis <daviddavis at redhat.com> wrote:
>>
>>> Currently in pulp, syncs always create repository versions regardless of
>>> whether or not any content changed. One of the tasks[0] for 3.0 GA is to
>>> document this behavior. However, I've heard several complaints about this
>>> from users so I wonder if it's worth reconsidering.
>>>
>> I love making users happy, but the complaints didn't resonate as much
>> with me because another user with a different subjective preferences could
>> walk up and complain after we switch it. I try to listen for user
>> complaints that come with objective claims of usability.
>>
>>
>>> Here are some reasons against always creating repo versions:
>>> - They were meant to serve as a historical record but this information
>>> is available by looking at the tasks api
>>> - It creates additional, unnecessary versions and bumps the latest
>>> version number of the repo
>>> - If we ever have a feature to retain only the latest X repo versions,
>>> it'll be less useful since some repo versions may not have any changes
>>>
>> This last bullet I see an objective reason to make no-content-change repo
>> versions not increment. Users concerned about their cron jobs not running
>> can check the task records. Users get RepositoryVersions that always
>> include change and are therefore more meaningful (perhaps that was Bin Li's
>> objective claim). Also future users could get a repo-version retention
>> option which would be difficult to create if we don't switch this.
>>
>
> From a black-box perspective, how about some sort of compromise solution?
> Like a minor version number being bumped if there is a no-change sync. Or a
> separate field like "1st identical repo version."
>

Whether we implement a compromise or not, this current proposal should be
implemented 1st.

+1


>
>
>>
>>
>>> Any thoughts? I'd like to get this on the sprint by Wednesday so it can
>>> be changed before the dev freeze date of Nov 12.
>>>
>> +1 to making this change
>>
>>>
>>> [0] https://pulp.plan.io/issues/3308
>>>
>>> David
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
>
> --
>
> Mike DePaulo
>
> He / Him / His
>
> Service Reliability Engineer, Pulp
>
> Red Hat <https://www.redhat.com/>
>
> IM: mikedep333
>
> GPG: 51745404
> <https://www.redhat.com/>
>


-- 

Mike DePaulo

He / Him / His

Service Reliability Engineer, Pulp

Red Hat <https://www.redhat.com/>

IM: mikedep333

GPG: 51745404
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20191104/b0204684/attachment.htm>