Pulp

This could be done by having the platform track when the last time is that the distributor config changed. There is a similar desire to track when an importer config last changed, to determine when a full sync should happen.

In talking with @ipanova about this, why can't we make this a bug instead and not introduce an option to turn this on. In that case the behavior described would be on by default.

I like the idea of this being the default behavior. The absence of that behavior is inefficient, but is it a bug? I could see it both ways.

Regardless of what we call it, if we make that the default behavior, we need an option to force a full publish. We got into trouble with the yum importer when we tried a similar optimization that skips most of the work, we didn't provide an option to force a full sync, and we have several times needed to do tricks to help a user force a full sync. Imagine that /var/lib/pulp/published is lost or corrupted and needs to be recreated. Or a user goes poking around in there and messes up some published data. Or there's a bug in pulp that produces incorrect published data, and users need to re-publish after getting a fix.

mhrivnak, thanks for the input. We definitely need to be able to force a republish. The good news is we are tracking that work as https://pulp.plan.io/issues/1158

I'm going to rewrite this into a bug and drop the usage of a distributor option. Two different pulp user groups have identified this behavior as the expected behavior and it makes sense to me too.

Distributors should not be impacted by changes to importer settings, so I feel comfortable not considering the importer or its settings at all for this behavior. In the very small number of cases where we've needed the importer to make the distributor aware of something, we've managed to do so without require the distributor to look at the importer. Otherwise, the line between importers and distributors had been kept quite rigid.

repo_id is immutable, so that won't be a problem.

display_name is not used programmatically to my knowledge. It's intended only for human consumption. I suppose in theory a human-readable name could reasonably be used to form a URL, like many blogs do, but I don't think any part of pulp does that currently. I'm in favor of explicitly documenting that it is not for programmatic use.

thanks mhrivnak. It sounds like the story as it is currently written will guard against the necessary cases. I think it's ready for working on.

Currently this is planned an RPM feature, but I think it could implemented almost as easily as a platform feature which would make it available for all plugin types.

In the publish task itself you could have it run all the checks described in this ticket happen before the call to _do_publish(). That would get implemented here[0].

[0]: https://github.com/bmbouter/pulp/blob/0e2560e045dad843950461affad51d69c4b9f9d2/server/pulp/server/controllers/repository.py#L971-L971

https://github.com/PulpQE/pulp-smash/issues/232