[Pulp-dev] Pulp plugin repo name
We’re creating a separate repo for our plugin code[0] and we need to think of a name. I created a poll to see what people prefer for pulp’s plugin repository name. The package on PyPI is at https://pypi.org/project/pulpcore-plugin/. https://doodle.com/poll/npribicm6g8nqkvg You may select more than one option. I don’t have a premium account so the poll closes on Monday December 3rd. Please vote by then. [0] https://pulp.plan.io/issues/4101 David ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Auto-distribution
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. ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Auto-distribution
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
Re: [Pulp-dev] Pulp 3 RC Blocker tag
I am assuming that this can be used on a per-plugin basis, e.g. that applying this tag to an RPM plugin will be assumed to mean the RPM plugin RC as opposed to core? On Wed, Nov 28, 2018 at 9:45 AM David Davis wrote: > Just wanted to make a quick announcement that there’s a new RC Blocker tag > in redmine for issues that need to be completed by the RC release. Please > use it on all issues that you know block the RC. > > Thank you. > > David > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] Pulp 3 RC Blocker tag
Just wanted to make a quick announcement that there’s a new RC Blocker tag in redmine for issues that need to be completed by the RC release. Please use it on all issues that you know block the RC. Thank you. David ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev