[Pulp-dev] Auto-distribution

[James Cassell]

On Wed, Nov 28, 2018, at 10:55 AM, Jeff Ortel wrote:
> 
> 
> 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.
> 

Sounds very reasonable. A cut/paste into the docs of the above would be helpful.

V/r,
James Cassell

P.S., didn't mean for my last message to be off list, sorry.