[Pulp-dev] Auto-distribution

[Jeff Ortel]

On 11/27/18 11:45 PM, James Cassell wrote:
> On Tue, Nov 27, 2018, at 4:22 PM, Jeff Ortel wrote:
>>
>> On 11/27/18 3:20 PM, Jeff Ortel wrote:
>>>
>>> On 11/27/18 8:29 AM, Austin Macdonald wrote:
>>>> Yes, and AFAIK this is already complete. There are 2 fields on the
>>>> Distribution that allow auto-distribution. These fields must both be
>>>> set, and when they are, new publications will automatically update
>>>> the distribution.
>>> The Auto-distribution feature is not the same as auto-publish in pulp2
>>> which automatically triggered a publish at the end of a sync.  The
>>> auto-distribution feature automatically makes a newly created
>>> publication "live" after it has been created.  This is done by
>>> updating distributions (per configuration) with the newly created
>>> publication. As a result, the publication will be served by the
>>> distribution.  This is different than auto-publish in pulp2.
>> Currently, there are no plans to support pulp2 auto-publish in pulp3.
>>
> How would one achieve the same behaviour?  Is this a big functionality loss?

By not providing auto-publish, the responsibility for publishing after 
sync just shifts to the user.  For use cases where the user is manually 
triggering the sync, a subsequent API call would be needed to also 
trigger the publish.  For scheduled sync use cases or other cases where 
the sync is trigger though external automation, the automation could 
implement auto publish by triggering a publish following a successful 
sync.  This seems straight forward enough and puts the responsibility 
for making the decision to publish in the hands of the user.

The decision to not provide auto-publish in the pulp 3.0 core does not 
imply that the auto-publish flow has been dismissed as insignificant.  
But instead, is intended to promote implementations outside the core 
because it seemed more appropriate.  If this approach proves to be a 
significant burden on the user, we've had some preliminary discussions 
on mitigation.  For example, some tooling could be provided.  For 
example: some libs for python and bash scripting etc.  But, in the end, 
if users end up wanting/needing this back in core, that can be discussed 
as well.

>
> V/r,
> James Cassell