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
_______________________________________________
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
