Based on the discussion that has taken place on #pulp-dev there has been reached a common agreement that the behaviour observed in the issue https://pulp.plan.io/issues/6295 is an expected behaviour. I am closing this thread for now.
Pavel, will you update the issue with the according state and message? Thank you. -------- Regards, Ina Panova Senior Software Engineer| Pulp| Red Hat Inc. "Do not go where the path may lead, go instead where there is no path and leave a trail." On Wed, Mar 18, 2020 at 2:04 PM Ina Panova <ipan...@redhat.com> wrote: > This has always been a grey area: > > what if the user who has created RepoA cannot access content to the repoB > and yet we are 'stealing' the content from repoB? > > -------- > Regards, > > Ina Panova > Senior Software Engineer| Pulp| Red Hat Inc. > > "Do not go where the path may lead, > go instead where there is no path and leave a trail." > > > On Tue, Mar 17, 2020 at 7:41 PM Pavel Picka <ppi...@redhat.com> wrote: > >> Hi, >> >> started to work on #6295 [0] and by now at sync we look only for actual >> (repository we are syncing) packages if they are modular and connect to >> modulemd. >> >> To fix this issue we will need to check content from other repositories >> (already synced) what can have a really huge impact on sync time in case of >> big repositories. >> >> Do we want to get through all pulp content (RPM packages) when syncing >> new repository with modulemd? Or idea can be to extend sync API call with >> new argument to scan (all or specific) repositories. >> >> I think we would like to keep performance of sync so better to discuss >> first. >> >> Thank you >> >> [0] https://pulp.plan.io/issues/6295 >> >> -- >> Pavel Picka >> Red Hat >> _______________________________________________ >> 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