[Pulp-dev] pulp-2to3-migration 0.1.0 GA

2020-03-24 Thread Tatiana Tereshchenko 
The pulp-2to3-migration 0.1.0 is now generally available.

This is a Pulp 3 plugin to migrate content and repositories from Pulp 2 to
Pulp 3.
This release supports File 0.1 and Container 1.0 plugins and it's
compatible with Pulpcore 3.0.

PyPI: https://pypi.org/project/pulp-2to3-migration/0.1.0/
Release notes:
https://pulp-2to3-migration.readthedocs.io/en/0.1/changes.html
Docs: https://pulp-2to3-migration.readthedocs.io/en/0.1/
Python bindings: https://pypi.org/project/pulp-2to3-migration-client/0.1.0
Ruby bindings:
https://rubygems.org/gems/pulp_2to3_migration_client/versions/0.1.0

Tanya
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] pulp-2to3-migration 0.2.0 Beta 1

2020-03-24 Thread Tatiana Tereshchenko 
The pulp-2to3-migration 0.2.0b1 has been released.

This is a Pulp 3 plugin to migrate content and repositories from Pulp 2 to
Pulp 3.
It's compatible with Pulpcore 3.2.
It supports File and Container plugins, as well as RPM plugin for RPMs,
modules and custom metadata files. Support for other RPM content types is
in active development.

PyPI: https://pypi.org/project/pulp-2to3-migration/0.2.0b1/
Release notes:
https://pulp-2to3-migration.readthedocs.io/en/latest/changes.html
Docs: https://pulp-2to3-migration.readthedocs.io/en/latest/
Python bindings: https://pypi.org/project/pulp-2to3-migration-client/0.2.0b1
Ruby bindings:
https://rubygems.org/gems/pulp_2to3_migration_client/versions/0.2.0b1

Tanya
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] PR Processor

2020-03-24 Thread David Davis 
The PR processor has been merged/enabled. There was a bug where there might
have been some dupe comments added to issues and PRs. Apologies.

David


On Tue, Mar 24, 2020 at 8:50 AM David Davis  wrote:

> After looking at some different options last night, I think a cron job is
> the only option. I opened this PR which has a scheduled job that should
> check for new PRs every 5 min:
>
> https://github.com/pulp/pulp-ci/pull/701
>
> David
>
>
> On Mon, Mar 23, 2020 at 4:27 PM David Davis  wrote:
>
>> 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

2020-03-24 Thread Justin Sherrill 
I much prefer this solution (A single RPM Repository type), and i think 
just using 'location_href' for a rpm uniquness within a repo version 
makes a lot of sense, overall +1.


Justin

On 3/23/20 4:27 PM, Daniel Alley wrote:
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
mailto:ttere...@redhat.com>> 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
mailto:ggai...@redhat.com>> wrote:

On Mon, Mar 23, 2020 at 2:01 PM Dennis Kliban
mailto:dkli...@redhat.com>> 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
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] PR Processor

2020-03-24 Thread David Davis 
After looking at some different options last night, I think a cron job is
the only option. I opened this PR which has a scheduled job that should
check for new PRs every 5 min:

https://github.com/pulp/pulp-ci/pull/701

David


On Mon, Mar 23, 2020 at 4:27 PM David Davis  wrote:

> 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