Re: [Pulp-dev] Repo version validation
On Tue, Oct 8, 2019 at 2:55 PM David Davis wrote: > I think @bmbouter's solution could handle the first example of checking > RPMs against a specific key. > > The second example is trickier though because the validation would have to > know which module is being removed in order to know which packages to > remove from the repo. This is because the packages could exist in the repo > independently of the module. I think it'd have to have the list of > additions/removals in order to handle that use case. > It would have reference to the repo_version being created, so I think it would have the RepositoryVersion.removed queryset to inspect. I think this is mainly useful for copy operations at which point the copy endpoint may be a better tool for features like plugin-provided dependency resolution versus the generic copy operations in core. I keep thinking these use cases are for copy not sync, because only in the copy case is the plugin writer's code not already involved. > David > > > On Tue, Oct 8, 2019 at 12:55 PM Tatiana Tereshchenko > wrote: > >> The solution proposed in #3541 looks good for validation purposes. >> My understanding of the problem is that a plugin needs to apply some >> logic and decide which content to keep and which content to remove at repo >> version creation time and perform these changes. >> Examples: >> - add to a repo version only RPMs signed with a specific key >> - removal of the moduled content should automagically remove related >> RPMs from a repo version. >> >> In theory, for the examples above, if we have validation only, user can >> be forced to prepare perfect add/remove requests, however I think it won't >> be a good user experience. >> >> Can it be done in the same way as the suggestion for validation? Just if >> it makes sense for plugin to "fix" repo version itself, they will do it, >> otherwise validation error can be raised. What do you think? >> >> Tanya >> >> >> On Tue, Oct 8, 2019 at 4:46 PM Dennis Kliban wrote: >> >>> The plan outlined in 3541 solves the problem in a way that gives plugin >>> writers a lot of control. +1 to implementing it. >>> >>> On Thu, Oct 3, 2019 at 12:23 PM David Davis >>> wrote: >>> We have a blocker for Pulp 3.0 GA[0] that we need to address soon in order to let plugins leverage it in their upcoming GA releases. It involves allowing plugin writers to validate content in a repo version. It's somewhat related to validating uniqueness in a repo version[1] except there are cases other than uniqueness that plugins might want to handle. One example might be a case where we want to prevent a user from adding a docker tag that points to a manifest outside a repo from getting added to the repo. I'm not sure if this is an actual example but it gives you an idea that there might be other non-unique validation plugin writers might want to add. Brian proposed a solution on 3541 that I think solves the problem[2]. I was hoping to maybe get some feedback on it so we could proceed by October 9. [0] https://pulp.plan.io/issues/3541 [1] https://pulp.plan.io/issues/5008 [2] https://pulp.plan.io/issues/3541 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 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
Re: [Pulp-dev] Repo version validation
I think @bmbouter's solution could handle the first example of checking RPMs against a specific key. The second example is trickier though because the validation would have to know which module is being removed in order to know which packages to remove from the repo. This is because the packages could exist in the repo independently of the module. I think it'd have to have the list of additions/removals in order to handle that use case. David On Tue, Oct 8, 2019 at 12:55 PM Tatiana Tereshchenko wrote: > The solution proposed in #3541 looks good for validation purposes. > My understanding of the problem is that a plugin needs to apply some logic > and decide which content to keep and which content to remove at repo > version creation time and perform these changes. > Examples: > - add to a repo version only RPMs signed with a specific key > - removal of the moduled content should automagically remove related RPMs > from a repo version. > > In theory, for the examples above, if we have validation only, user can be > forced to prepare perfect add/remove requests, however I think it won't be > a good user experience. > > Can it be done in the same way as the suggestion for validation? Just if > it makes sense for plugin to "fix" repo version itself, they will do it, > otherwise validation error can be raised. What do you think? > > Tanya > > > On Tue, Oct 8, 2019 at 4:46 PM Dennis Kliban wrote: > >> The plan outlined in 3541 solves the problem in a way that gives plugin >> writers a lot of control. +1 to implementing it. >> >> On Thu, Oct 3, 2019 at 12:23 PM David Davis >> wrote: >> >>> We have a blocker for Pulp 3.0 GA[0] that we need to address soon in >>> order to let plugins leverage it in their upcoming GA releases. It involves >>> allowing plugin writers to validate content in a repo version. It's >>> somewhat related to validating uniqueness in a repo version[1] except there >>> are cases other than uniqueness that plugins might want to handle. One >>> example might be a case where we want to prevent a user from adding a >>> docker tag that points to a manifest outside a repo from getting added to >>> the repo. I'm not sure if this is an actual example but it gives you an >>> idea that there might be other non-unique validation plugin writers might >>> want to add. >>> >>> Brian proposed a solution on 3541 that I think solves the problem[2]. I >>> was hoping to maybe get some feedback on it so we could proceed by October >>> 9. >>> >>> [0] https://pulp.plan.io/issues/3541 >>> [1] https://pulp.plan.io/issues/5008 >>> [2] https://pulp.plan.io/issues/3541 >>> >>> 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 mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] Installer Team Changes
Recently the installer has had a lot of changes, and Mike DePaulo (@mikedep333) has been the most involved with it over the past few months. With all favorable support, the existing committers accept @mikedep333 as the lead for the Installer mini-team on Github. Additionally, we wanted to find out who would work with the Installer on a weekly basis. We polled the existing committers to see who wants to stay involved, and several who were not planning to continue have given up their bit including: @abraverman, @lyrch, @dawalker. This leaves the current committers as: @mikedep333, @dkliban, and myself (@bmbouter) which you can ping on Github via @pulp/ansible-installer. If you would like to be more involved with the installer, please let @mikedep333 know. Contributions and feedback is welcome from everyone; the installer is shared by all of us. This clarity on who is the lead should provide benefits like: * Reduce the time to review for new contributions * Reduce the time to fix for high-priority issues in the installer * Help facilitate for roadmap creation and long-term planning Thank you to everyone who has helped make the installer excellent. It's taken much work from many people to get it to this point. -Brian ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
[Pulp-dev] Issue exporting Publications to POSIX Filesystems
At open floor today, we talked about an issue with the exporting Publications with some relative_path data to POSIX filesystems. I'm wondering what you think should/could be done about this. https://pulp.plan.io/issues/5559 Thanks! Brian ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Repo version validation
The plan outlined in 3541 solves the problem in a way that gives plugin writers a lot of control. +1 to implementing it. On Thu, Oct 3, 2019 at 12:23 PM David Davis wrote: > We have a blocker for Pulp 3.0 GA[0] that we need to address soon in order > to let plugins leverage it in their upcoming GA releases. It involves > allowing plugin writers to validate content in a repo version. It's > somewhat related to validating uniqueness in a repo version[1] except there > are cases other than uniqueness that plugins might want to handle. One > example might be a case where we want to prevent a user from adding a > docker tag that points to a manifest outside a repo from getting added to > the repo. I'm not sure if this is an actual example but it gives you an > idea that there might be other non-unique validation plugin writers might > want to add. > > Brian proposed a solution on 3541 that I think solves the problem[2]. I > was hoping to maybe get some feedback on it so we could proceed by October > 9. > > [0] https://pulp.plan.io/issues/3541 > [1] https://pulp.plan.io/issues/5008 > [2] https://pulp.plan.io/issues/3541 > > 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
