Pulp 3:
-
Release 3.3.1
-
Yes, the sooner the better, some critical bug fixes are merged
-
Features
-
Mirrorlist support
-
Needs review https://github.com/pulp/pulp_rpm/pull/1690
-
config.repo feature from @lieter
-
Thank you for the great discussion today. Here's a link to the recording:
https://youtu.be/WZNjPFxYvqQ
Here is a link to the minutes/agenda from the meeting:
https://hackmd.io/9H2ry9EcT5Sa7-4QUG6iJg
We're going to continue to develop this doc as the main design doc:
On Thu, May 7, 2020 at 7:13 AM Tatiana Tereshchenko
wrote:
> +1 to `pulp` command.
>
> I think for me as a user, the most logical would be to have a plugin name
> first and then follow the URL pattern.
> The majority of commands are plugin specific. If I work with multiple
> plugins, it also
I agree with that problem statement. pulp_file may want to have the same
Content at two different paths in different RepositoryVersions (or even the
same RepositoryVersion). Without this capability a user could never "move"
where content lives in a RepositoryVersion if its already been placed in
+1 to `pulp` command.
I think for me as a user, the most logical would be to have a plugin name
first and then follow the URL pattern.
The majority of commands are plugin specific. If I work with multiple
plugins, it also makes it easy for me as a user to just change the plugin
name in front for
> In case of the RPM plugin, the content handler needs to be able to know
what the public key file is named without actually executing the sign() or
validate() method.
This opens a new can of worms. But as far as i see it, metadata is signed
when creating the publication. Along with the signature,
> Users need to be able to store the same content unit at different
relative paths in different repository versions. This problem is not unique
to the RPM plugin. Do we agree about that?
Yes, we agree. In pulp_deb relative_path is part of the contents
natural_key to circumvent this problem. So
