RPM Support

The RPMDistribution will need to support users providing a repository or a repository version in addition to publications.

ideally we wouldn't have to generate a normal yum publication when going this route, as those are quite expensive to generate.

jsherril@redhat.com wrote:

The RPMDistribution will need to support users providing a repository or a repository version in addition to publications.

ideally we wouldn't have to generate a normal yum publication when going this route, as those are quite expensive to generate.

You would not need to create a publication. That's why we need to be able to serve the repository version directly.

This feature would be very welcome in RHUI as it would save us from regenerating the metadata every time the repo content is updated. So yes, it gets our votes!

Open question: Should the DeclarativeContent pipeline be extended to allow this functionality, or should it remain entirely within the plugin?

The latter might make more sense for the initial implementation, but if Debian wants to switch to this method we might want to be able to share the implementation.

This is a separate question from the invasive generic proposal.

dalley wrote:

Open question: Should the DeclarativeContent pipeline be extended to allow this functionality, or should it remain entirely within the plugin?

The latter might make more sense for the initial implementation, but if Debian wants to switch to this method we might want to be able to share the implementation.

I would suggest keeping the changes for now entirely in the plugin. Both RPM and Debian plugins are having a complex pipeline, would be good to first implement the proposal and then decouple what can be shared.

This is a separate question from the invasive generic proposal.

This could be accomplished by the following:

Have a way to distinguish between repositories with managed content and with the exact mirror (e.g. create a repository with exact_mirror=True or a new dedicated repository type, RpmMirrorRepository)

I think having a separate repo type will be a cleaner solution, we can disable endpoints we do not want to expose , for example /modify endpoint and also take control over what options to enable. I agree that this type of the repo should be immutable, meaning no content can be added to it or removed from it.

For such repos, create a publication at sync time (includes published artifacts and metadata).

I wonder how we would leave the room to the user to specify signing_service and gpg_check options?

For such repos, publish is no-op and always returns the existing publication for the requested repo version.

Apparently in this step we could allow user to re-publish the repo with signing_service and gpg_check options if needed, but definitely not allowing setting checksum_types

For such repos, no modifications are allowed except the sync in mirror mode.

I guess we should not allow skipping types.

I am wondering - has it been considered to add metadata as a separate content typse to the mirror repo type? This could allow us to distribute the repository right away without the need of creating the publication. On the other hand i would not know how we'd allow user setting a gpg_check option, for example. This idea is obviously far from being flawless, just throwing it on the table for discussion.

I wonder how we would leave the room to the user to specify signing_service and gpg_check options?

I'm not sure that we need to provide a way to sign repo metadata here. The idea is to have a pure mirror of the remote repo without any changes. But maybe I'm just not aware of a use case and customers will be interested in it. I'm open for feedback here.

I am wondering - has it been considered to add metadata as a separate content type to the mirror repo type? This could allow us to distribute the repository right away without the need of creating the publication. On the other hand i would not know how we'd allow user setting a gpg_check option, for example. This idea is obviously far from being flawless, just throwing it on the table for discussion.

I believe it was one of the initial ideas. One of the reason the current proposal is different because it's potentially a one step closer to a more generalised solution for the relative_path problem while the separate content type for metadata won't help in such case. Another potential concern is managing this content type in some special way... it's not a content type you want to show to a user and you need to disallow copy operation for it, aka not associate this content with any other repo, etc.