Re: [Pulp-dev] SUSE repositories in Pulp
I think, as long as the metadata is correct, using just the location_href would be OK. It should contain all the other bits of information. On Mon, Mar 23, 2020 at 3:57 PM David Davis wrote: > A couple questions below. > > On Mon, Mar 23, 2020 at 3:47 PM Tatiana Tereshchenko > wrote: > >> Clarification: >> The proposal is to add the 'location_href' attribute to >> the repo_key_fields, uniqueness constraint within a repository version, so >> 2 packages with the same NEVRA but different location can be present in one >> repo. >> > > Why have nevra+relative_path instead of just relative_path? ie would it be > possible for two packages in a repo version to have the same relative_paths > but different nevras? > > >> RPM package is still uniquely identified in Pulp by NEVRA + checksum(aka >> pkgId) + checksum type. >> > > What if a user has the same package in a repo at two different locations > or the same package in two different repos at the different locations. > Since relative_path is attached to the content unit, I think this would > prevent this from happening? I wonder if uniqueness in Pulp should also > have location_href/relative_path? > > >> >> On Mon, Mar 23, 2020 at 7:33 PM Grant Gainey wrote: >> >>> On Mon, Mar 23, 2020 at 2:01 PM Dennis Kliban >>> wrote: >>> During last week's RPM team meeting, a concern was raised about using the same repository type for both Red Hat and SUSE repositories. Since that meeting I have only been able to identify a single difference between the two repositories. SUSE repos can contain the same package in two different locations in the same repository. Even though I just referred to this as a difference, I don't actually believe that to be true. All RPM repositories should be able to support this. >>> >>> If I'm reading the discussion w/the RPM folks correctly, this is 'odd >>> but legal' for rpm-repositories. That means that, while SUSE may be the >>> only current example, there's nothing to keep some other distro/thirdparty >>> from doing the exact same thing, and we'd have to handle it. >>> >>> I propose that we not add a separate repository type for SUSE and simply add the 'location' attribute of an RPM to it's uniqueness constraint. What do you all think? >>> >>> Yeah, concur. It feels messy - but only because the problem-domain >>> itself is messy :( >>> >>> G >>> >>> ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >>> -- >>> Grant Gainey >>> Principal Software Engineer, Red Hat System Management Engineering >>> ___ >>> 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] PR Processor
I ran into a problem. Any PR event in Github Actions runs against the fork and not the repo against which the PR was opened. And the repo's secrets such as the github api key and redmine api key are not shared with the fork for obvious security reasons. Fabricio and I are looking at some options. I'll try to figure out a workaround this coming weekend. David On Mon, Mar 23, 2020 at 9:19 AM David Davis wrote: > Cool. When we move the cherry pick processor to Github Actions, we can do > some cool things like run it when a PR gets merged or labeled. > > David > > > On Mon, Mar 23, 2020 at 9:08 AM Brian Bouterse > wrote: > >> Oh I'm glad you asked. I incorrectly thought this also actually performed >> cherry picking, but I see now it only adds labels. At one point we had the >> idea to convert the PR processor to a "run as needed with github actions" >> instead of "run once a day with Travis". >> >> I was referring to removing the cherry picking tooling from Travis, but >> if this doesn't replace it, let's not do that. >> >> On Mon, Mar 23, 2020 at 9:05 AM David Davis >> wrote: >> >>> Brian, >>> >>> What do you mean by "removing the old one"? AFAIK, there is nothing >>> currently processing PRs and updating redmine. >>> >>> David >>> >>> >>> On Mon, Mar 23, 2020 at 8:41 AM Brian Bouterse >>> wrote: >>> This is excellent. +1 to merging, rolling out to plugins, and removing the old one. Thank you! On Mon, Mar 23, 2020 at 7:48 AM Ina Panova wrote: > Thank you for this work! > > > > 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 Sat, Mar 21, 2020 at 3:49 PM Daniel Alley > wrote: > >> This is great! Awesome work, David <3 >> >> On Sat, Mar 21, 2020 at 10:38 AM David Davis >> wrote: >> >>> I created a PR workflow in Github Actions so I could learn more >>> about Github Actions. >>> >>> Here's the issue and my PR against plugin_template: >>> >>> https://pulp.plan.io/issues/4365 >>> https://github.com/pulp/plugin_template/pull/199 >>> >>> The PR processor will listen for new PRs in Github and when it >>> detects a newly opened PR it does two things: >>> >>> - Updates the pulp.plan.io issue >>> - Adds a comment with a link to the Github PR (regardless of the >>> issue's status) >>> - Sets the issue status to POST if it's in NEW or ASSIGNED >>> - Adds labels to the Github PR >>> - Right now, this is only "Needs Cherry Pick" which is added if >>> tracker == "Issue" >>> >>> I have an example that demonstrates the PR processor. Here's a story >>> and its PR: >>> >>> https://pulp.plan.io/issues/6381 >>> https://github.com/daviddavis/pulp_file/pull/11 >>> >>> The PR processor will also comment with a warning if there is no >>> issue attached: >>> >>> https://github.com/daviddavis/pulp_file/pull/12 >>> >>> Questions and feedback welcome. >>> >>> 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] SUSE repositories in Pulp
A couple questions below. On Mon, Mar 23, 2020 at 3:47 PM Tatiana Tereshchenko wrote: > Clarification: > The proposal is to add the 'location_href' attribute to > the repo_key_fields, uniqueness constraint within a repository version, so > 2 packages with the same NEVRA but different location can be present in one > repo. > Why have nevra+relative_path instead of just relative_path? ie would it be possible for two packages in a repo version to have the same relative_paths but different nevras? > RPM package is still uniquely identified in Pulp by NEVRA + checksum(aka > pkgId) + checksum type. > What if a user has the same package in a repo at two different locations or the same package in two different repos at the different locations. Since relative_path is attached to the content unit, I think this would prevent this from happening? I wonder if uniqueness in Pulp should also have location_href/relative_path? > > On Mon, Mar 23, 2020 at 7:33 PM Grant Gainey wrote: > >> On Mon, Mar 23, 2020 at 2:01 PM Dennis Kliban wrote: >> >>> During last week's RPM team meeting, a concern was raised about using >>> the same repository type for both Red Hat and SUSE repositories. Since that >>> meeting I have only been able to identify a single difference between the >>> two repositories. SUSE repos can contain the same package in two different >>> locations in the same repository. Even though I just referred to this as a >>> difference, I don't actually believe that to be true. All RPM repositories >>> should be able to support this. >>> >> >> If I'm reading the discussion w/the RPM folks correctly, this is 'odd but >> legal' for rpm-repositories. That means that, while SUSE may be the only >> current example, there's nothing to keep some other distro/thirdparty from >> doing the exact same thing, and we'd have to handle it. >> >> >>> I propose that we not add a separate repository type for SUSE and simply >>> add the 'location' attribute of an RPM to it's uniqueness constraint. What >>> do you all think? >>> >> >> Yeah, concur. It feels messy - but only because the problem-domain itself >> is messy :( >> >> G >> >> ___ >>> Pulp-dev mailing list >>> Pulp-dev@redhat.com >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >> >> >> -- >> Grant Gainey >> Principal Software Engineer, Red Hat System Management Engineering >> ___ >> 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] SUSE repositories in Pulp
Clarification: The proposal is to add the 'location_href' attribute to the repo_key_fields, uniqueness constraint within a repository version, so 2 packages with the same NEVRA but different location can be present in one repo. RPM package is still uniquely identified in Pulp by NEVRA + checksum(aka pkgId) + checksum type. On Mon, Mar 23, 2020 at 7:33 PM Grant Gainey wrote: > On Mon, Mar 23, 2020 at 2:01 PM Dennis Kliban wrote: > >> During last week's RPM team meeting, a concern was raised about using the >> same repository type for both Red Hat and SUSE repositories. Since that >> meeting I have only been able to identify a single difference between the >> two repositories. SUSE repos can contain the same package in two different >> locations in the same repository. Even though I just referred to this as a >> difference, I don't actually believe that to be true. All RPM repositories >> should be able to support this. >> > > If I'm reading the discussion w/the RPM folks correctly, this is 'odd but > legal' for rpm-repositories. That means that, while SUSE may be the only > current example, there's nothing to keep some other distro/thirdparty from > doing the exact same thing, and we'd have to handle it. > > >> I propose that we not add a separate repository type for SUSE and simply >> add the 'location' attribute of an RPM to it's uniqueness constraint. What >> do you all think? >> > > Yeah, concur. It feels messy - but only because the problem-domain itself > is messy :( > > G > > ___ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> > > > -- > Grant Gainey > Principal Software Engineer, Red Hat System Management Engineering > ___ > 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] SUSE repositories in Pulp
On Mon, Mar 23, 2020 at 2:01 PM Dennis Kliban wrote: > During last week's RPM team meeting, a concern was raised about using the > same repository type for both Red Hat and SUSE repositories. Since that > meeting I have only been able to identify a single difference between the > two repositories. SUSE repos can contain the same package in two different > locations in the same repository. Even though I just referred to this as a > difference, I don't actually believe that to be true. All RPM repositories > should be able to support this. > If I'm reading the discussion w/the RPM folks correctly, this is 'odd but legal' for rpm-repositories. That means that, while SUSE may be the only current example, there's nothing to keep some other distro/thirdparty from doing the exact same thing, and we'd have to handle it. > I propose that we not add a separate repository type for SUSE and simply > add the 'location' attribute of an RPM to it's uniqueness constraint. What > do you all think? > Yeah, concur. It feels messy - but only because the problem-domain itself is messy :( G ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > -- Grant Gainey Principal Software Engineer, Red Hat System Management Engineering ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] SUSE repositories in Pulp
I agree, just usually it is not the same package, but two packages with the same name with minor differences inside (e.g. optimization). On Mon, Mar 23, 2020 at 7:01 PM Dennis Kliban wrote: > During last week's RPM team meeting, a concern was raised about using the > same repository type for both Red Hat and SUSE repositories. Since that > meeting I have only been able to identify a single difference between the > two repositories. SUSE repos can contain the same package in two different > locations in the same repository. Even though I just referred to this as a > difference, I don't actually believe that to be true. All RPM repositories > should be able to support this. > > I propose that we not add a separate repository type for SUSE and simply > add the 'location' attribute of an RPM to it's uniqueness constraint. What > do you all think? > ___ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > -- Pavel Picka Red Hat ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] SUSE repositories in Pulp
> > I propose that we not add a separate repository type for SUSE and simply > add the 'location' attribute of an RPM to it's uniqueness constraint. What > do you all think? +1 On Mon, Mar 23, 2020 at 2:01 PM Dennis Kliban wrote: > During last week's RPM team meeting, a concern was raised about using the > same repository type for both Red Hat and SUSE repositories. Since that > meeting I have only been able to identify a single difference between the > two repositories. SUSE repos can contain the same package in two different > locations in the same repository. Even though I just referred to this as a > difference, I don't actually believe that to be true. All RPM repositories > should be able to support this. > > I propose that we not add a separate repository type for SUSE and simply > add the 'location' attribute of an RPM to it's uniqueness constraint. What > do you all think? > ___ > 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] SUSE repositories in Pulp
During last week's RPM team meeting, a concern was raised about using the same repository type for both Red Hat and SUSE repositories. Since that meeting I have only been able to identify a single difference between the two repositories. SUSE repos can contain the same package in two different locations in the same repository. Even though I just referred to this as a difference, I don't actually believe that to be true. All RPM repositories should be able to support this. I propose that we not add a separate repository type for SUSE and simply add the 'location' attribute of an RPM to it's uniqueness constraint. What do you all think? ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Should signing service be associated with Publication or Repository?
On Fri, Mar 20, 2020 at 8:35 AM Neal Gompa wrote: > On Thu, Mar 19, 2020 at 11:14 PM Dennis Kliban wrote: > > > > RPM plugin allows users to define a signing service per repository. All > publications created from repository versions of that repository are signed > with that signing service. > > > > The Debian plugin requires the user to specify the signing service each > time a publication is created. The signing service foreign key is stored > with each publication. > > > > Even though the implementation in Debian requires the user to provide > the service href each time a publication is created, it seems like a > stronger model. The signing service associated with a repository can change > thus making it challenging to keep track of which signing service was used > to create a publication. > > > > We should change the behavior in the RPM plugin before we release this > feature. > > Isn't the reason for the difference that Debian repos only have > repodata signed and not packages? > > I guess technically we could use different GPG keys for each > repository publish, but that would lead to multiple copies of the same > RPM with different data, since the expectation is that both RPMs and > the repodata should be signed for RPM repositories. > > The RPM plugin does not currently provide the ability to sign packages. This discussion is only about singing the metadata. > > -- > 真実はいつも一つ！/ Always, there's only one truth! > > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] PR Processor
Cool. When we move the cherry pick processor to Github Actions, we can do some cool things like run it when a PR gets merged or labeled. David On Mon, Mar 23, 2020 at 9:08 AM Brian Bouterse wrote: > Oh I'm glad you asked. I incorrectly thought this also actually performed > cherry picking, but I see now it only adds labels. At one point we had the > idea to convert the PR processor to a "run as needed with github actions" > instead of "run once a day with Travis". > > I was referring to removing the cherry picking tooling from Travis, but if > this doesn't replace it, let's not do that. > > On Mon, Mar 23, 2020 at 9:05 AM David Davis wrote: > >> Brian, >> >> What do you mean by "removing the old one"? AFAIK, there is nothing >> currently processing PRs and updating redmine. >> >> David >> >> >> On Mon, Mar 23, 2020 at 8:41 AM Brian Bouterse >> wrote: >> >>> This is excellent. +1 to merging, rolling out to plugins, and removing >>> the old one. >>> >>> Thank you! >>> >>> On Mon, Mar 23, 2020 at 7:48 AM Ina Panova wrote: >>> Thank you for this work! 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 Sat, Mar 21, 2020 at 3:49 PM Daniel Alley wrote: > This is great! Awesome work, David <3 > > On Sat, Mar 21, 2020 at 10:38 AM David Davis > wrote: > >> I created a PR workflow in Github Actions so I could learn more about >> Github Actions. >> >> Here's the issue and my PR against plugin_template: >> >> https://pulp.plan.io/issues/4365 >> https://github.com/pulp/plugin_template/pull/199 >> >> The PR processor will listen for new PRs in Github and when it >> detects a newly opened PR it does two things: >> >> - Updates the pulp.plan.io issue >> - Adds a comment with a link to the Github PR (regardless of the >> issue's status) >> - Sets the issue status to POST if it's in NEW or ASSIGNED >> - Adds labels to the Github PR >> - Right now, this is only "Needs Cherry Pick" which is added if >> tracker == "Issue" >> >> I have an example that demonstrates the PR processor. Here's a story >> and its PR: >> >> https://pulp.plan.io/issues/6381 >> https://github.com/daviddavis/pulp_file/pull/11 >> >> The PR processor will also comment with a warning if there is no >> issue attached: >> >> https://github.com/daviddavis/pulp_file/pull/12 >> >> Questions and feedback welcome. >> >> 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] PR Processor
Oh I'm glad you asked. I incorrectly thought this also actually performed cherry picking, but I see now it only adds labels. At one point we had the idea to convert the PR processor to a "run as needed with github actions" instead of "run once a day with Travis". I was referring to removing the cherry picking tooling from Travis, but if this doesn't replace it, let's not do that. On Mon, Mar 23, 2020 at 9:05 AM David Davis wrote: > Brian, > > What do you mean by "removing the old one"? AFAIK, there is nothing > currently processing PRs and updating redmine. > > David > > > On Mon, Mar 23, 2020 at 8:41 AM Brian Bouterse > wrote: > >> This is excellent. +1 to merging, rolling out to plugins, and removing >> the old one. >> >> Thank you! >> >> On Mon, Mar 23, 2020 at 7:48 AM Ina Panova wrote: >> >>> Thank you for this work! >>> >>> >>> >>> 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 Sat, Mar 21, 2020 at 3:49 PM Daniel Alley wrote: >>> This is great! Awesome work, David <3 On Sat, Mar 21, 2020 at 10:38 AM David Davis wrote: > I created a PR workflow in Github Actions so I could learn more about > Github Actions. > > Here's the issue and my PR against plugin_template: > > https://pulp.plan.io/issues/4365 > https://github.com/pulp/plugin_template/pull/199 > > The PR processor will listen for new PRs in Github and when it detects > a newly opened PR it does two things: > > - Updates the pulp.plan.io issue > - Adds a comment with a link to the Github PR (regardless of the > issue's status) > - Sets the issue status to POST if it's in NEW or ASSIGNED > - Adds labels to the Github PR > - Right now, this is only "Needs Cherry Pick" which is added if > tracker == "Issue" > > I have an example that demonstrates the PR processor. Here's a story > and its PR: > > https://pulp.plan.io/issues/6381 > https://github.com/daviddavis/pulp_file/pull/11 > > The PR processor will also comment with a warning if there is no issue > attached: > > https://github.com/daviddavis/pulp_file/pull/12 > > Questions and feedback welcome. > > 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] PR Processor
Brian, What do you mean by "removing the old one"? AFAIK, there is nothing currently processing PRs and updating redmine. David On Mon, Mar 23, 2020 at 8:41 AM Brian Bouterse wrote: > This is excellent. +1 to merging, rolling out to plugins, and removing the > old one. > > Thank you! > > On Mon, Mar 23, 2020 at 7:48 AM Ina Panova wrote: > >> Thank you for this work! >> >> >> >> 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 Sat, Mar 21, 2020 at 3:49 PM Daniel Alley wrote: >> >>> This is great! Awesome work, David <3 >>> >>> On Sat, Mar 21, 2020 at 10:38 AM David Davis >>> wrote: >>> I created a PR workflow in Github Actions so I could learn more about Github Actions. Here's the issue and my PR against plugin_template: https://pulp.plan.io/issues/4365 https://github.com/pulp/plugin_template/pull/199 The PR processor will listen for new PRs in Github and when it detects a newly opened PR it does two things: - Updates the pulp.plan.io issue - Adds a comment with a link to the Github PR (regardless of the issue's status) - Sets the issue status to POST if it's in NEW or ASSIGNED - Adds labels to the Github PR - Right now, this is only "Needs Cherry Pick" which is added if tracker == "Issue" I have an example that demonstrates the PR processor. Here's a story and its PR: https://pulp.plan.io/issues/6381 https://github.com/daviddavis/pulp_file/pull/11 The PR processor will also comment with a warning if there is no issue attached: https://github.com/daviddavis/pulp_file/pull/12 Questions and feedback welcome. 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] Package in a different repo does not get added to package list on Module
On Wed, Mar 18, 2020 at 9:07 AM Ina Panova 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? > This isn't exactly related to your question but I wanted to share a thought. I call this problem "content isolation", and I hope in the future (maybe the near-future) Pulp will isolate content per-user/group. Pulp has a multi-tenancy problem. The reasoning is that pulp is built as a multi-user system, but as it is your content isn't actually safe from other users. This could circumvent things like users syncing pay-for redhat content with pulp and then having other users of that system who are not RH subscribers have "full access" to that content. >From a high level, I think the solution to "content isolation problem" is to use add "user/group" ownership restriction at the queryset level and probably integrate w/ a user-configurable policy engine like drf-access-policy https://rsinger86.github.io/drf-access-policy/multi_tenacy/ > > 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 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 > ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] PR Processor
This is excellent. +1 to merging, rolling out to plugins, and removing the old one. Thank you! On Mon, Mar 23, 2020 at 7:48 AM Ina Panova wrote: > Thank you for this work! > > > > 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 Sat, Mar 21, 2020 at 3:49 PM Daniel Alley wrote: > >> This is great! Awesome work, David <3 >> >> On Sat, Mar 21, 2020 at 10:38 AM David Davis >> wrote: >> >>> I created a PR workflow in Github Actions so I could learn more about >>> Github Actions. >>> >>> Here's the issue and my PR against plugin_template: >>> >>> https://pulp.plan.io/issues/4365 >>> https://github.com/pulp/plugin_template/pull/199 >>> >>> The PR processor will listen for new PRs in Github and when it detects a >>> newly opened PR it does two things: >>> >>> - Updates the pulp.plan.io issue >>> - Adds a comment with a link to the Github PR (regardless of the >>> issue's status) >>> - Sets the issue status to POST if it's in NEW or ASSIGNED >>> - Adds labels to the Github PR >>> - Right now, this is only "Needs Cherry Pick" which is added if >>> tracker == "Issue" >>> >>> I have an example that demonstrates the PR processor. Here's a story and >>> its PR: >>> >>> https://pulp.plan.io/issues/6381 >>> https://github.com/daviddavis/pulp_file/pull/11 >>> >>> The PR processor will also comment with a warning if there is no issue >>> attached: >>> >>> https://github.com/daviddavis/pulp_file/pull/12 >>> >>> Questions and feedback welcome. >>> >>> 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] PR Processor
Thank you for this work! 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 Sat, Mar 21, 2020 at 3:49 PM Daniel Alley wrote: > This is great! Awesome work, David <3 > > On Sat, Mar 21, 2020 at 10:38 AM David Davis > wrote: > >> I created a PR workflow in Github Actions so I could learn more about >> Github Actions. >> >> Here's the issue and my PR against plugin_template: >> >> https://pulp.plan.io/issues/4365 >> https://github.com/pulp/plugin_template/pull/199 >> >> The PR processor will listen for new PRs in Github and when it detects a >> newly opened PR it does two things: >> >> - Updates the pulp.plan.io issue >> - Adds a comment with a link to the Github PR (regardless of the >> issue's status) >> - Sets the issue status to POST if it's in NEW or ASSIGNED >> - Adds labels to the Github PR >> - Right now, this is only "Needs Cherry Pick" which is added if tracker >> == "Issue" >> >> I have an example that demonstrates the PR processor. Here's a story and >> its PR: >> >> https://pulp.plan.io/issues/6381 >> https://github.com/daviddavis/pulp_file/pull/11 >> >> The PR processor will also comment with a warning if there is no issue >> attached: >> >> https://github.com/daviddavis/pulp_file/pull/12 >> >> Questions and feedback welcome. >> >> 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
Re: [Pulp-dev] Package in a different repo does not get added to package list on Module
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 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 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
