[Pulp-dev] Migration plugin meeting notes

[Tatiana Tereshchenko]

   -

   Current priorities (discussed). Pick from the top 4.
   - [in progress] start migration from scratch
  https://pulp.plan.io/issues/7714
  - skip the corrupted content https://pulp.plan.io/issues/7538
  - pre-migrate content from mongo ordered by date (in case something
  fails, so re-run can pick it up from the right place)
  https://pulp.plan.io/issues/7781
 - check indices in pulp 2 for last_updated. If they are absent, we
 might need another pulp 2 release
  - ensure a migration task can be cancelled at any point
  https://pulp.plan.io/issues/7778
 - what to do with long running db queries
  - re-run needs to be very fast https://pulp.plan.io/issues/7779
 - special handling of no changes or very little changes in pulp 2
  - process simple plan as a complex one
  https://pulp.plan.io/issues/6516
 - needed for Pulp community
  - fips https://pulp.plan.io/issues/7782
 - likely blocked on fips for plugins


   - Tests
  - Depending on how quickly we’ll be able to address the items above,
  we might have time to get to the test backlog.

Open PRs

   - https://github.com/pulp/pulp-2to3-migration/pulls

Un-triaged bugs

   - https://pulp.plan.io/projects/migration/issues?query_id=159
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] the "relative path" problem

[Tatiana Tereshchenko]

Updated the redmine story https://pulp.plan.io/issues/6353 with this
proposal. Feel free to comment there as well.
If there are no objections, I'll start on a PoC once I finish the items I'm
working on right now.

Thanks,
Tanya

On Wed, Oct 21, 2020 at 8:48 PM Tatiana Tereshchenko 
wrote:

> TL;DR: An attempt to propose the least invasive option to solve the case
> when remote repository metadata needs to be mirrored. Please provide
> feedback if you are interested in the outcome.
>
> There have been multiple attempts and discussions to solve the
> relative_path problem in a general way which covers multiple use cases.
> They all look very invasive and only possible to be done in Pulp 4+ due to
> the amount and significance of changes that needs to be made, to the data
> models and/or to the API.
>
> The following proposal solves only this use case: As a user, I can mirror
> remote repository metadata as is.
> An additional goal is to avoid backward incompatible changes and ideally
> leave a way for further improvement to solve the problem in a more general
> way.
> (The following proposal does NOT solve a use case: As a user, I can have
> the same content under different relative paths in any repository.)
>
> Proposal:
> - Have a way to distinguish between repositories with managed content and
> with the exact mirror (e.g. create a repository with exact_mirror=True or a
> new dedicated repository type)
>  - For such repos, create a publication at sync time (includes published
> artifacts and metadata).
>  - For such repos, publish is no-op and always returns the existing
> publication for the requested repo version.
>  - For such repos, no modifications are allowed except the sync in mirror
> mode. (At least for RPM plugin, I believe we can't allow discrepancies
> between metadata and content in a repo, especially if some content is
> removed.)
>
> Pros:
>  - non-invasive, only additive model changes
>  - can be implemented in a plugin which needs it or it can be moved to the
> pulpcore if it allows plugin input at certain points.
>  - leaves a way for further improvement to handle a more general case, see
> the full proposal here
> https://hackmd.io/02KBjCD3Q0WP7p4ALwzhJw#relative_path-in-PublishedArtifact-only
>
> Cons:
>  - doesn't solve the problem of various relative paths for the same
> content in general way
>  - a separate code path (at times) to handle this type of repositories.
>
> For reference:
>  - hackmd doc with all the considered proposals and the summary of the
> potentially valid ones https://hackmd.io/02KBjCD3Q0WP7p4ALwzhJw
>  - pulpcon video with the discussion of the proposals
> https://www.youtube.com/watch?v=7IzxAQYr5-I
>
> Thanks,
> Tanya
>
> On Thu, May 7, 2020 at 2:07 PM Brian Bouterse  wrote:
>
>> 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
>> any other RepositoryVersion.
>>
>> Additionally pulp_maven may need to sync two repositories in the wild
>> that already contain the same content in two locations. I offer this as
>> example not to pile-on, but because it's a multi-content artifact which I
>> believe we will need to consider also as we work towards a solution.
>>
>> I've been spending time on developing a solution, but it needs more work
>> so it's not ready yet. Also other katello and galaxy_ng work continues to
>> pre-empt this, so it could take a while.
>>
>> On Thu, May 7, 2020 at 3:39 AM Matthias Dellweg 
>> wrote:
>>
>>> > 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 this creates two content units
>>> that only differ in relativ_path. At least they share the artifact.
>>>
>>> On Thu, May 7, 2020 at 2:06 AM Dennis Kliban  wrote:
>>>
>>>> I'd like to provide a little bit more context for my previous email by
>>>> going back to the original problem statement:
>>>>
>>>> On Wed, Apr 1, 2020 at 9:23 AM Daniel Alley  wrote:
>>>>
>>>>> Problem:
>>>>>
>>>>> Currently, a relative_path is tied to content in Pulp. This means that
>>>>> if a content unit exists in two places within 

Re: [Pulp-dev] the "relative path" problem

[Tatiana Tereshchenko]

TL;DR: An attempt to propose the least invasive option to solve the case
when remote repository metadata needs to be mirrored. Please provide
feedback if you are interested in the outcome.

There have been multiple attempts and discussions to solve the
relative_path problem in a general way which covers multiple use cases.
They all look very invasive and only possible to be done in Pulp 4+ due to
the amount and significance of changes that needs to be made, to the data
models and/or to the API.

The following proposal solves only this use case: As a user, I can mirror
remote repository metadata as is.
An additional goal is to avoid backward incompatible changes and ideally
leave a way for further improvement to solve the problem in a more general
way.
(The following proposal does NOT solve a use case: As a user, I can have
the same content under different relative paths in any repository.)

Proposal:
- Have a way to distinguish between repositories with managed content and
with the exact mirror (e.g. create a repository with exact_mirror=True or a
new dedicated repository type)
 - For such repos, create a publication at sync time (includes published
artifacts and metadata).
 - For such repos, publish is no-op and always returns the existing
publication for the requested repo version.
 - For such repos, no modifications are allowed except the sync in mirror
mode. (At least for RPM plugin, I believe we can't allow discrepancies
between metadata and content in a repo, especially if some content is
removed.)

Pros:
 - non-invasive, only additive model changes
 - can be implemented in a plugin which needs it or it can be moved to the
pulpcore if it allows plugin input at certain points.
 - leaves a way for further improvement to handle a more general case, see
the full proposal here
https://hackmd.io/02KBjCD3Q0WP7p4ALwzhJw#relative_path-in-PublishedArtifact-only

Cons:
 - doesn't solve the problem of various relative paths for the same content
in general way
 - a separate code path (at times) to handle this type of repositories.

For reference:
 - hackmd doc with all the considered proposals and the summary of the
potentially valid ones https://hackmd.io/02KBjCD3Q0WP7p4ALwzhJw
 - pulpcon video with the discussion of the proposals
https://www.youtube.com/watch?v=7IzxAQYr5-I

Thanks,
Tanya

On Thu, May 7, 2020 at 2:07 PM Brian Bouterse  wrote:

> 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
> any other RepositoryVersion.
>
> Additionally pulp_maven may need to sync two repositories in the wild that
> already contain the same content in two locations. I offer this as example
> not to pile-on, but because it's a multi-content artifact which I believe
> we will need to consider also as we work towards a solution.
>
> I've been spending time on developing a solution, but it needs more work
> so it's not ready yet. Also other katello and galaxy_ng work continues to
> pre-empt this, so it could take a while.
>
> On Thu, May 7, 2020 at 3:39 AM Matthias Dellweg 
> wrote:
>
>> > 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 this creates two content units
>> that only differ in relativ_path. At least they share the artifact.
>>
>> On Thu, May 7, 2020 at 2:06 AM Dennis Kliban  wrote:
>>
>>> I'd like to provide a little bit more context for my previous email by
>>> going back to the original problem statement:
>>>
>>> On Wed, Apr 1, 2020 at 9:23 AM Daniel Alley  wrote:
>>>
 Problem:

 Currently, a relative_path is tied to content in Pulp. This means that
 if a content unit exists in two places within a repository or across
 repositories, it has to be stored as two separate content units. This
 creates redundant data and potential confusion for users.

 As a specific example, we need to support mirroring content in pulp_rpm
 . Currently, for each location at
 which a single package is stored, we’ll need to create a content unit. We
 could end up with several records representing a single package. Users may
 be confused about why they see multiple records for a package and they may
 have trouble for example deciding which content unit to copy.

>>> 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?
>>>
>>> I've been working on a potential solution that solves this problem in a
>>> 

Re: [Pulp-dev] pulpcore 3.8.0 release timeline & go/no-go irc meeting

[Tatiana Tereshchenko]

No blocking items for pulpcore and pulp_installer 3.8.0 release were
identified at the meeting today.
The tentative GA date is still October 20th.

In case any new issues come up, a quick sync-up before the release will
take place in #pulp-meeting at the time below:

Monday Oct 19th, 10:30am - 11:00am EDT. https://everytimezone.com/s/130b36c0


On Fri, Oct 2, 2020 at 8:41 PM Tatiana Tereshchenko 
wrote:

> Here's the tracker for the pulpcore 3.8.0 release:
> https://pulp.plan.io/issues/7645.
> The tentative GA date is October 20th.
>
> The first go/no-go meeting will happen in #pulp-meeting at the time below:
>
> Tuesday Oct 13th, 9am - 9:30am EDT. https://everytimezone.com/s/e267c120
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Migration plugin meeting notes

[Tatiana Tereshchenko]

Also available here https://hackmd.io/@pulp/migration_meeting

   -

   running migration on the same machine as pulp 2 production
   - control of resources, how fast migration goes
 - cgroups?
- one of concerns - shared postgres instance
 - control with the number of pulp3 workers?
  -

   3-month planning prep
   - skip corrupted pulp 2 content (katello)
  https://pulp.plan.io/issues/7538 on the sprint already
  - FIPS https://pulp.plan.io/issues/7536
  - optimization not to create child tasks when not necessary
  https://pulp.plan.io/issues/7009
  - Improve re-migration time
 - speed up no-op re-migration
 - speed up few-changes re-migration

Open PRs

   - https://github.com/pulp/pulp-2to3-migration/pulls
  - ttereshc to follow up withpilp_deb to see where things are

Un-triaged bugs

   - https://pulp.plan.io/projects/migration/issues?query_id=159
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Also available here: https://hackmd.io/@pulp/rpm_meeting

Pulp 3:
 * Sprint items https://pulp.plan.io/projects/pulp_rpm/issues?query_id=161
 * Grant will work on the copy issue and a pulp2 bug which already has
a patch to support Amazon Linux repositories
 * Pavel will likely cover the rest of the issues in the NEW state

Pulp 2:
 * 2.21.4 Release incoming
 * https://pulp.plan.io/projects/pulp/wiki/2214_Release_Schedule

Open PRs:
 * https://github.com/pulp/pulp_rpm/pulls

Un-triaged bugs:
 * https://pulp.plan.io/projects/pulp_rpm/issues?query_id=159

3-month planning prep (Jan-Mar):
 * RBAC - likely will still be not fully done
 * mirror repodata - Tanya needs to send a followup from PulpCon
 * auto-publish - likely a small amount of work
 * zchunk - can we squeeze it in?
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp2: 2.21.4 Release Proposal

[Tatiana Tereshchenko]

Thank you!
The proposed dates look good to me.

Tanya

On Thu, Oct 8, 2020 at 7:03 PM Grant Gainey  wrote:

> Hello folks,
>
> We have a number of Pulp2 bugs that have been fixed, that we would like to
> get into a formal release. To that end, I'm proposing the following dates:
>
> dev-freeze: *Tues 13-OCT*
> beta (rpms available): *Fri 16-OCT*
> GA: *Tues 22-OCT*
>
> Release page is here:
>
> https://pulp.plan.io/projects/pulp/wiki/2214_Release_Schedule
>
> You can see the list of proposed issues here:
>
> https://pulp.plan.io/issues?query_id=59
>
> I will be the release-nanny for 2.21.4.  If you have questions or
> counter-proposals, you can reach me at *ggai...@redhat.com
> * or via IRC, *ggainey *in* #pulp *or* #pulp-dev *on*
> Freenode*. I am in Raleigh's timezone (GMT-4)
>
> Thanks!
>
> Grant
> --
> 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] namespacing base_path of Distributions

[Tatiana Tereshchenko]

I believe I've heard RPM plugin users asking for the same.
Something along those lines: I want to allow this group of people to
publish/distribute repositories under this path and the other group of
people - under that path.

It would be great if any folks who'll benefit from such a feature could
speak up.

On Tue, Oct 6, 2020 at 11:57 PM Dennis Kliban  wrote:

> The container plugin is introducing a 'namespace' resource that will be
> associated with Distributions. The name of the namespace will be used as
> the first part of the base_path for the ContainerDistribution. Role based
> access control will allow users to create content under their own namespace
> and any other namespace that they have permission to push container images
> to.
>
> Would a similar feature be useful in any other plugins?
> ___
> 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] RPM plugin meeting notes

[Tatiana Tereshchenko]

Also available here: https://hackmd.io/@pulp/rpm_meeting

AI review:


   - github merge options - done

Pulp 3:

   - As a Pulp Rpm user, I can have my repository synced, auto published
   and distributed https://pulp.plan.io/issues/7622
  - need to add more details before grooming
   - Pulp does not resync yum metadata files on change
   https://pulp.plan.io/issues/7030
  - pulp 2 gap
  - false positive no-op sync
  - add to the sprint

Pulp 2:

   - Impacted by https://pulp.plan.io/issues/7445
  - Grant will open a cloned issue/PR #soon

Open PRs:

   - https://github.com/pulp/pulp_rpm/pulls

Un-triaged bugs:

   - https://pulp.plan.io/projects/pulp_rpm/issues?query_id=159
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Also available here: https://hackmd.io/@pulp/rpm_meeting

General:


   - github merge options
  - leave only rebase option

Pulp 3:

   -

   https://pulp.plan.io/issues/7537
   - Would like to get into the pulp_rpm 3.8 if possible
 - +1
 - depending on the effort it might push back RBAC work
  -

   https://pulp.plan.io/issues/6926
   - does it depend on the changes which are needed in pulpcore?
 - can be worked on independently
  -

   https://pulp.plan.io/issues/7431
   - treat dist tree/comps as other content?
 -  yes

Pulp 2:

   - when reviewing Pulp 2 PRs, make sure to remove “Needs cherry-pick”
   label

Open PRs:

   - https://github.com/pulp/pulp_rpm/pulls

Un-triaged bugs:

   - https://pulp.plan.io/projects/pulp_rpm/issues?query_id=159
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Disabling merge by commit

[Tatiana Tereshchenko]

pulp_rpm left only rebase & merge option.

On Wed, Sep 23, 2020 at 7:46 PM Mike DePaulo  wrote:

> On Wed, Sep 23, 2020 at 9:52 AM Justin Sherrill 
> wrote:
>
>>
>> On 9/23/20 7:18 AM, David Davis wrote:
>>
>> I think the two main things for me are (1) it makes git history more
>> linear and (2) it cuts down on the number of commits. Both of these make
>> git history more readable.
>>
>> 3rd main thing for me:
> 3. It removes extra work when rewriting history. Rewriting history is
> desirable in case secret keys, huge binary blobs (that degrade git
> performance), etc accidentally get through.
>
>> The 'rebase and merge' option provides a nice balance of letting you
>> provide multiple commits and maintain commit history while not creating a
>> merge commit and  making a hard to read commit history.  Sometimes it is
>> more expressive to have two (or three) commits that make up one pr to make
>> it into the source tree.
>>
> I agree with rebase and merge. Often I need multiple commits for that
> reason, or for multiple closely related (pulp_installer) tickets.
>
> I've done this both on the X2Go Project ,
> and at a previous job with a big ansible codebase.
>
> -Mike
>
>
> David
>
>
> On Wed, Sep 23, 2020 at 6:48 AM Ina Panova  wrote:
>
>> Hi Quirin,
>>
>>
>> 
>> 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, Sep 23, 2020 at 10:47 AM Quirin Pamp  wrote:
>>
>>> "I'd encourage plugins to consider disabling merge by commit as well."
>>>
>>> In order to evaluate this it would be great, if you could explain why
>>> this was decided for pulpcore and pulp_file.
>>> You have posted a lot of general information about the different merge
>>> type (the "What?"), but not so much on the "Why?".
>>>
>>> As far as I can tell the main advantage of squish and rebase, is that it
>>> leads to a more tidy history in master, at the cost of losing some
>>> information on how the sausage was made.
>>> As a result squish and rebase becomes increasingly advantageous with
>>> increasing PR volume.
>>> However, I fail to see an advantage for pulp_deb, which does not have a
>>> large PR volume.
>>>
>>> Or am I missing some relevant part of the argument?
>>>
>>
>> I think your understanding is correct. In my perspective it is important
>> to have a tidy history in master no matter how high/low PR traffic you have.
>>
>> pulp_container has disabled merge by commit as well.
>>
>>>
>>> Quirin
>>> --
>>> *From:* pulp-dev-boun...@redhat.com  on
>>> behalf of David Davis 
>>> *Sent:* 22 September 2020 17:16
>>> *To:* Pulp-dev 
>>> *Subject:* Re: [Pulp-dev] Disabling merge by commit
>>>
>>> Here's some more information about PR merges as well:
>>>
>>>
>>> https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges
>>>
>>> David
>>>
>>>
>>> On Tue, Sep 22, 2020 at 11:11 AM David Davis 
>>> wrote:
>>>
>>> Today at open floor, we decided to disable merging by commit for
>>> pulpcore and pulp_file PRs. Instead, developers will rebase or squash PRs
>>> to merge them. This adds the changes to HEAD instead of
>>> interspersing commits and creating a merge commit. This picture of git
>>> history comparing pulpcore to foreman (which doesn't merge by commit)
>>> illustrates the differences:
>>>
>>> https://imgur.com/a/uiIa0Mr
>>>
>>> I'd encourage plugins to consider disabling merge by commit as well. To
>>> do so, go to the settings page for your github repo and look under the
>>> Merge Button section.
>>>
>>> David
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>
> ___
> Pulp-dev mailing 
> listPulp-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>
> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>
>
> --
>
> Mike DePaulo
>
> He / Him / His
>
> Service Reliability Engineer, Pulp
>
> Red Hat 
>
> IM: mikedep333
>
> GPG: 51745404
> 
> ___
> 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] 3.7.0 Release Timeline & Go/No-Go Chat Meeting

[Tatiana Tereshchenko]

pulp_rpm==3.7.0 is published but not announced.

On Wed, Sep 23, 2020 at 11:11 PM Brian Bouterse  wrote:

> A lot of progress was made today, the final 3.7.0 and several plugin
> compatibility releases should go out tomorrow.
>
> * 3.6.4 pulpcore and its installer are fully published and announced
> * pulpcore==3.7.0, pulp_file==1.3.0, and pulp_ansible==0.4.0 are published
> but not announced (waiting on pulpcore announcement first)
> * pulp_container==2.1.0 is publishing right now (thanks @ipanova and
> @dkliban)
> * 3.6.4 installer is not yet published, and this is what is holding up the
> announcement. I will resume tomorrow, and then proceed to announce
> * pulp-certguard should happen tomorrow, along with galaxy_ng upgrading to
> the latest pulpcore, pulp_ansible, and pulp_container. pulp_rpm I also
> think is likely
>
>
>
>
> On Wed, Sep 23, 2020 at 12:29 PM Brian Bouterse 
> wrote:
>
>> Through IRC discussion here's what we learned:
>>
>> * it's generally agreed plugins should not switch their pulpcore version
>> in a z-stream
>> * pulpcore 3.7.0 is on pypi so plugins can now use pulpcore>=3.7,<3.9 and
>> start releasing. Bump your y-versions even if there are no changes (it's
>> strange I know but ... bullet point one)
>> * 3.6.3 is broken, and I am now going to release a 3.6.4 and an installer
>> version 3.6.4 first, see this release tracker issue
>> https://pulp.plan.io/issues/7557
>> * We're waiting on pulp_file and pulp_rpm compat releases for 3.7.0
>> before the installer is released
>> * Once the installer and pulpcore bits are available (both 3.7.0 and
>> 3.6.4) announcements will go to pulp-list
>>
>>
>>
>>
>> On Tue, Sep 22, 2020 at 7:15 PM Brian Bouterse 
>> wrote:
>>
>>> 3.7.0 is technically released, but the pulp_file PR is failing due to a
>>> variety of reasons. I'll continue on it (and the pulp_ansible release PR
>>> also failing) tomorrow.
>>>
>>> I still need to release the installer, and then proceed with the
>>> announcements.
>>>
>>> On Fri, Sep 18, 2020 at 1:13 PM Brian Bouterse 
>>> wrote:
>>>
 We had our final go/no-go check in today, and we determined 3.7.0 is
 on-track for the Sept 22nd release date.

 You can see the milestone's work items here:
 https://tinyurl.com/y6rqlufb

 * Everything except 7460 is expected to merge, or at least be in POST,
 by EOB today
 * 7460 is a very small piece of work that a meeting on Monday will
 coordinate
 * Selinux EL7 and EL8 policies (not in work query since it doesn't
 block the pulpcore release due to not being in pulpcore's bits) is also
 done!

 Thanks to everyone who put in so much hard work to get this release
 ready.


 On Tue, Sep 15, 2020 at 12:51 PM Brian Bouterse 
 wrote:

> At the go/no-go check in today, we determined the 3.7.0 is on-track
> for the Sept 22nd release date.
>
> The next check-in meeting on #pulp-meeting is set up for Friday Sept
> 18th, 12pm - 12:30pm EDT. https://everytimezone.com/?t=5f63f880,3c0
>
> ## Notes
>
> * All remaining pulpcore and pulpcore installer items to be included
> are now tagged in the 3.7.0 milestone:
> https://pulp.plan.io/versions/126
> * You can see a query-based of the milestone sorted by status here:
> https://tinyurl.com/y6rqlufb
> * We believe all items at ASSIGNED will be merged at our current pace
> by Friday
> * The 4 items at NEW are all now marked HIGH prio
> * All code must be merged by the end of business on the 21st. The 22nd
> is just release day
> * The SELinux deliverables (EL7 and EL8 policies) are required for
> 3.7.0 but are not included on this milestone because they are shipped
> separately from pulpcore and therefore do not need to block its release
> * No significant pulp_file items were discussed
>
> ## The four items at NEW
>
> 7471 - The biggest risk. The installer team will be discussing this
> today and through the end of the week
> 7460 - A small item. A meeting on monday was already set up to
> finalize it's merge. This will likely merge on the 21st
> 7413 - To be done on docs day this Thursday the 17th
> 7411 - Technically not blocking the release and will be removed if not
> merged by end of business on the 21st. It is still high prio though, for
> anyone who is on the CI mini-team and can work on it
>
> Thanks to everyone who participated in our release check in today!
>
>
> On Fri, Sep 4, 2020 at 3:20 PM Brian Bouterse 
> wrote:
>
>> Per the new process, here's the tracker (with checklist) for 3.7.0's
>> release: https://pulp.plan.io/issues/7463  Right now, the GA date is
>> slated for Sept 22nd.
>>
>> The first go/no-go meeting will happen in #pulp-meeting at the time
>> below:
>>
>> Tuesday Sept 15th, 12pm - 12:30pm EDT.
>> https://everytimezone.com/s/68f4535a
>>
>> 

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Also available here: https://hackmd.io/@pulp/rpm_meeting

AI review:

   - ttereshc to investigate slow sync/publish for smart proxies in pup2
   - ggainey to look at power kickstart https://pulp.plan.io/issues/7303

Pulp 3:

   - proxy issue https://pulp.plan.io/issues/7321
   - distribution tree orphan cleanup problem
   https://pulp.plan.io/issues/7440
  - ugly “half-solution” https://github.com/pulp/pulp_rpm/pull/1836
  - ideas are welcome

Pulp2:

   - F32 sync issue https://pulp.plan.io/issues/7449
  - close, upgrade to pulp3

Open PRs:

   - https://github.com/pulp/pulp_rpm/pulls

Un-triaged bugs:

   - https://pulp.plan.io/projects/pulp_rpm/issues?query_id=159
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] PulpCon 2020 schedule

[Tatiana Tereshchenko]

PulpCon 2020 is approaching!
Check out the schedule https://hackmd.io/@pulp/pulpcon2020_schedule.

In case of any changes, that document will be updated.
Agenda for each session is being added to each hackmd doc linked in the
schedule.

Join us in a couple of weeks at PulpCon!
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Also available here: https://hackmd.io/@pulp/rpm_meeting

AI review

   - ask katello if 3.6.1 release is needed 3.6.1. is out

General:

   - commit bit for ggainey
  - agreed

Pulp 3:

   - https://pulp.plan.io/issues/7298
  - put on the sprint for investigation for import/export issue vs
  duplicates handling
   - dep solving fixtures for katello
  - remove from the sprint, iballou will likely work on it
   - malformed oracle repository (module arch is missing sometimes)
  - still open but on QE
   - proxy issue https://pulp.plan.io/issues/7321
  - ppicka is on it, not reproduced so far
   - FIPS proposal

Pulp 2:

   - slow sync/publish for smart proxies
  - suspicion is that errata make publish operational more often than
  needed
  - might be related to the timestamp fixes in 2.21
  - ttereshc to investigate
   - power kickstart https://pulp.plan.io/issues/7303
  - ggainey to look into next week
  - need a URL to sync from

Open PRs:

   - https://github.com/pulp/pulp_rpm/pulls

Un-triaged bugs:

   - https://pulp.plan.io/projects/pulp_rpm/issues?query_id=159
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Also available here: https://hackmd.io/@pulp/rpm_meeting

AI review


   - ttereshc will create a hackmd doc for agenda/notes
   - ttereshc to take a look at pulp-internal list about fixing checksum
   mismatch

Pulp 3:

   - 3.6.1
  - file downloader is fixed
  - ask katello if release is needed
   - dep solving issues
  - one is on hold, waiting on libsolv maintainer reply
  - another is in progress
   - malformed oracle repository (module arch is missing sometimes)
  - https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=17353 (assigned
  state as of today)
   - dep solving fixtures for katello https://pulp.plan.io/issues/7333
  - Do these fixtures make sense to have at fixtures.pulpproject.org?
  in other words, would they benefit Pulp as well?
  - If so, maybe ask iballou for a PR? I (david) can do this.
 - +1 to add them

Open PRs:

   - https://github.com/pulp/pulp_rpm/pulls

Un-triaged bugs:

   - https://pulp.plan.io/projects/pulp_rpm/issues?query_id=159
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] github checklist as a part of the release process

[Tatiana Tereshchenko]

I learned recently how Fedora CoreOS folks do their releases and I really
like their process.
I think something similar can be useful for Pulp. We already have ~15 steps
in our release guide
 and it's
without some pre/post-release steps, like release announcement
collaboration, writing blog posts, etc.

The idea is simple.
Have a checklist template (for each type of release if needed).
Create a github issue with this checklist and mark it as you perform the
steps.
In addition post any relevant links as comments.
Here is the example
https://github.com/coreos/fedora-coreos-streams/issues/158

Benefits:
 - release progress is open and transparent to everyone, including our
community
 - it's easy to look at the history if needed
 - release "guide" is always up to date
 - if one started a release and can't finish for some reason (e.g. end of
working day in their time zone), another one can take over
 - keeps a release person more organized (those who released many times
sometimes perform steps by memory and might forget some small steps; often
people multitask and do something while waiting for the builds to be done.
Our release guide serves the same purpose but one needs to consciously go
back to it, here it requires you to click the checkbox.)

Cons:
  - a potential downside is that it's one more action to do and a new
process to follow. Though it should be very close to the release guide, so
I hope it does not add much to our processes, it should not feel like
something new :)

Thoughts?

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

Re: [Pulp-dev] PulpCon 2020 - save the date and vote for topics!

[Tatiana Tereshchenko]

Thanks for the participation in the voting and for bringing your
suggestions!
The voting is closed.

We will go through the suggestions and share a tentative schedule soon.
Stay tuned!

Tanya

On Wed, Aug 5, 2020 at 4:31 PM Tatiana Tereshchenko 
wrote:

> +pulp-list 
>
> On Wed, Aug 5, 2020 at 4:28 PM Tatiana Tereshchenko 
> wrote:
>
>> We are glad to announce that PulpCon will take place during* the week of
>> September 14th*.
>> The sessions will be held over *5 half-days*, Mon-Fri mornings in EST
>> and afternoons in CET.
>>
>> Currently, we are collecting potential topics to discuss and voting on
>> them. Please add topics you are interested in to this doc
>> <https://hackmd.io/@pulp/pulpcon2020/> [0] or add your +1 to the
>> existing ones.
>>
>> If you would like to present your own work related to Pulp, your own
>> plugin or any tooling around Pulp, feel free to add your name and project
>> as a topic. We'll be happy to hear about your experience and allocate a
>> slot for you in the schedule.
>>
>> The topic submission and voting will be closed on *August 15, 2020*.
>>
>> [0] https://hackmd.io/@pulp/pulpcon2020/
>>
>> On Wed, Jul 1, 2020 at 3:50 PM Tatiana Tereshchenko 
>> wrote:
>>
>>> PulpCon is an annual event where Pulp developers and contributors come
>>> together to discuss short and long-term project goals, deep dive into new
>>> and developing features, and make time for topics that need more attention
>>> than an email thread or a conventional meeting will allow. The schedule
>>> changes every year and is driven by the attendees.
>>>
>>> Past events have been held in person; however, this year it will be
>>> *virtual*.
>>>
>>> The sessions will take place over 5 half-days - mornings in EST and
>>> afternoons in CET. The schedule of sessions will be planned
>>> collaboratively. A detailed schedule will be announced on the pulp-dev
>>> mailing list as we get closer to the event. Participants are free to attend
>>> whichever sessions interest them.
>>>
>>> At this time we are trying to pick a week that will work best for
>>> everyone. Please provide your input here:
>>> https://doodle.com/poll/bssf9qpnzei9ypyg
>>>
>>> Thank you!
>>>
>>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Migration plugin meeting notes

[Tatiana Tereshchenko]

The notes below can also be found here:
https://hackmd.io/@pulp/migration_meeting

   -

   Travis failures
   - installing pulpcore and pulp-2to3-migration outside of a container
  - func tests depends on configs from ^ and on pulp2 connection
  initialization
   -

   Getting Pulp 2 repos in tests
   - use constants
   -

   Use cases
   - on ttereshc todo list
   -

   Current priority items
   - Sync after migrating file content throws error
  https://pulp.plan.io/issues/7264
  - Hard links not being used during RPM content type migration
  https://pulp.plan.io/issues/7244
   -

   3-month planning
   - Current (Jul-Sep)
 - Minor features (SLES support, simple-to-complex migration plan
 (0.25 FTE/week))
 - Known bugs, ongoing
 - Tests, in progress
  - Sep-Nov
 - adjust to pulp_container 2.0 changes (0.25 FTE/week)
 - performance testing/work for pulp_file and pulp_container part
 (1 FTE/week)
 - tests (2 FTE/week)

Open PRs

   - https://github.com/pulp/pulp-2to3-migration/pulls

Un-triaged bugs

   - https://pulp.plan.io/projects/migration/issues?query_id=159
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

The agenda with the meeting notes are now public
https://hackmd.io/@pulp/rpm_meeting.
Feel free to add any items which require RPM mini-team attention. We meet
once a week to go through the agenda items.

Notes from yesterday:

Pulp 3:

   - As a user, I want to be able to use ansible to manage a pulp rpm repo
   https://pulp.plan.io/issues/7222
   - What if we move this agenda to hack.md? +1
  - ttereshc will create a doc - done
   - 3.6 release
  - Likely Tuesday, Aug-18

Pulp 2:

   - How do we address PRs that are features
   https://github.com/pulp/pulp_rpm/pull/1799
  - solved
   - Email on pulp-internal list about fixing checksum mismatch
  - ttereshc to take a look

3-month planning prep:

   - Current plans (Jul-Sep)
  - RBAC (postpone?)
  - Zchunk support (postpone?)
  - Known bugs for Katello
  - Import/export
   - Sep-Nov planning
  - RBAC (if not done earlier)
  - Known bugs for Katello
  - Candidates (vote with +1s):
 - Items from previous planning which are not complete
- RBAC
- Zchunk support - postpone
 - As a user I can set/update repo_gpgcheck and gpg_check options
 https://pulp.plan.io/issues/6926 +1 to add +1+1 +1 +1
 - RPM signing and re-signing https://pulp.plan.io/issues/1686 +1
 - As a user, I can do a one-shot upload of custom repository
 metadata https://pulp.plan.io/issues/5433 +1 +1
 - As a user, I can view sub repositories
 https://pulp.plan.io/issues/5556
 - As a user, I want to be able to use ansible to manage a pulp rpm
 repo https://pulp.plan.io/issues/7222 - dkliban plans to work on
 it soon as a part of CLI effort +1 +1 +1
 - FIPS +1 +1
 - https://pulp.plan.io/issues/5510 - notes/tags +1 +1

Open PRs:

   - https://github.com/pulp/pulp_rpm/pulls

Un-triaged bugs:

   - https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] When to declare Pulp safe for multi-user?

[Tatiana Tereshchenko]

On Wed, Aug 12, 2020 at 12:34 PM Ina Panova  wrote:

>
>
>
> 
> 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, Aug 11, 2020 at 11:10 PM Brian Bouterse 
> wrote:
>
>> Pulpcore 3.6 adds RBAC machinery for plugins to enable RBAC with [0], but
>> that hasn't happened broadly in plugins or pulpcore yet, so Pulp 3.6 is
>> still not multi-user safe. I want us to discuss options and strategy for
>> when can we declare Pulp multi-user safe.
>>
>> My take is that, I think we should avoid a situation where no part of
>> Pulp can be declared multi-user safe until every call in Pulp everywhere is
>> multi-user safe. I think doing it plugin-by-plugin is a reasonable
>> middle-ground. Alternatives to consider here would be great.
>>
>
> It might get tricky if we follow that path. I am not sure we can speak for
> all the plugins, especially the community plugins plans and timelines.
> What about finding a middle ground and targeting " Pulpcore is multi-user
> safe 3.7+ with the following list of plugins", where the list will of
> plugins will be increasing with time.
> I would not want to hit the bottleneck and wait with "Pulp is multi-user
> safe unless all plugins have rbac support".
>

+1, maybe it's worth adding a new column to our plugin table, "multi-user
safe" - yes/no.


>
>
>> Assuming a plugin-by-plugin approach, I'd like to propose a few things
>> for discussion:
>>
>> * pulpcore and pulp_file enable RBAC on all of their endpoints for 3.7
>> * pulpcore declare itself safe for multi-user use for 3.7 [1]
>> * all plugins discuss-and-communicate which release is their target to
>> add RBAC support
>>
>> +1
>
+1


>
> What do you think?
>>
>> [0]:
>> https://github.com/pulp/pulpcore/tree/master/docs/plugins/plugin-writer/concepts/rbac
>> [1]: https://pulp.plan.io/issues/7309
>>
>> -Brian
>>
>>
>> ___
>> 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] Dealing with our redmine backlog

[Tatiana Tereshchenko]

+1 to allow all users to re-open issues.
If ^, then +1 to closing as many backlog issues as seems needed.

We can close based on the date and then review manually items with redmine
issue number less than N - old ones, to see if they have recent comments or
just spam.

On Thu, Aug 6, 2020 at 6:08 PM Ina Panova  wrote:

>
>
>
> 
> 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, Aug 5, 2020 at 8:54 PM David Davis  wrote:
>
>> We've been discussing the possibility of closing issues in redmine due to
>> the overwhelming number of issues at NEW. Currently, we have 930 issues at
>> NEW and I think that exceeds our capacity to address each issue
>> individually.
>>
>> The first item I want to bring up for discussion is expanding the ability
>> for users to reopen closed issues. Currently only authors can reopen issues
>> at CLOSED excluding CLOSED - DUPLICATE and CLOSED - COMPLETE. Should we
>> expand this to all redmine users?
>>
>
> +1 to expand it to all users.
>
>>
>> If we expand this permission, this should give us the ability to safely
>> close out issues that fit some criteria. I looked at the pulpcore issues
>> and limited the issues to just ones without a Katello tag or a BZ and that
>> were created before 2020[0]. This still leaves us with almost 300 NEW
>> issues in pulpcore which still seems unrealistic to go through. Any
>> thoughts on what criteria to use?
>>
>
> We could also exclude issues that have Pulp2 tag.
> Even if we end up having 300 issues to process, I know that sounds a lot,
> but we can regularly dedicate 5 mins(timeboxed!) of our pulpcore team
> meeting, or open floor to go through. For some issues it is enough to read
> the title to make a decision.
> I *think* this might be a feasible idea, look how many and good
> improvements we did in redmine having it on the agenda for each open floor.
>
> Alsom, what will be the state of the issues we are going to mass close -
> CLOSED-WON'TFIX?
>
>>
>> [0] It would be better to use updated at to scope issues but
>> unfortunately a lot of older issues have been updated recently due to spam
>> comment
>>
>
>> 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] Allowing Older Z-stream Backports and Releases?

[Tatiana Tereshchenko]

Backport tracker has been created.
Docs about how to file a backport request can be found here
https://docs.pulpproject.org/en/master/nightly/bugs-features.html#for-backport-requests

Tanya

On Wed, Aug 5, 2020 at 12:11 PM Ina Panova  wrote:

> To follow up on this, during the open floor it has been decided to create
> a Backport tracker to facilitate backport requests, in addition some docs
> are being written so people have guidelines.
>
> 
> 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 Thu, Jul 30, 2020 at 7:10 PM Brian Bouterse 
> wrote:
>
>> Currently my understanding of the z-stream policy is that Pulp only has
>> one active z-stream. This means (for example) that when 3.6.0 comes out,
>> there will never be another z-stream release for 3.5.z, 3.4.z, 3.3.z, etc.
>>
>> I believe we have an opportunity to create more value by adjusting this
>> to allow for older z-stream releases to be requested as-needed. This would
>> allow for example Katello's use of pulpcore 3.4.1 to request a 3.4.2 to be
>> created even if 3.6.0 is released. Similarly for any plugin. These could
>> only contain bugfixes (never features) due to semantic versioning
>> restriction.
>>
>> This is based on feedback I've gotten from various users including
>> Katello, and this would allow them to use a version of pulpcore or a plugin
>> and receive stability fixes without being forced to upgrade. Then they can
>> upgrade when is right for them (not for us).
>>
>> If others agree with this change I think we need to figure out the
>> following:
>>
>> * How can a user request a backport? [bmbouter suggests using a new
>> tracker type in Redmine named 'Backport']
>> * How can mini-teams perform backporting? [bmbouter suggests manual
>> cherry-picking and releasing as-needed, only with requested items]
>>
>> What do you think?
>>
>> Thanks!
>> Brian
>>
>> ___
>> 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] PulpCon 2020 - save the date and vote for topics!

[Tatiana Tereshchenko]

+pulp-list 

On Wed, Aug 5, 2020 at 4:28 PM Tatiana Tereshchenko 
wrote:

> We are glad to announce that PulpCon will take place during* the week of
> September 14th*.
> The sessions will be held over *5 half-days*, Mon-Fri mornings in EST and
> afternoons in CET.
>
> Currently, we are collecting potential topics to discuss and voting on
> them. Please add topics you are interested in to this doc
> <https://hackmd.io/@pulp/pulpcon2020/> [0] or add your +1 to the existing
> ones.
>
> If you would like to present your own work related to Pulp, your own
> plugin or any tooling around Pulp, feel free to add your name and project
> as a topic. We'll be happy to hear about your experience and allocate a
> slot for you in the schedule.
>
> The topic submission and voting will be closed on *August 15, 2020*.
>
> [0] https://hackmd.io/@pulp/pulpcon2020/
>
> On Wed, Jul 1, 2020 at 3:50 PM Tatiana Tereshchenko 
> wrote:
>
>> PulpCon is an annual event where Pulp developers and contributors come
>> together to discuss short and long-term project goals, deep dive into new
>> and developing features, and make time for topics that need more attention
>> than an email thread or a conventional meeting will allow. The schedule
>> changes every year and is driven by the attendees.
>>
>> Past events have been held in person; however, this year it will be
>> *virtual*.
>>
>> The sessions will take place over 5 half-days - mornings in EST and
>> afternoons in CET. The schedule of sessions will be planned
>> collaboratively. A detailed schedule will be announced on the pulp-dev
>> mailing list as we get closer to the event. Participants are free to attend
>> whichever sessions interest them.
>>
>> At this time we are trying to pick a week that will work best for
>> everyone. Please provide your input here:
>> https://doodle.com/poll/bssf9qpnzei9ypyg
>>
>> Thank you!
>>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] PulpCon 2020 - save the date and vote for topics!

[Tatiana Tereshchenko]

We are glad to announce that PulpCon will take place during* the week of
September 14th*.
The sessions will be held over *5 half-days*, Mon-Fri mornings in EST and
afternoons in CET.

Currently, we are collecting potential topics to discuss and voting on
them. Please add topics you are interested in to this doc
<https://hackmd.io/@pulp/pulpcon2020/> [0] or add your +1 to the existing
ones.

If you would like to present your own work related to Pulp, your own plugin
or any tooling around Pulp, feel free to add your name and project as a
topic. We'll be happy to hear about your experience and allocate a slot for
you in the schedule.

The topic submission and voting will be closed on *August 15, 2020*.

[0] https://hackmd.io/@pulp/pulpcon2020/

On Wed, Jul 1, 2020 at 3:50 PM Tatiana Tereshchenko 
wrote:

> PulpCon is an annual event where Pulp developers and contributors come
> together to discuss short and long-term project goals, deep dive into new
> and developing features, and make time for topics that need more attention
> than an email thread or a conventional meeting will allow. The schedule
> changes every year and is driven by the attendees.
>
> Past events have been held in person; however, this year it will be
> *virtual*.
>
> The sessions will take place over 5 half-days - mornings in EST and
> afternoons in CET. The schedule of sessions will be planned
> collaboratively. A detailed schedule will be announced on the pulp-dev
> mailing list as we get closer to the event. Participants are free to attend
> whichever sessions interest them.
>
> At this time we are trying to pick a week that will work best for
> everyone. Please provide your input here:
> https://doodle.com/poll/bssf9qpnzei9ypyg
>
> Thank you!
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] pulp-2-to-3-migration pins the wrong pulpcore version?

[Tatiana Tereshchenko]

0.2.0b7 is out with the fixed pulpcore version. Please try it out.

Tanya

On Mon, Aug 3, 2020 at 12:11 PM Tatiana Tereshchenko 
wrote:

> It's not intentional, let me fix it.
>
> Tanya
>
> On Mon, Aug 3, 2020 at 11:46 AM Evgeni Golov  wrote:
>
>> Ohai,
>>
>> in
>> https://github.com/pulp/pulp-2to3-migration/commit/43c2f10b9590a9886f2492614c48e527956873c1
>> 2to3
>> <https://github.com/pulp/pulp-2to3-migration/commit/43c2f10b9590a9886f2492614c48e527956873c12to3>
>> got a hard pin on pulpcore 3.4, which means it can't be used with
>> 3.4.1 which is the latest version in the 3.4 branch and what we have
>> currently in Katello packaging.
>>
>> Is this pin intentional? Or should it be >=3.4,<3.5 (or ~= 3.4)?
>>
>> If it's intentional, we'll have to downgrade pulpcore for Katello :(
>>
>> Evgeni
>>
>> --
>> Beste Grüße/Kind regards,
>>
>> Evgeni Golov
>> Senior Software Engineer
>> 
>> Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
>> Handelsregister: Amtsgericht München, HRB 153243,
>> Geschäftsführer: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas
>> Savage
>>
>>
>> ___
>> 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] pulp-2-to-3-migration pins the wrong pulpcore version?

[Tatiana Tereshchenko]

It's not intentional, let me fix it.

Tanya

On Mon, Aug 3, 2020 at 11:46 AM Evgeni Golov  wrote:

> Ohai,
>
> in
> https://github.com/pulp/pulp-2to3-migration/commit/43c2f10b9590a9886f2492614c48e527956873c1
> 2to3
> 
> got a hard pin on pulpcore 3.4, which means it can't be used with
> 3.4.1 which is the latest version in the 3.4 branch and what we have
> currently in Katello packaging.
>
> Is this pin intentional? Or should it be >=3.4,<3.5 (or ~= 3.4)?
>
> If it's intentional, we'll have to downgrade pulpcore for Katello :(
>
> Evgeni
>
> --
> Beste Grüße/Kind regards,
>
> Evgeni Golov
> Senior Software Engineer
> 
> Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
> Handelsregister: Amtsgericht München, HRB 153243,
> Geschäftsführer: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas
> Savage
>
>
> ___
> 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] Draft Community Demo - Your Opinion Please

[Tatiana Tereshchenko]

For "Which Pulp 2 plugins do you use?"

 - Is the OSTree plugin left out on purpose? I heard questions/concerns
from the Fedora Core OS community about missing OSTree plugin in Pulp3 for
mirroring their content. Having it in the list helps to provide more
information about how widely it's used.
 - We know that some of our contributors have their own plugins, which may
or may not be open sourced and which they use within their company. Maybe
it's worth adding "my own plugin" or something like that. In
combination with questions about upgrading to Pulp 3, it will help to gauge
how much focus the Migration plugin needs to have with regards to
the plugin writers.

Thanks for working on this,
Tanya


On Mon, Jul 27, 2020 at 1:48 PM Melanie Corr  wrote:

>
> Hey Ina,
>
> Thanks for reviewing.
>
> Ar Luan 27 Iúil 2020 ag 12:32, scríobh Ina Panova :
>
>> Can we add a follow up question to: "To what extent have you tried Pulp 3?
>> "
>> "If you are already familiar with Pulp 3 and/or have tried it , what do
>> you like/dislike about?"
>>
>
> That question is in the Pulp 2 section. I didn't enter anything about Pulp
> 3 because if they answer Yes to having installed Pulp 3, they then answer
> the Pulp 3 section. Also. I thought that might be repetitive? But I can
> easily add that if you still think it is a good idea.
>
>>
>> It would be interesting to see what users find beneficial and are excited
>> about (including feature set, workflows, installation, etc) or on the
>> contrary what in their opinion has gotten worse or they do not see value in
>> certain areas.
>>
>
> Can I just clarify that this would be a question to ask people who use
> Pulp 2?
>
>>
>> 
>> 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 Fri, Jul 24, 2020 at 8:07 PM Melanie Corr  wrote:
>>
>>>
>>>
>>> Ar Aoine 24 Iúil 2020 ag 18:24, scríobh Bryan Kearney <
>>> bkear...@redhat.com>:
>>>
 On 7/24/20 12:59 PM, Melanie Corr wrote:
 > I just saw the email subject. Total mislabel on my part :-O
 > Demo! I meant survey. Luckily it is just the draft.
 > https://forms.gle/aynaM4d4wX5Aterz5

 Can the questions like

 Which Pulp 3 plugins do you use?


 be a selection so that you can run percentage based analysis on it and
 not have to
 deal with cleaning up the answers.

>>>
>>> They can and they are now. Thanks for pointing that out.
>>>

 -- bk


>>>
>>> --
>>>
>>> Melanie Corr, RHCE
>>>
>>> Community Manager
>>>
>>> Red Hat 
>>>
>>> Remote, Ireland
>>>
>>> mc...@redhat.com
>>> M: +353857774436 IM: mcorr
>>> 
>>>
>>> ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>>
>
> --
>
> Melanie Corr, RHCE
>
> Community Manager
>
> Red Hat 
>
> Remote, Ireland
>
> mc...@redhat.com
> M: +353857774436 IM: mcorr
> 
>
> ___
> 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] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Distribution Tree model changes
   -

  https://github.com/pulp/pulp_rpm/pull/1782
  -

   3.5 branching/release once DistTree change is merged
   -

   UpdateCollection model fixes and uniqueness - in progress


Pulp 2:

   -

   https://pulp.plan.io/issues/7141 - closed as works for me, but
   continuing to investigate with Katello devs to find a different reproducer


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:
Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

AI review

   -

   ddavis to update 7096  with more
   explanation
   -

   Bmbouters to add comment to 7095 
   -

   Ppicka/dkliban to investigate 5847 
   (fix merged)


Pulp 3:

   -

   import/export
   -

  Natural-keys change waiting on 3.5 branch
  -

  UpdateCollection is going to be A Pain
  
  -

   3.5 compatible release
   -

  Kickstart-model-changes necessary before pulp_rpm 3.5 can happen
  -

  3.4.z compatible with pulpcore 3.5 - releasing today


Pulp 2:

   -

   smart proxy sync issue with mismatching checksum types
   https://access.redhat.com/solutions/5224911
   -

  ttereshc to review the pulp part
  -

   https://pulp.plan.io/issues/7141
   -

  https://github.com/pulp/pulp_rpm/pull/1772
  -

  dkliban has a PR to fix this and then investigate how users will fix
  their existing installs. Either as part of ‘force’ sync or a separate
  script.


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Cherry pick processor

[Tatiana Tereshchenko]

In RPM plugin we use it quite happily.
I guess it depends on the scale and the amount of PRs which might be
problematic and create conflicts.

I'm ok to cherry-pick manually, if it's decided for the cherry-pick
processor to be retired. The load is not high at the moment.

Tanya

On Fri, Jul 10, 2020 at 9:24 PM Robin Chan  wrote:

> I can't speak to the work delta between the existing processor and doing
> them manually, but maybe we can initiate a conversation about this and
> other challenges with cherry picking and building with the build team?
>
> Robin Chan
>
> She/Her/Hers
>
> Satellite Software Engineering Manager - Pulp
>
> Red Hat 
>
> IRC: rchan
>
> Red Hat respects your work life balance. Therefore there is no need to
> answer this email out of your office hours.
> 
>
>
>
> On Fri, Jul 10, 2020 at 2:48 PM Brian Bouterse 
> wrote:
>
>>
>>
>> On Fri, Jul 10, 2020 at 1:34 PM David Davis 
>> wrote:
>>
>>> As creator of the cherry pick processor, I'd like to propose we ditch
>>> it. It requires a lot of upkeep which doesn't really save us time over just
>>> doing the cherry picks ourselves. Also, it often fails because it cannot
>>> make intelligent decisions when there are merge conflicts.
>>>
>>> Instead what I'd propose is that we do cherry picks at release time. We
>>> do z-releases infrequently and they are usually for a particular
>>> stakeholder so we usually know which issues the stakeholder needs and can
>>> cherry pick these changes ourselves before we do a release. We can also
>>> continue using the "Needs Cherry Pick" labels to help us remember issues we
>>> want to include in a z-release later on.
>>>
>>> Overall, I think disabling it is the best path forward but I'm also
>>> interested in any feedback people may have to improve the cherry pick
>>> processor.
>>>
>> I agree with you. Also if we do keep something like this we probably
>> should use one that is already made, e.g. gerritt.
>> https://www.gerritcodereview.com/ +1 to for now retiring it.
>>
>>
>>> 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] AccessPolicy Model Advice ... input needed

[Tatiana Tereshchenko]

+1 to idea 1 since the URLs seem to me more stable than class paths. We
should not change REST API much but potentially can refactor code in some
ways.

One nitpick, maybe the `viewset` field should have a more generic name,
since we don't use viewsets exclusively, we also have separate views, e.g.
for orphan cleanup or status.
I don't have good ideas though... `endpoint`? (though it's not a full
endpoint), `guarded_view_obj`? `view_object`? `view`? :)

On Tue, Jul 14, 2020 at 2:21 AM Dennis Kliban  wrote:

> Pulp 2 users would definitely be familiar with describing policies in
> terms of urls. The Pulp 3 REST API already uses the pulp_href field as the
> primary identifier. You should implement idea 1.
>
> On Mon, Jul 13, 2020, 5:45 PM Brian Bouterse  wrote:
>
>> I need some design input. To store AccessPolicy data in the DB I think we
>> want one Model where each instance is the access policy for a given
>> viewset. I think this would be better than one Model per Viewset which
>> would generate N tables for N viewsets with 1 instance of each which would
>> be very strange and inefficient.
>>
>> So let's assume we have a simple definition like the one below. Each
>> instance stores the policy for one viewset.
>>
>> class AccessPolicy(BaseModel):
>> data = JSONField()
>>
>> So what second field can I add to this that would allow me to relate an
>> instance of this model to a viewset. For example the FileRemoteViewset
>> here:
>> https://github.com/pulp/pulp_file/blob/de638519fc02d588f403db4c5cfcca7552543c50/pulp_file/app/viewsets.py#L116
>>
>> Idea 1: Add a viewset = CharField(). Have it store values as URLs, e.g.
>> /pulp/api/v3/remotes/file/file/.
>> Idea 2: Add a viewset = CharField(), and have it store values as
>> classpaths, e.g. 'pulp_file.app.viewsets.RemoteFileViewset'.
>>
>> I think Idea 1 makes the most sense because that's how our users think of
>> it. I can't think of a good alternative. What do you think makes the most
>> sense? What alternative ideas should we consider?
>>
>> If you have feedback please share it. I need to start into something to
>> get it going tomorrow even if it's just Idea 1 for lack of an alternate
>> proposal.
>>
>> Thanks,
>> Brian
>> ___
>> 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] RPM plugin meeting notes

[Tatiana Tereshchenko]

AI review

   -

   AI: dkliban will add commentary to issue
   -

  https://pulp.plan.io/issues/7046#note-3

Pulp 3:

   -

   Distribution tree copy bug https://pulp.plan.io/issues/7046
   
   -

  High prio
  -

   “retain_package_versions”
   -

  PR review needed https://github.com/pulp/pulp_rpm/pull/1752
  -

   RepoMetadataFIle issue (potentially relative_path problem)
   https://pulp.plan.io/issues/5847
   -

  High prio, needs to be resolved very soon
  -

  Need to come up with a ‘clever’ workaround, not to affect db and
  further migraitons
  -

  AI: ppicka to discuss investigation with interested parties, soon
  -

   Recursive copy
   -

  Copy prepared (depends on retain old PR)
  -

   Review next week for import/export natural-keys
    - please
   review and send comments/questions
   -

   It looks like a repo can have more than one distribution tree? How does
   this work?
   -


  
https://github.com/pulp/pulp_rpm/blob/546da71b4b7bb8fc2af57213b3249a409880401c/pulp_rpm/app/models/distribution.py#L89-L96
  -

  Should be only one
  -

  AI: daviddavis to file an issue


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:
Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Pulp 2.21.3 Beta is delayed

[Tatiana Tereshchenko]

Pulp 2.21.3 Beta 1 is delayed until all issues are resolved.

There were CI issues which are mostly resolved.
There are also some test failures which require investigation.

I'll update the thread when release is unblocked.

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

Re: [Pulp-dev] Removal of https://repos.fedorapeople.org/pulp/pulp/fixtures/

[Tatiana Tereshchenko]

Hi David,

I noticed today that not all fixtures rehomed. Is it intentional? no
docker, puppet, ostree.
They are used in pulp 2 functional tests. Maybe we can move them to the new
location as well until we reach EOL for pulp 2 or until we are sure that no
new releases (e.g. with critical/security bugs) will be out.

Thanks,
Tanya

On Tue, Jun 30, 2020 at 7:14 PM David Davis  wrote:

> This is the final reminder that the fedorapeople.org pulp fixtures are
> scheduled to be removed this week. If anyone needs more time, please reach
> out to me.
>
> David
>
>
> On Tue, Jun 9, 2020 at 11:04 AM David Davis  wrote:
>
>> As part of our effort[0] to rehome fixtures to
>> https://fixtures.pulpproject.org/, we plan to remove the old fixtures at
>> https://repos.fedorapeople.org/pulp/pulp/fixtures/ on July 1st unless
>> there are any objections.
>>
>> [0] https://pulp.plan.io/issues/6638
>>
>> 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] PulpCon 2020: Call for Participation

[Tatiana Tereshchenko]

PulpCon is an annual event where Pulp developers and contributors come
together to discuss short and long-term project goals, deep dive into new
and developing features, and make time for topics that need more attention
than an email thread or a conventional meeting will allow. The schedule
changes every year and is driven by the attendees.

Past events have been held in person; however, this year it will be virtual.

The sessions will take place over 5 half-days - mornings in EST and
afternoons in CET. The schedule of sessions will be planned
collaboratively. A detailed schedule will be announced on the pulp-dev
mailing list as we get closer to the event. Participants are free to attend
whichever sessions interest them.

At this time we are trying to pick a week that will work best for everyone.
Please provide your input here: https://doodle.com/poll/bssf9qpnzei9ypyg

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

[Pulp-dev] Pulp 2.21.3 Dev Freeze

[Tatiana Tereshchenko]

The code for 2.21.3 is frozen as of yesterday. The list of fixes can be
found here [0].
The Beta build is expected on June 30, 2020, see the release schedule [1].

[0] https://pulp.plan.io/issues?query_id=59
[1] https://pulp.plan.io/projects/pulp/wiki/2213_Release_Schedule

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

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Kickstarts copy issue https://pulp.plan.io/issues/7046
   -

  Lots of discussion
  -

  AI: dkliban will add commentary to issue
  -

 https://pulp.plan.io/issues/7046#note-3
 -

   Retain old count
   -

  Basically done - writing a test, might rename the field
  -

 https://github.com/pulp/pulp_rpm/pull/1752
 -

AI: feedback is needed for the naming of user facing
configuration parameter
-

  Need to do a little more thinking about whether we can share an
  install of the extension with Katello or if we should just dump
the entire
  extension into the database ourselves with raw SQL
  -

 Katello has an RPM that provides it
 -

 If install custom-type via rpm, still need migration to take
 advantage of it
 -

Django can note existence/lack-thereof of a plugin
-

   Comps.xml relations removal and recursive copy
   -

  Copy is in progress, looks good so far
  -

  It’s preferable if all changes go together into one Y release
  -

   Mirrored metadata 
   -

  No time to move this forward
  -

  ttereshc will try to move it forward, had a knowledge/ideas dump from
  dkliban earlier today


Pulp 2:

   -

   2.21.3 - dev freeze today, beta - on Tuesday


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] 2.21.3 release schedule

[Tatiana Tereshchenko]

A 2.21.3 release is being planned with recent fixes. Here [0] is a release
schedule which outlines some tentative dates, starting with a* dev freeze*
on Thursday, *June 25*, 2020  @ 17:00 UTC.
A query with the list of bug fixes to be released will be added to the
release schedule page.

Tanya

[0] https://pulp.plan.io/projects/pulp/wiki/2213_Release_Schedule
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

AI review

   -

   discuss if other relations for comps needs to be removed or only
   packages to groups
   -

   bmbouter to remove  ‘Pulp3 RPM blocker’ tag
   -

   dkliban to try to come up with rough design during the sprint
   https://pulp.plan.io/issues/5200
   -

  started
  -

   dkliban to reach out to productmd dev https://pulp.plan.io/issues/6568
   -

   ttereshc to look at response/patch
   https://bugzilla.redhat.com/show_bug.cgi?id=1743776#c13


Pulp 3:

   -

   Retain old count
   -

  Q: how to install evr_t plugin for postgres?
  -

 Extension vs raw-migration
 -


 
https://github.com/pulp/pulp_ansible/blob/master/pulp_ansible/app/migrations/0004_add_fulltext_search_indexes.py
 -

  Django doesn’t like fields it doesn’t ‘own’
  -

 There exists a read-only extension for django
 -

 Needs to be installed by pulpcore?
 -

If used by one plugin only, it’s better to install as a part of
the plugin
-

see what pulp-ansible is doing :

https://github.com/pulp/pulp_ansible/blob/master/pulp_ansible/app/settings.py#19


-

   Mirrored metadata 
   -

  dkliban to continue working on rough design
  -

   daviddavis working on export of kickstarts
   -

   https://pulp.plan.io/issues/7004 (pulpcore/fixtures) blocks sles auth
   token test


Pulp 2:

   -

   2.21.3
   -

  mainly applicability regression fix
  -

  ttereshc to be a release shepherd


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls
   -

   Needs review
   -

   https://github.com/pulp/pulp_rpm/pull/1725
  -

 dkliban to look at it
 -

  https://github.com/pulp/pulp_rpm/pull/1745
  -

 dalley to look at it


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Katello/Pulp 3 integration meeting notes

[Tatiana Tereshchenko]

Pulp

   -

   Core
   -

  Import/export
  -

 Mostly same as last week
 -

 daviddavis looking into kickstart support
 -

  GroupProgressReport https://pulp.plan.io/issues/6858,  in progress,
  might be done tomorrow if no significant issues appear
  -

  Correlation id logging feature is in progress
  -

   RPM
   -

  SLES remote
  -

 No dedicated remote, just sles_auth_token param, merged, will be
 in 3.5
 -

  Retain N latest packages, in progress
  -

  Removing relations in comps types, does katello use those?
  -

 Package group/environment/category
 -

 AI: follow up on this next week
 -

  Centos8 kickstart publishing bug fix in progress -
  https://pulp.plan.io/issues/6568
  -

   Migration
   -

  0.2.0b3 is out with recent fixes
  -

  0.2.0 items
  https://pulp.plan.io/projects/migration/issues?query_id=158
  -

  Remaining features to add:
  -

 Checksum type for publications, in progress (6813
 )
 -

 SLES remotes
 -

   Certguard
   -

  Releasing 1.0 GA at end of June, scheduled for June 29th


Katello

   -

   Found auth issue with pulp master and binding behavior:
   https://pulp.plan.io/issues/6989
   -

  AI: dkliban to take a peek into bindings
  -

   3.4 pulled into nightly, will be pulled into 3.16
   -

   Finishing up 3.16 stuff:
   -

  Srpm sync skipping
  -

  Incremental update
  -

   Yum migration work ongoing



Top Priorities

   -

   issue with pulp master and binding behavior:
   https://pulp.plan.io/issues/6989
   -

  Not blocking at the moment but soon will become a problem
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Website: moving "Related Tooling" to a sub menu

[Tatiana Tereshchenko]

+1

On Wed, Jun 17, 2020 at 4:03 PM Brian Bouterse  wrote:

> +1
>
> On Wed, Jun 17, 2020 at 10:01 AM Melanie Corr  wrote:
>
>> Hi all,
>>
>> I was wondering if there would be any objections to moving the Related
>> Tooling page under the Pulp 3 drop-down menu?
>>
>> At the moment the Pulp 3 menu contains a page comparing Pulp 2 v Pulp 3,
>> a page dedicated to Pulp 3 Features, a page on Migrating to Pulp 3. I think
>> the Related Tooling page might be a natural fit here.
>>
>> My main motivation for doing this is to gain some space on the navbar to
>> add an "Install Pulp"  menu item, with a page for each of the installation
>> options.
>>
>> Here is a preview:
>>
>> https://melcorr.github.io/pulpproject.org/
>>
>> Here is the PR if you have any comments or reservations:
>>
>> https://github.com/pulp/pulpproject.org/pull/272
>>
>> All +1s and -1s appreciated.
>>
>> All the best,
>>
>> Melanie
>>
>> --
>>
>> Melanie Corr, RHCE
>>
>> Community Manager
>>
>> Red Hat 
>>
>> Remote, Ireland
>>
>> mc...@redhat.com
>> M: +353857774436 IM: mcorr
>> 
>>
>> ___
>> 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] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   comps.xml relation issues
   -

  PR for PackageGroups which removes relations completely
  -

 https://github.com/pulp/pulp_rpm/pull/1745
 -

 Backward incompatible change in REST API
 -

Ok, because it’s a bug fix
-

Likely no usage outside of copy which can handle it without
knowing the relations
-

AI: discuss if other relations for comps needs to be removed or
only packages to groups
-

   Rethinking SLES Remote as a separate Remote
   -

  Maybe it’s not more usable?
  -

  https://github.com/pulp/pulp_rpm/pull/1729#issuecomment-641478315
  -

 Keep one Remote
 -

 Make parameter name specific - sles_auth_token
 -

 Have one rpm specific downloader, don’t call it anything specific,
 so in the future we can add more functionality to it to avoid
the case with
 mutually exclusive downloaders
 -

   Do we still need the ‘Pulp3 RPM blocker’ tag or can we remove it?
   -

  We can remove it - bmbouter will handle it
  -

   Do we have any timeline for https://pulp.plan.io/issues/5200
   -

  dkliban to try to come up with rough design during the sprint
  -

   Client certs w/ Remote (newline problem)
   -

  Need to use at notation (@~/file) not a string for correct process of
  control chars
  -

   CentOS 8 kickstart repo bug - https://pulp.plan.io/issues/6568
   -

  dkliban to reach out to productmd dev


Pulp 2:

   -

   Failed content view deletions
   -

  https://bugzilla.redhat.com/show_bug.cgi?id=1743776#c13
  -

  https://git.io/Jf98f
  -

  AI: ttereshc to look at response/patch


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
   -

  Didn’t have time to cover it, will do it online today or on Monday
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Migration plugin meeting notes

[Tatiana Tereshchenko]

   -

   Issues/stories to triage/prioritise and see who can work on it.
   -

  https://pulp.plan.io/projects/migration/issues?query_id=158
  -

   Brainstorm ideas for the testing strategy. Currently no tests are
   written partially because we never clean the database and tests affect each
   other.
   -

  dkliban to write a task to clean up after each test -
  https://pulp.plan.io/issues/6963
  -

  ttereshc to come up with scenarios and prep pulp 2 data
  -

   How can QE know which pulp-2to3-migraiton version is currently
   integrated in Katello? How to avoid filing the known issues when downstream
   testing starts.
   -

  rochabruno to organize a discussion with katello and pulp dev to come
  up with a process.


Open PRs https://github.com/pulp/pulp-2to3-migration/pulls
Un-triaged bugs https://pulp.plan.io/projects/migration/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

AI review

   -

   dalley to email amatej w/r to the drpm library support
   -

   dkliban takes AI to write up cert-getting ticket
   -

   ppicka to talk to dkliban and file an issue about suse auth token
   -

   ttereshc to file an issue about import/export
   -

  https://pulp.plan.io/issues/6815
  -

   ipanova to review mirror list support
   -

  Started, needs more input from the team
  -

   ipanova to reply to user on the pulp-list about upgrade issues from rc
   to the latest ga


Pulp 3:

   -

   Features
   -

  SUSE repos, auth token
  -

 https://pulp.plan.io/issues/6729
 -

 Agreed to have a separate Remote and require auth token
 -

 No new problems for migration but need to add the support
 -

 Need to discuss with Katello
 -

  Retain old count - planning
  -

  DRPM support NOT needed - Katello is dropping the feature with 4.0/4.1
  -

  Mirrorlist support
  -

 Design proposal:
 https://github.com/pulp/pulp_rpm/pull/1690/files#r431910746
 -

   Bugs
   -

  Dep solving for katello https://pulp.plan.io/issues/6820


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30


Sprint planning prep:

   -

   Dep solving for katello https://pulp.plan.io/issues/6820 - Daniel or
   Grant
   -

   SUSE auth - Pavel
   -

   Retain old count - design/planning - Daniel (if priorities permit)
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   AI review
   -

   3.3.2 is out with the upgrade fix
   -

   Features
   -

  SUSE repos, auth token
  -

  Retain old count 5367 
  -

 EVR comparison
 -

Ggainey’s cut at it


-

Ian Ballou started w/the above, but I believe he has a better
answer now?
-

 Ggainey to add some interesting edge cases
 -

See 5367#note-11  and
5367#note-12 
-

 Need a proper planning for this feature
 -

  Mirror metadata/relative path timeline
  -

 daviddavis to ask jsherrill about the pulpcore version
 -

 jsherrill: need this by august (pulpcore 3.5 or 3.6)
 -

  Import/export
  -

 Need to add all advisory models to the IMPORT_ORDER
 -

 Distribution trees are not handled properly yet but it’s a known
 gap
 -

   Tests
   -

  Coverage
  -

 Hook for PRs in place
 -

  High prio tests are identified and being worked on
  -

 as of now, only ‘copy’ tests missing from prio identified
 -

  This is the last week of test-only work
  -

   Docs
   -

  Tested in CI, thanks Fabricio
  -

  Copy API docs are merged
  -

   AI:
   -

  dalley to email amatej w/r to the drpm library support
  -

  dkliban takes AI to write up cert-getting ticket
  -

  ppicka to talk to dkliban and file an issue about suse auth token
  -

  ipanova to review mirror list support
  -

  ttereshc to file an issue about import/export
  -

  ipanova to reply to user on the pulp-list about upgrade issues from
  rc to the latest ga


Pulp 2:

   -

   2.21.2 is out
   -

  Except docs, travis issue


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:
Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] pulpcore 3.4.0 release scheduled for May 27th

[Tatiana Tereshchenko]

Hi Justin,

I think because we are trying to do time-based releases, we are not
aligning anything upfront. Just close to the release time, blockers are
being added to the release milestone, for the rest items milestone is set
at a release time.
To see what will end up in the upcoming release one can look at issues at
MODIFIED state. Here is the query https://tinyurl.com/y7ry4xoy (it excludes
installer and CI work, so it's easier to spot pulp features and bug fixes).

Maybe we should create a custom query in redmine for all projects -
something like "Upcoming feature release". The query will just include all
issues (except tests and pulp2) in MODIFIED state (though some bug
fixes might be released earlier, if Z release is planned).
What do you all think?

Tanya

On Wed, May 20, 2020 at 3:08 AM Justin Sherrill  wrote:

> Is it normal for things added/fixed between 3.3 and 3.4 to not show up in
> that version tracker?
>
> The item i'm thinking about is https://pulp.plan.io/issues/6591
> On 5/19/20 8:55 PM, Dennis Kliban wrote:
>
> Pulpcore 3.4.0 is scheduled to be released on May 27th. There are
> currently 3 issues that have been proposed as blockers for this release[0].
> Please respond to this thread with any other issues that should potentially
> be addressed in this release.
>
> [0] https://pulp.plan.io/versions/88
>
> ___
> Pulp-dev mailing 
> listPulp-dev@redhat.comhttps://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] Consolidating plugin listing on pulpproject.org for user clarity?

[Tatiana Tereshchenko]

Hi Brian,

I agree with the problems identified.
I'm concerned that the same plugins have a different set of features
in Pulp 2 and Pulp 3, e.g, pulp_rpm. Having it just marked as compatible
with both Pulp 2 and Pulp 3 might create an assumption that the same
features are available for both Pulp 2 and Pulp 3.
Some plugins are separated or renamed, it's hard to mark them compatible or
not, e.g. Pulp 3 pulp_file should be marked as a part of Pulp 2 pulp_rpm?
Pulp 2 pulp_docker - a part of pulp_container in Pulp 3?

I wonder if we should keep pulp 2 and pulp 3 plugins separate, maybe on the
same page but not in the same table?
Alternatively, many footnotes with clarifications might help.

Thanks,
Tanya

On Wed, May 13, 2020 at 5:37 PM Brian Bouterse  wrote:

> Melanie,
>
> I'm sending via pulp-dev for more visibility, but I wanted to see what you
> think specifically. Recently a user gave us feedback via an issue on Pulp 3
> pain points for usage [0]. A lot of it is code and docs, and we're working
> to address those, but the last bullet says:
>
> "On the project page you tells that Pulp can manage plainty of repo type,
> but in fact if you take a fresh version only few plugins are working. Is
> there at least a compatibility/status matrix explaining that?"
>
> There are two issues we identified at the installer meeting. 1) The
> homepage claims one set of plugins that are pulp2 compatible but doesn't
> clearly state they are for pulp two.2) the pulp3 plugin table is not on the
> home page.
>
> What do you think about consolidating the "plugin list" on the homepage
> and the pulp3 plugins page into one table with two new columns "Pulp 2
> compatible" and "Pulp 3 compatible" with X's or check mark icons in the
> cells where that compatibility exists?
>
> What do others think also?
>
> [0]: https://pulp.plan.io/issues/6658
>
> Thanks,
> Brian
>
> ___
> 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] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   https://pulp.plan.io/issues/6699
   -

  Core change
  -

  bmbouter to put a complete proposal
  -

   Release 3.3.1 is out, 3.3.2 is planned
   -

   Features
   -

  Estimate for mirroring metadata https://pulp.plan.io/issues/6353
  -

 Relative_path needs to be addressed to do this
 -

 Somewhere around 1-3 staff months/2 months.
 -

  Remaining features for Katello 4.0
  https://pulp.plan.io/projects/pulp_rpm/issues?query_id=155
  -

 File task to skip drpms during sync
 -

 Daniel email amatej w/r to the drpm library support
 -

   Tests
   -

  Coverage
  -

 Hook and markdown form in WIP https://pulp.plan.io/issues/6706
 - RHEL repos
  -

 Users reporting problems only seen when consuming RHEL-CDN repos
 -

 Add debug-cert to secrets, have a nightly test against RHEL
 -

 Needs a test-specific/pulp-bot-owned cert-ticket opened
 -

 ttereshc takes AI to write up issue
 -

 dkliban takes AI to write up cert-getting ticket
 -

  Upgrade tests
  -

 Pulp_rpm_prerequisites CI tests upgrade, but it not test database
 migration (as it does not have data)
 -

 https://hackmd.io/Bz6cLGRCSMmnCLDvhnBWtg?both
 -

 Have upgrade tests with data in the db
 -

 Potentially run in CI for https://github.com/pulp/pulp-oci-images/
 -

 AI to write a task
 -

  SSL cert test https://pulp.plan.io/issues/6735
  -

 Needs “RHEL repos” above, to really have tests
 -

   Docs
   -

  RPM copy API documentation PR:
  https://github.com/pulp/pulp_rpm/pull/1706
  -

  REST API docs are out of date, don’t forget to push fresh api.json if
  you make any changes affecting it
  -

 (dalley) I’m doing this in the copy docs PR
 -

 (david) I am never going to remember to do this. Can we add
 https://pulp.plan.io/issues/5541 to next sprint?
 -

Discuss at open floor
-

   Priorities


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

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
  -

 https://github.com/pulp/pulp_rpm/pull/1687
 -

 It seems like only one functional test left to be done
 -

   Tests
   -

  Ran into travis failure due to test importing directly from pulpcore
  -

 6682
 

 opened to update plugin-writers-guide to help avoid in the future
 -

  Coverage of features (internal doc at the moment)
  -

 Needs a “last revised” somewhere obvious
 -

 It would be nice to keep a list like this somewhere ‘public’
 -

Example: A markdown+1/rst doc in the project, with a list of
testcases and the use-case they are testing
-

Would get “out of sync” over time and need regular revisiting,
but would be a starting-point for a) tracking coverage, b)
publically/transparently
-

Automation to prompt (not require) dev to update test list when
test files are modified? (only if it would be simple, like
“touch any file
in this subdirectory, drop a comment) +1
-

   Kickstart issues
   -

  All known ones are filed
  -

 https://pulp.plan.io/issues/6629 - can’t remove a kickstart repo
 -

Need to check if it was the main repo or the sub repo which is
being removed
-

@dkliban to comment
-

 https://pulp.plan.io/issues/6683 - migrated kickstart repo missing
 treeinfo file after first sync by pulp 3
 -

   Docs
   -

  Copy API docs are close to be ready
  -

  They don’t block 3.3.1, docs can be published asynchronously
  -

   Priorities
   -

  Continue on tests and review of the feature PRs
  -

  Next sprint - start looking into major features for the Katello
  3.18/4.0 release
  -

 @ttereshc to prepare a list of features that needs to be done for ^


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp 3 CLI MVP

[Tatiana Tereshchenko]

+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 the commands which have the same structure in different
plugins.
It also makes it visually clear that I work with a specific plugin, in
comparison to when the plugin name is somewhere in the 3rd/4th place.
It will also allow not to guess in commands like the `pulp repositories rpm
rpm`  which one is the plugin name and which one is a repo type.

+1 for
pulp rpm content packages
pulp rpm repositories rpm
pulp rpm repositories mirror
...

On Wed, May 6, 2020 at 7:58 PM Dennis Kliban  wrote:

> On Wed, May 6, 2020 at 12:30 PM David Davis  wrote:
>
>> Matthias and I met today to go over some plans for a prototype. I wrote
>> some notes[0] down. As part of the prototype, we'd propose two deliverables
>> (one this week and one next week):
>>
>> 1. A set of ~2-3 click commands that use the bindings to interact with
>> Pulp
>> 2. Some openapi-generator templates that will be able to generate such
>> commands from the schema
>>
>> There is a question we had about how the commands for typed resources
>> will be structured in the CLI. To illustrate with two endpoints:
>>
>>
> We should call the command 'pulp' instead of pulp-cli.
>
>
>> # rpm.package content (/pulp/api/v3/content/rpm/packages/):
>> - pulp-cli rpm content packages ...
>> - pulp-cli content rpm packages ...
>> - pulp-cli rpm packages content ...
>> - ???
>>
>
> I was thinking we should structure the commands similar to the URLs in the
> REST API.
>
> pulp content rpm packages
>
>
>>
>> # file.file repositories (/pulp/api/v3/repositories/file/file/):
>> - pulp-cli file repositories file ...
>> - pulp-cli repositories file file ...
>> - pulp-cli file file repositories ...
>> - ???
>>
>> pulp repositories file
>
> Plugins that provide multiple types of the same resource would need to be
> more descriptive. Though I can see a practical reason for requiring all
> resources to be that descriptive.
>
> pulp repositories rpm rpm
> pulp repositories rpm mirror
>
>
>
>> [0] https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig?view#Prototype
>>
>> David
>>
>>
>> On Thu, Apr 30, 2020 at 1:42 PM David Davis 
>> wrote:
>>
>>> Today we met to discuss some ideas for a technical design for how the
>>> CLI would work. Here's a copy of our notes:
>>>
>>> https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig#Technical-discussion
>>>
>>> And there is a rough design in the document as well:
>>>
>>> https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig#Design
>>>
>>> I have also entered the CLI user stories from our meeting last week into
>>> redmine under the Pulp CLI project:
>>>
>>> https://pulp.plan.io/versions/93
>>>
>>> And I've filed a user story that we talked about today that would handle
>>> sync, publish, and distribution of repos. Feedback welcome:
>>>
>>> https://pulp.plan.io/issues/6626
>>>
>>> Matthias and I are planning to meet next week to look at creating a
>>> proof of concept that would provide 2-3 commands. If anyone is interested
>>> in joining us, please let me know and I can add you.
>>>
>>> David
>>>
>>>
>>> On Tue, Apr 28, 2020 at 8:06 AM David Davis 
>>> wrote:
>>>
 I've also started working on some questions about how the CLI will
 work. Feel free to add some of your own:

 https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig?view#Technical-discussion

 David


 On Tue, Apr 28, 2020 at 8:05 AM David Davis 
 wrote:

> I have set up a meeting to discuss the CLI technical design. Below are
> the details. I think a video conference might be easier for technical
> discussion but am open to consider meeting on #pulp-meeting again.
>
> URL: https://meet.google.com/vgx-bzbb-wnh
> Date/time: April 30, 2020 at 9:00am ET (1pm UTC)
>
> David
>
>
> On Fri, Apr 24, 2020 at 10:29 AM David Davis 
> wrote:
>
>> Today we met in #pulp-meeting on freenode to discuss the user stories
>> for a Pulp 3 CLI MVP. The document with the user stories is available
>> below. I'd like to ask for any feedback from users or plugin writers.
>>
>> The goal of the CLI MVP is to cover the pulp_file happy path (sync,
>> publish, distribute) and make it possible for plugin writers to generate
>> and write their own commands. I'm imagining that plugins will release 
>> their
>> own sets of CLI commands after we complete the initial MVP.
>>
>> https://hackmd.io/aH9RqAS_TrGyxoi1UGRgig
>>
>> Feedback is welcome. I plan to enter these user stories into redmine
>> next week.
>>
>> David
>>
> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> 

[Pulp-dev] Migration plugin meeting notes

[Tatiana Tereshchenko]

   -

   In progress
   -

  [ipanova] Remotes tracking
  -

 https://github.com/pulp/pulp-2to3-migration/pull/145/
 -

  [dalley] Progress report planning
  -

 Discussion happened on https://pulp.plan.io/issues/6590
 -

 Dalley to file a new issue about detailed progress reporting and
 start discussion on pulp-dev
 -

  [ttereshc] started on errata issue https://pulp.plan.io/issues/6531
  -

   Priorities
   -

  One migration at a time https://pulp.plan.io/issues/6639
  -

 Needs to be solved in the pulpcore 3.3.1 timeline
 -

  simple/complex plan https://pulp.plan.io/issues/6516
  -

  Publication tracking https://pulp.plan.io/issues/6376



Open PRs https://github.com/pulp/pulp-2to3-migration/pulls
Un-triaged bugs https://pulp.plan.io/projects/migration/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] New pulpcore release (3.3.1?)

[Tatiana Tereshchenko]

+1 for 3.3.1

Could those be included?
1. Adding TaskGroup to the plugin API
https://github.com/pulp/pulpcore/pull/677
2. Adding all_task_dispatched field to indicate that no more tasks will
spawn https://github.com/pulp/pulpcore/pull/682

They may sound like features/improvements however, without both, task
groups are close to unusable.
Katello integrates with pulpcore 3.3 and migration plugin which uses task
groups.
Migration plugin can workaround the first problem by importing directly
from the pulpcore.
Without #2, there is no way to know whether all tasks have been dispatched
or not, it means no way to know the overall state of the migration.

To my knowledge, task groups are used by import/export (which is in tech
preview) and by the migration plugin. So those PRs seem to me like a
low-risk change.

Any thoughts?

Thanks,
Tanya

On Mon, May 4, 2020 at 8:41 PM David Davis  wrote:

> I think Katello would like a few of the bug fixes from the past couple
> weeks. Would a 3.3.1 release make sense? Would anyone have time this week
> to work on it?
>
> 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

Re: [Pulp-dev] Moving to travis-ci.com

[Tatiana Tereshchenko]

Thank you! +1 for pulp_rpm to migrate.

Tanya

On Tue, May 5, 2020 at 1:38 PM David Davis  wrote:

> I migrated over pulp_ansible, pulp-smash, and pulp-ci. I think at this
> point, these are the only pulp 3 repos still on travis-ci.org:
>
> - pulp_rpm
> - pulp_python
> - pulp_gem
>
> If any of the plugins want me to migrate these over, please let me know.
>
> David
>
>
> On Mon, May 4, 2020 at 7:12 AM Ina Panova  wrote:
>
>> +1 to move pulp3 projects.
>> Thank you for taking care of this.
>>
>>
>> 
>> 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 Fri, May 1, 2020 at 9:22 PM Brian Bouterse 
>> wrote:
>>
>>> Thank you for porting these! I'm +1 to moving all Pulp3 projects with an
>>> ack from each plugin team first.
>>>
>>> I can ack for pulp_ansible, if it's possible to move that one please.
>>> Let me know how I can help also.
>>>
>>> On Wed, Apr 29, 2020 at 6:43 AM David Davis 
>>> wrote:
>>>
 Out of curiosity this morning I tried migrating pulp_file over to
 travis-ci this morning and it worked. So then I went back and tried
 pulp-certguard and that worked as well. So now both projects are on
 travis-ci.com.

 I think these are the main projects still on travis-ci.org:
 - pulp_ansible
 - pulp_rpm
 - pulp
 - pulp_python
 - pulp_gem
 - pulp-smash
 - pulp-ci
 - Pulp-2-Tests
 - pulp_ostree
 - crane

 Should we move these projects over as well? Maybe just the Pulp 3 ones?
 I'd also like confirmation from plugin teams though before we move their
 repos over.

 David


 On Thu, Apr 23, 2020 at 11:01 AM Daniel Alley 
 wrote:

> I kid, but it is a funny situation
>
> On Thu, Apr 23, 2020 at 10:01 AM David Davis 
> wrote:
>
>> LOL.
>>
>> To answer your question though, we're kind of in a holding pattern
>> right now. There are some missing features like sharing jobs between
>> workflows and restarting jobs within workflows that we're hoping Github
>> Actions adds. Maybe we can revisit though at our next CI meeting.
>>
>> David
>>
>>
>> On Thu, Apr 23, 2020 at 9:46 AM Daniel Alley 
>> wrote:
>>
>>> travis-ci.org is broken

>>> migrating away from travis-ci.org is also broken

>>>
>>> So, uh, when will github actions be ready xD
>>>
>>> On Thu, Apr 23, 2020 at 8:40 AM David Davis 
>>> wrote:
>>>
 I wrote to Travis support yesterday and they responded (below). I
 tried again this morning and it's still broken. I'll wait a few more 
 days
 unless anyone objects.









 *Thank you for reaching out! We are sorry about the issue that you
 are having.We are currently aware of a bug related to migrating
 repositories from travis-ci.org  to travis-ci.com
  and our Engineering Team is working on this 
 issue to
 be solved as soon as possible.Until the fix is deployed, we would 
 kindly
 suggest you build your projects on travis-ci.org
 .Thank you for your patience and once again we 
 are
 extremely sorry about the issue.*

 David


 On Thu, Apr 23, 2020 at 8:34 AM Brian Bouterse 
 wrote:

>
>
> On Wed, Apr 22, 2020 at 3:48 PM David Davis 
> wrote:
>
>> Ok, I agree. I tried to migrate certguard to travis-ci.com and
>> hit a 500 error. Looks like we're not alone both in status updates 
>> not
>> being reported from travis-ci.org and having problems trying to
>> migrate:
>>
>>
>> https://travis-ci.community/t/github-status-not-posted-on-commits-on-repositories-using-legacy-service-integration/7798/16
>>
>> I'll wait a day for Travis support to respond but I think we
>> could also just enable the repos and start from scratch in
>> travis-ci.com. I think we'd lose past build information and
>> settings though if we don't migrate.
>>
> This also sounds good to me. If you want to tag-team via irc or
> video we can do that.
>
>
>> David
>>
>>
>> On Wed, Apr 22, 2020 at 3:21 PM Brian Bouterse <
>> bmbou...@redhat.com> wrote:
>>
>>> OK now more than an annoyance, travis-ci.org not notifying
>>> github is preventing certguard from merging without me disabling 
>>> the CI
>>> check  :(
>>>
>>> I think we need to do this asap.
>>>
>>> On Wed, Apr 22, 2020 at 9:21 AM 

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   3.3.0 is released
   -

   From now on, add functional tests at the same time as features
   -

  At least a happy path
  -

   List of RPM features to test and/or to ensure are present in the docs
   -

  AI: Please review areas you are familiar with and which you think
  deserve a happy-path test or a note in the docs
  -

   Reminder: relative path problem still unsolved, another meeting on
   Monday to discuss
   -

   Features
   -

  Mirrorlist support from @lmjachky
  -

 https://pulp.plan.io/issues/6225
 -

 In progress https://github.com/pulp/pulp_rpm/pull/1690
 -

  config.repo feature from @lieter
  -

 There is a problem with determining the name of the public key file
 -

AI: dkliban will send a note to list about needing to
strengthen the interface for signing services. Will for
now provide docs
that recommend using a specific name for a public key.


Pulp 2:

   -

   All 2.21.2 items are done.
   -

  dalley is taking care of it instead of dkliban
  -

   Need to reply to Katello
   -

  CentOS 8 kickstarts  https://pulp.plan.io/issues/6470
  -

  can't be fixed in pulp2, will be fixed in pulp 3, dkliban to reach
  out to Katello


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30



Sprint planning prep:

   -

   planned to be worked on during sprint and estimated time for each
   -

  ppicka - tests planning/implementation (full time)
  -

  dkliban - kickstarts issues (1 day)
  -

  dalley - pulp 2 release (1 day)
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] fedorapeople.org fixtures

[Tatiana Tereshchenko]

I personally prefer to keep fixtures published somewhere, fedorapeople or
not, doesn't matter.
It is convenient to refer to in situations which are not related to feature
development or functional testing:
 - when one files a redmine issue and provides steps to reproduce
 - when one works with, say, Katello, or any other related project and
needs to try/test something quickly
 - when one tries to help some user remotely and ask to sync this or that.

It's not a strong reason, it's just a matter of convenience, in my opinion.

Tanya


On Wed, Apr 29, 2020 at 8:31 AM Quirin Pamp  wrote:

> I have grown used to always running the fixtures container locally in my
> pulplift boxes using the pfixtures command (essential when working on new
> fixtures).
>
> This command could be made a bit more flexible (right now it always runs
> in the foreground and always uses the latest container image from quay.io),
> but those would be trivial changes.
>
> As a result, I personally have no problems with retiring the fixtures on
> fedorapeople.org completely.
>
> The disadvantage of the approach is that it requires either downloading
> the (pretty large) fixtures container from quay.io, or building it
> locally.
>
>
> Quirin (quba42)
> --
> *From:* pulp-dev-boun...@redhat.com  on
> behalf of David Davis 
> *Sent:* 28 April 2020 22:19:23
> *To:* Pulp-dev 
> *Subject:* [Pulp-dev] fedorapeople.org fixtures
>
> Our Jenkins jobs for Pulp 2 are disabled and that also includes the job
> that builds the fixtures and publishes them to fedorapeople.org[0]. With
> the new pulp-fixtures container[1], it's less essential that we have
> fixtures published somewhere. I think the two options we have are to either
> retire the fedorapeople.org fixtures and remove them, or to move where
> the job runs and possibly the place where they are hosted.
>
> Thoughts?
>
> [0] https://repos.fedorapeople.org/pulp/pulp/fixtures/
> [1] https://quay.io/repository/pulp/pulp-fixtures
>
>
> 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] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   3.3.0 release is on the way (various issues along the way which didn’t
   let to release earlier)
   -

   Focus on bug fixes and tests
   -

   Features
   -

  Lubos started on mirrorlist support
  -

 https://pulp.plan.io/issues/6225
 -

  https://pulp.plan.io/issues/5356
  -

 Feedback is needed


   -

   Tests
   -

  Advisory tests
  -

  Plan to do some coverage report experiments
  -

   Need to move QueryModelResource to the plugin API
   -


  
https://github.com/pulp/pulpcore/blob/master/pulpcore/app/modelresource.py#L12
  -

  Will break plugins (ie pulp_file and pulp_rpm) when pulpcore 3.4
  releases since they are importing it from pulpcore.app
  -

  Our proposal: import it into the plugin API but leave it in core. ove
  it in a future release (3.5+).
  - Plugins get pinned to pulpcore<3.4 on release so we can just move
 the model to the plugin api.
  -

   Validating content in Stages
   -

  Validate content in the first stage? Should be ok for RPM
  -

  Follow up on pulp-dev mailing list to discuss with other plugins
  -

   pulp_rpm_prerequisites release process: Where to document?
   -

  Either add to main pulpcore (which describes plugins generically)
  doc, or create a separate doc prereqs roles.


Pulp 2:

   -

   ttereshc tries to finish today
   -

  https://pulp.plan.io/issues/6354
  -

  https://pulp.plan.io/issues/6355
  -

   next is applicability issue https://pulp.plan.io/issues/6387


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
   -

  https://pulp.plan.io/issues/6519
  -

 Needs to be resolved this or next sprint (3 weeks till Katello
 release)
 -

  https://pulp.plan.io/issues/6476
  -

 Needs to be tested with real S3 and not minio to be sure that it’s
 not a minio specific issue.
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] redmine process for katello-integration-related issues

[Tatiana Tereshchenko]

Grant, thanks for trying to solve it thoroughly and with less bookkeeping
work for others.

However, I agree with the sentiment that it's better to have no milestone
than the wrong one.
Setting a milestone correctly is a difficult-to-impossible task, since that
can change with time. Also some projects/plugins assign milestones as a
part of release process, some assign ahead of time.

How about every mini-team, pulpcore and plugins, will figure out milestones
themselves and set them whenever they think is necessary?
And for now we just:

   - create a Katello tag
   - set this tag for all Katello items
   - adjust priority (P1 - High, P2 - Normal, P3 - low)
   - remove Katello-Px tags

What do you all think?

On Thu, Apr 23, 2020 at 12:30 PM David Davis  wrote:

> pulpcore is not the only project with milestones. Each project has its own
> set of milestones to represent different versions. The issue is your
> proposal is trying to assign all Katello-PX issues to a pulpcore milestone.
> That won't work if you have say a pulp_container or pulp_ansible issue with
> a Katello-PX tag.
>
> You could go through all the Katello-PX issues and try to figure out which
> milestone in which project to assign it to but with so many milestones and
> projects, it's going to be a huge pain. My suggestion was to just worry
> about the open issues and not try to retroactively assign these issues to
> milestones.
>
> David
>
>
> On Wed, Apr 22, 2020 at 7:12 PM Grant Gainey  wrote:
>
>>
>>
>> On Wed, Apr 22, 2020 at 6:17 PM David Davis 
>> wrote:
>>
>>> A couple observations: the 3.3[0] and 3.4[1] milestones already exist in
>>> redmine. Also, you won't be able to assign any of the MODIFIED issues to
>>> 3.3 because they're all plugin issues and the 3.3 milestone is exclusive to
>>> pulpcore. IMHO, I probably wouldn't assign any issues to any milestones. I
>>> think it would be worse having an issue on the wrong milestone than it
>>> being unassigned.
>>>
>>
>> If pulpcore is the only thing that has the version-milestones, then we're
>> at a dead stop. The whole point of the initial process proposal, was that
>> "milestone" would be able to completely replace the Katello-PX tags as a
>> way for Katello to tell us what they needed/expected when; if that's only
>> useful for pulpcore, then we have missed the mark, since the tags are used
>> cross-organizationally.
>>
>> If you look at the list of open-issues
>> <https://pulp.plan.io/issues?c%5B%5D=project%5B%5D=tracker%5B%5D=status%5B%5D=priority%5B%5D=subject%5B%5D=author%5B%5D=assigned_to%5B%5D=cf_3%5B%5D=cf_7%5B%5D=status_id%5B%5D=cf_7%5B%5D=_by=%5Bcf_7%5D=%3D%5Bstatus_id%5D=o_filter=1=project%2Cstatus%2Ccf_7%5B%5D==%E2%9C%93%5Bcf_7%5D%5B%5D=Katello-P1%5Bcf_7%5D%5B%5D=Katello-P2%5Bcf_7%5D%5B%5D=Katello-P3>
>> currently tagged with Katello-PX tags, you'll see more than pulpcore in
>> there.
>>
>> From ttereshc's summary email:
>>
>>>
>>>- tag katello-related issues as 'Katello'
>>>
>>>
>>>- *use the milestone field to define the
>>>planned-pulp-release-version*
>>>
>>>
>>>- use the Priority field to mark how important it is *to Katello*
>>>
>>>
>>>- remove the existing Katello P1/2/3 tags
>>>
>>>  If we can't mark non-pulpcore-issues with
>> "planned-pulp-release-version", then this proposal is DOA.
>>
>> Clearly, we need some more discussion! Anyone else want to join in?
>>
>> G
>>
>>
>>> That would leave the process somewhat simpler:
>>>
>>> 1. Create a Katello tag and assign it to all Katello-PX issues
>>> 2. Set the priority to high for P1 issues, medium for P2 issues, and low
>>> for P3 issues
>>> 3. Optionally, add open P2 issues to 3.4 milestone
>>> 4. Remove all Katello-PX tags
>>>
>>> And then Katello can just add the 15 issues at NEW/ASSIGNED to a
>>> milestone as they see fit: https://pulp.plan.io/issues?query_id=113.
>>>
>>> [0] https://pulp.plan.io/versions/83
>>> [1] https://pulp.plan.io/versions/88
>>>
>>> David
>>>
>>>
>>> On Wed, Apr 22, 2020 at 5:15 PM Grant Gainey  wrote:
>>>
>>>> Hey folks,
>>>>
>>>> To close the loop on this:
>>>>
>>>> On Thu, Apr 9, 2020 at 6:26 AM Tatiana Tereshchenko <
>>>> ttere...@redhat.com> wrote:
>>>>
>>>>> +1 and to the nitpick as well
>>>>>
>>>>>- tag katello-related issues as 'Katello

Re: [Pulp-dev] MODIFIED issues

[Tatiana Tereshchenko]

Thanks for the suggested automation, it would keep us more organised
with issues belonging to the right projects!

How do we close everything which is not in a changelog, do we associate it
with the same release milestone or leave it without any?
It seems that the majority are CI/CD and installer issues. Does it
make sense to have a separate process for them? Installer has its own
releases. I understand that some releases are tightly connected to the
pulpcore release, so maybe it can be closed when pulpocre is out.
I don't have a strong opinion here, just sharing some potential concerns.

Tanya

On Wed, Apr 22, 2020 at 1:56 PM David Davis  wrote:

> Thanks for the response. I think the next steps for me will be:
>
> 1. Merge https://github.com/pulp/plugin_template/pull/209
> 2. Add a step to the release guide to check/cleanup any MODIFIED issues
>
> I plan to proceed with these steps by April 24 if there is no other
> feedback.
>
> David
>
>
> On Tue, Apr 21, 2020 at 8:13 AM Ina Panova  wrote:
>
>> Comments inline.
>>
>>
>> 
>> 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 Mon, Apr 20, 2020 at 2:41 PM David Davis 
>> wrote:
>>
>>> During the pulpcore team meeting last week, we noted that after the
>>> latest pulpcore release there were a number of issues in redmine still at
>>> MODIFIED. I took an action item to go through them and they seem to fall
>>> into four categories:
>>>
>>> 1. Issues that got filed against pulpcore but were fixed in a plugin
>>>
>>> I think that item 1 is worth trying to fix by automation. The commit
>>> validation could check that the issue project for the attached issue
>>> matches the repo. I have a proof of concept here:
>>>
>>> https://github.com/pulp/plugin_template/pull/209
>>>
>>> +1
>>
>> 2. Issues without code changes (eg tasks, epics, etc) getting set to
>>> MODIFIED upon completion
>>> 3. Issues that got pulled/reverted before the release went out
>>>
>>> Optimally, we'd set these to CLOSED when they are completed. I think the
>>> release person could also check though. I'd propose we add a step to the
>>> release guide that asks the release person to clean up any items at
>>> MODIFIED after releasing.
>>>
>>> +1 to that, I had the same thought.
>>
>> 4. Issues against the installer and plugin_template.
>>>
>>> I would also make sure that they are in a closed state after the release.
>>
>> Looking for feedback on what to do with these.
>>>
>>> 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] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Query for the upcoming release
   -

  https://pulp.plan.io/projects/pulp_rpm/issues?query_id=149
  -

 Copy API docs
 -

Maybe we can publish them after the release? +1
-

 PR reviews
 -

   “Relative_path” problem
   -

  https://www.redhat.com/archives/pulp-dev/2020-April/msg0.html
  -

  Need to come back to it and bump the thread
  -

  Will be discussed at the pulpcore meeting
  -

   Import/export
   -

  Main path works, tech-preview in 3.3
  -

 pulp_file/pulp_rpm happy-path available
 -

  Docs in progress
  -

  Setting up handoff mtg w/katello next week
  -

 Public invite to list
 -

 Dennis volunteered to manage accepts
 -

 Invite QE folks
 -

   Katello timeline and deliverables
   -

  Ask if anything is unclear
  -

   3.3.0 release
   -

  Monday or Tuesday
  -

  Daniel to take care of the release
  -

   Testing publish task
   -

  Easy to test using the REST API:
  
https://github.com/pulp/pulp_rpm/blob/master/pulp_rpm/tests/functional/api/test_publish.py#L347
  -

  Problem: how to test publish task directly? How to emulate a synced
  repo? (Unit and Functional tests run on different places on CI)
  - Brian to write a proposal to solve this type of testing problems


Pulp 2:

   -

   Both items from last week needs to be taken care of
   -

  for the RPM migration to Pulp 3
  -

 https://pulp.plan.io/issues/6354
 -

 https://pulp.plan.io/issues/6355
 -

  CentOS directory KS structure is no longer RH compatible
  -

 https://pulp.plan.io/issues/6470
 -

 the same problem in Pulp3
 - Dennis to test more and file an issue if needed


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30


Tests:

   - Pulp 3 https://pulp.plan.io/projects/pulp_rpm/issues?query_id=153
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] pulpcore 3.3.0 GA timeline

[Tatiana Tereshchenko]

The release is unblocked and we'll proceed with it today.
Thanks to everyone for collaboration and quick resolution of the issues.

On Tue, Apr 14, 2020 at 7:29 PM Tatiana Tereshchenko 
wrote:

> The release is currently blocked by:
>
>- the issue with ordering of content https://pulp.plan.io/issues/6347
>- issues with CI
>
> We will update this thread when the release is unblocked (likely tomorrow).
>
> On Thu, Apr 9, 2020 at 5:52 PM Tatiana Tereshchenko 
> wrote:
>
>>
>> We decided to wait a bit more to include the import/export basic
>> functionality into the release.
>> The current plan is to release pulpcore==3.3.0 GA on April 14th.
>> The deadline for merging code is April 13th 23:59:59 EDT. We are planning
>> to start the release process on Tuesday morning.
>>
>> The following items are no longer blocking the release:
>> * The new repository repair API /pulp/api/v3/repair/ -
>> https://pulp.plan.io/issues/5613 - is done and merged.
>> * The setting to increase the accepted header size for pulpcore-content -
>> https://pulp.plan.io/issues/6460 - is moved to 3.4.
>>
>> On Wed, Apr 1, 2020 at 8:58 PM Brian Bouterse 
>> wrote:
>>
>>> We are planning to release pulpcore==3.3.0 GA on April 8th. While we
>>> strive for time-based releases, here are two items that we are hoping to
>>> include based on feedback from Katello who would like to consume 3.3.0 in
>>> their upcoming releases.
>>>
>>> * The new repository repair API /pulp/api/v3/repair/ -
>>> https://pulp.plan.io/issues/5613. This one is a must-have.
>>>
>>> * The import/export parts that belong in pulpcore -
>>> https://pulp.plan.io/issues/6134. This one is a nice-to-have and will
>>> tech-preview if not fully complete.
>>>
>>> ## What plugin writers need to know
>>>
>>> Look at the backwards incompatible changes in the plugin API release
>>> notes to determine if your plugin will require a compatibility release.
>>> Those are the *.removal entries here:
>>>
>>> https://github.com/pulp/pulpcore/tree/master/CHANGES/plugin_api
>>>
>>> Feedback, questions, and discussion are welcome.
>>> ___
>>> 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] pulpcore 3.3.0 GA timeline

[Tatiana Tereshchenko]

The release is currently blocked by:

   - the issue with ordering of content https://pulp.plan.io/issues/6347
   - issues with CI

We will update this thread when the release is unblocked (likely tomorrow).

On Thu, Apr 9, 2020 at 5:52 PM Tatiana Tereshchenko 
wrote:

>
> We decided to wait a bit more to include the import/export basic
> functionality into the release.
> The current plan is to release pulpcore==3.3.0 GA on April 14th.
> The deadline for merging code is April 13th 23:59:59 EDT. We are planning
> to start the release process on Tuesday morning.
>
> The following items are no longer blocking the release:
> * The new repository repair API /pulp/api/v3/repair/ -
> https://pulp.plan.io/issues/5613 - is done and merged.
> * The setting to increase the accepted header size for pulpcore-content -
> https://pulp.plan.io/issues/6460 - is moved to 3.4.
>
> On Wed, Apr 1, 2020 at 8:58 PM Brian Bouterse  wrote:
>
>> We are planning to release pulpcore==3.3.0 GA on April 8th. While we
>> strive for time-based releases, here are two items that we are hoping to
>> include based on feedback from Katello who would like to consume 3.3.0 in
>> their upcoming releases.
>>
>> * The new repository repair API /pulp/api/v3/repair/ -
>> https://pulp.plan.io/issues/5613. This one is a must-have.
>>
>> * The import/export parts that belong in pulpcore -
>> https://pulp.plan.io/issues/6134. This one is a nice-to-have and will
>> tech-preview if not fully complete.
>>
>> ## What plugin writers need to know
>>
>> Look at the backwards incompatible changes in the plugin API release
>> notes to determine if your plugin will require a compatibility release.
>> Those are the *.removal entries here:
>>
>> https://github.com/pulp/pulpcore/tree/master/CHANGES/plugin_api
>>
>> Feedback, questions, and discussion are welcome.
>> ___
>> 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] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Query for items to be done for Katello release
   https://pulp.plan.io/projects/pulp_rpm/issues?query_id=149
   -

  Priorities for Katello from the items which are not merged
  -

 Checksum type configuration for a publication
 - more tests added
- ready for review
 -

 Kickstart copy
 -

https://pulp.plan.io/issues/5207 - POST, awaiting review
-

 Issue with advisory checksum type
 -

https://github.com/pulp/pulp_rpm/pull/1667
-

proceed with the string representation
-

ready for review
-

   Import/export
   -

  On track for a first pass for pulpcore 3.3
  -

  Hope to have RPM integration by then or shortly thereafter
  -

  Need feedback about how to handle content dependencies
  -

 https://www.redhat.com/archives/pulp-dev/2020-April/msg00015.html
 -

   Features
   -

  Publish layout Packages + Opensuse support
  -

 Merged
 -

  Advisory version is considered at conflict resolution time
  -

 Advisory doesn't seem to be checked for conflicts at upload time
 (with repository specified)
 - ppicka to test thoroughly if it's the case
 -

  Mirror metadata discussion, aka "relative_path" problem
  -

 Bump email discussion next week


Pulp 2:

   -

for the RPM migration to Pulp 3
   -

  https://pulp.plan.io/issues/6354
  -

  https://pulp.plan.io/issues/6355
  -

  Need to fix it next week
  -

   CentOS directory KS structure is no longer RH compatible
   -

  https://pulp.plan.io/issues/6470
  -

  need someone to look at it next week
  -

  potentially a problem with pulp2 only (hopefully)


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30


Tests:

   - Pulp 3 https://pulp.plan.io/projects/pulp_rpm/issues?query_id=153
  - Opinions differ on how good the current test coverage is
  - Need to find a way to identify gaps, hopefully work on coverage
  report will be back on track soon
  - Focus on tests after 3.3, no capacity to look at it right now
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] pulpcore 3.3.0 GA timeline

[Tatiana Tereshchenko]

We decided to wait a bit more to include the import/export basic
functionality into the release.
The current plan is to release pulpcore==3.3.0 GA on April 14th.
The deadline for merging code is April 13th 23:59:59 EDT. We are planning
to start the release process on Tuesday morning.

The following items are no longer blocking the release:
* The new repository repair API /pulp/api/v3/repair/ -
https://pulp.plan.io/issues/5613 - is done and merged.
* The setting to increase the accepted header size for pulpcore-content -
https://pulp.plan.io/issues/6460 - is moved to 3.4.

On Wed, Apr 1, 2020 at 8:58 PM Brian Bouterse  wrote:

> We are planning to release pulpcore==3.3.0 GA on April 8th. While we
> strive for time-based releases, here are two items that we are hoping to
> include based on feedback from Katello who would like to consume 3.3.0 in
> their upcoming releases.
>
> * The new repository repair API /pulp/api/v3/repair/ -
> https://pulp.plan.io/issues/5613. This one is a must-have.
>
> * The import/export parts that belong in pulpcore -
> https://pulp.plan.io/issues/6134. This one is a nice-to-have and will
> tech-preview if not fully complete.
>
> ## What plugin writers need to know
>
> Look at the backwards incompatible changes in the plugin API release notes
> to determine if your plugin will require a compatibility release. Those are
> the *.removal entries here:
>
> https://github.com/pulp/pulpcore/tree/master/CHANGES/plugin_api
>
> Feedback, questions, and discussion are welcome.
> ___
> 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] redmine process for katello-integration-related issues

[Tatiana Tereshchenko]

+1 and to the nitpick as well

   - tag katello-related issues as 'Katello'
   - use the milestone field to define the planned-pulp-release-version
   - use the Priority field to mark how important it is *to Katello*
   - remove the existing Katello P1/2/3 tags


On Wed, Apr 8, 2020 at 6:47 PM David Davis  wrote:

> Nitpick but I would use 'Katello' to be consistent with other tags. And
> agreed that we should remove the Katello P tags. Other than that, LGTM.
>
> David
>
>
> On Wed, Apr 8, 2020 at 12:42 PM Justin Sherrill 
> wrote:
>
>> +1 to all of this!
>> On 4/8/20 12:35 PM, Brian Bouterse wrote:
>>
>> Thanks for writing this up and sending! My only addition would be to also
>> remove the P1, P2, P3 tags entirely after setting all tagged issues with
>> 'katello' and setting their priorities based on the previous P1/P2/P3 label.
>>
>> Thank you!
>>
>> On Wed, Apr 8, 2020 at 12:32 PM Grant Gainey  wrote:
>>
>>> Hey folks,
>>>
>>> As part of working with the katello upstream, we have been using a
>>> mechanism for prioritizing pulp-issues in order to help keep the Katello
>>> Gang unblocked. We have been using the 'Tags' field in an issue, and
>>> marking things as Katello-P1/2/3, with P1 being "blocker for the next
>>> release".
>>>
>>> As we move through releases, this is starting to break down - last
>>> release's P2 is this release's P1. This was brought up for discussion in
>>> today's integration meeting.
>>>
>>> In order to continue being able to prioritize work, we're proposing a
>>> change to the process to make it more sustainable as releases go on. I
>>> *think* I have captured the proposal effectively below - if I've missed
>>> something vital, I'm sure someone who was in the meeting will expand on it:
>>>
>>>- tag katello-related issues as 'katello'
>>>- use the milestone field to define the planned-pulp-release-version
>>>- use the Priority field to mark how important it is, *to katello*,
>>>to fix a bug NOW, as opposed to 'the day before the release is cut' 
>>> (which
>>>in practice is likely to be  'blockers are critical, everything else is
>>>normal')
>>>
>>> This will make it easy to query redmine in a way that returns a
>>> properly-ordered list, without some human having to go through and
>>> group-change tags on multiple issues at once.
>>>
>>> Would appreciate more eyes on this, and especially input on what I might
>>> have missed. We'd like to switch 'soon', so feedback before, say next
>>> Wednesday 15-APR would be great!
>>>
>>> Thanks,
>>> G
>>> --
>>> 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 
>> listPulp-dev@redhat.comhttps://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] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   “Relative_path” problem
   -

  https://www.redhat.com/archives/pulp-dev/2020-April/msg0.html
  -

  Doesn’t block critical work
  -

   Query for items to be done for Katello release
   https://pulp.plan.io/projects/pulp_rpm/issues?query_id=149
   -

  Priorities for Katello from the items which are not merged
  -

 Checksum type configuration for a publication (needs review)
 -

 Kickstart copy (volunteer is needed)
 -

https://pulp.plan.io/issues/5207
-

That issue could probably use some more detail
-

Start by writing a test
-

 OpenSUSE support (not blocked, needs review)
 -

   Import/export
   -

  Import PR up
  -

  Export-backend PR going up today
  -

   Other features
   -

  Copying a package group auto-copies packages that are members of it
  -

 https://pulp.plan.io/issues/6316
 -

 Not a priority, but needs to be addressed eventually
 -

  Publish layout Packages/
  -

 Potentially  blocked by relative_path problem but it’s not a
 critical feature and can wait


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
   -

  OOM kill for https://packages.microsoft.com/rhel/7/prod/

Tests:

   - Pulp 3 https://pulp.plan.io/projects/pulp_rpm/issues?query_id=153
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   A query for items to be done for Katello release
   https://pulp.plan.io/projects/pulp_rpm/issues?query_id=149
   -

  Waiting on Katello to review and mark what is needed for the
  early-April release
  -

   DRPM support
   -

  Likely is needed for Katello 4.0/4.1
  -

   Import/export
   -

  ggainey filling out export backend
  -

  daviddavis working on importer/import
  -

  Take a look at 6329  and
  comment if you have thoughts
  -

  agreed on Master/Detail approach

  -

   Other features
   -

  Publish layout Packages/x
  -

 a/name.rpm and b/name.rpm situation
 -

 Consider storing relative_path outside of ContentArtifact or
 Package model
 -

 Mirror repository story - https://pulp.plan.io/issues/6353
 -

  Opensuse
  -

 Done but depends on publish layout above
 -

  Configuration of a checksum type for a publication
  -

 PR is up and needs review



   -

   Tests
   -

  Will try to focus on it after the features for the upcoming Katello
  release


Pulp 2:

   -

   Applicability issue
   -

  https://bugzilla.redhat.com/show_bug.cgi?id=1816464
  -

   Reminder from last week
   -

  Needs to be fixed in pulp2, required for the RPM migration to Pulp 3
  -

 https://pulp.plan.io/issues/6354
 -

 https://pulp.plan.io/issues/6355
 -

 Will go into 2.21.z release


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:
Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

[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

[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] SUSE repositories in Pulp

[Tatiana Tereshchenko]

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

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Copy
   -

  In 3.3.0 beta 1
  -

   Import/export
   -

  Initial CRUD for Exporter in progress.
  -

  PR should be ready for review today hopefully. Debugging an openapi
  issue.
  -

   Other features
   -

  Opensuse
  -

 Open issue against productmd
 -

ppicka and fao89 to discuss
-

 Same nevra packages issue (pulp-dev-mailing-list)
 -

One option is to have a separate type of a repository for SUSE
-

   AI: run by Katello
   -

nosrc is (should be) a valid arch
-

   AI: talk to #suse
   -

AI: gather user cases, email pulp-list and PMs
-

  Sync optimizations
  -

 Merged
 -

 Automating tests
 -

   Tests
   -

  Query: https://pulp.plan.io/projects/pulp_rpm/issues?query_id=153
  -

  Started with tests originated by bugs:
  
https://github.com/pulp/Pulp-2-Tests/search?q=selectors.bug_is_fixed_q=selectors.bug_is_fixed



Pulp 2:

   -

   Applicability performance, patches accepted from CEE
   -

  https://bugzilla.redhat.com/show_bug.cgi?id=1812031
  -

   Needs to be fixed in pulp2, required for the RPM migration to Pulp 3
   -

  https://pulp.plan.io/issues/6354
  -

  https://pulp.plan.io/issues/6355
  -

  Will go into 2.21.z release


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls
   -

  Reviews are needed!
  -

 Opensuse kickstart support
 https://github.com/pulp/pulp_rpm/pull/1639
 -

 Modularity sync fix https://github.com/pulp/pulp_rpm/pull/1649


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Cherry pick labeling

[Tatiana Tereshchenko]

I believe it's the responsibility of both the author and the PR reviewer.

If it's a one-time contribution from someone, then the PR reviewer is
likely the one who is aware whether the cherry-pick should be done or not.
However in the majority of cases, we have regular contributors and they are
aware of the process. Depending on the fix, they might be in a better
position to say whether it's worth cherry-picking, if the cherry-pick will
be clean or not.

Alternatively, can we automate it? When PR is open, look at the referred
redmine issue and check its tracker, if it's an "issue", mark PR as the one
to be cherry-picked, so reviewer can unset it if it's undesirable for
whatever reason.

Tanya

On Tue, Mar 17, 2020 at 9:43 PM David Davis  wrote:

> Today we missed a change that could have maybe have gone out with the 3.2
> release. It stemmed from a lack of clarity around whose responsibility it
> is to label PRs with the cherry pick label. I think the general agreement
> is that it's ultimately the responsibility of the PR reviewer to add this
> label to the PR. I'm interested to see if there are any other thoughts or
> objections. Here is a PR I've opened as a proposal:
>
> https://github.com/pulp/pulpcore/pull/592
>
> 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] pulp_rpm 3.3.0 beta 1

[Tatiana Tereshchenko]

pulp_rpm 3.3.0 beta 1 has been released. It is compatible with pulpcore 3.2.

Among other features, this Beta release includes:
 - ability to perform complicated copy scenarios, including filters and
dependency solving
 - repository metadata signing

For the full list of features, see the changelog.

PyPI: https://pypi.org/project/pulp-rpm/3.3.0b1/
Changelog:
https://pulp-rpm.readthedocs.io/en/latest/changes.html#b1-2020-03-13
Docs: https://pulp-rpm.readthedocs.io/
Python bindings: https://pypi.org/project/pulp-rpm-client/3.3.0b1/
Ruby bindings: https://rubygems.org/gems/pulp_rpm_client/versions/3.3.0b1/

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

Re: [Pulp-dev] Changelog conventions

[Tatiana Tereshchenko]

+1 to describe the fix and not the problem.

On Thu, Mar 12, 2020 at 12:43 AM Dana Walker  wrote:

> +1
>
> Dana Walker
>
> She / Her / Hers
>
> Software Engineer, Pulp Project
>
> Red Hat 
>
> dawal...@redhat.com
> 
>
>
>
> On Wed, Mar 11, 2020 at 3:56 PM Dennis Kliban  wrote:
>
>> On Wed, Mar 11, 2020 at 3:33 PM David Davis 
>> wrote:
>>
>>> I want to reopen this thread for discussion as this topic has come up
>>> again this week. I don't think we need very strict or detailed requirements
>>> for changelog messages. But rather, some guidance around things like which
>>> tense to use would be helpful to standardize the changelog and not cause us
>>> to debate formatting in our PRs.
>>>
>>> Regarding tense, I think either past simple or present makes sense. I
>>> also believe that the changelog message should describe the fix and not the
>>> problem (unlike the associated redmine issue).
>>>
>>> +1 ... This works for me.
>>
>>
>>
>>> David
>>>
>>>
>>> On Wed, Mar 4, 2020 at 9:23 AM Robin Chan  wrote:
>>>
 Thanks for closing out this thread/topic, Lubos. That is a helpful
 practice.

 Given Ina's input, I see that as a concern, because best practice for
 bugs is to have a title or description of the behavior that is a problem
 and NOT the solution so that they can easily be found by others
 experiencing the same bug. Whereas with features, it is best to have a
 title or description of new behavior being added. So I can see that this
 would make it hard to standardize practices here.

 Robin Chan

 She/Her/Hers

 Satellite Software Engineering Manager - Pulp

 Red Hat 

 IRC: rchan
 



 On Fri, Feb 28, 2020 at 6:04 AM Lubos Mjachky 
 wrote:

> No inputs have been received for a week. Therefore, the changelog
> conventions should remain the same. That is, basically, no rules, and no
> conventions at all. I will continue using past simple on my own.
>
> On Mon, Feb 17, 2020 at 5:31 PM Ina Panova  wrote:
>
>> Thank you for starting this thread.
>>
>> The format of the changelog is different because the usual practice
>> is to re-use the title of the issue/story/task/refactor.
>>
>> If we want to create some standards than maybe we should start with
>> the titles from redmine.
>>
>> 
>> 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 Mon, Feb 17, 2020 at 4:55 PM Lubos Mjachky 
>> wrote:
>>
>>> Dear colleagues,
>>>
>>> I have recently noticed that our changelog often contains
>>> non-uniform messages informing about particular changes.
>>>
>>> For instance, take a look at the changelogs in pulp_container (
>>> https://pulp-container.readthedocs.io/en/latest/changes.html) or
>>> pulpcore (
>>> https://docs.pulpproject.org/en/master/nightly/changes.html):
>>> 1. As a user I can manage images in OCI format.
>>> 2. Let users fetch the list of all distributed repositories via the
>>> _catalog endpoint.
>>> 3. Adds ability to build OCI images from Containerfiles.
>>> 4. Added v2s2 to v2s1 converter.
>>> 5. Allow administrators to add a signing service.
>>> 6. Files stored on S3 and Azure now download with the correct
>>> filename.
>>>
>>> As you can see, we are using there random tenses and sentence
>>> structures. I am in favor of establishing one feasible convention for 
>>> all
>>> changelog messages. We should strive to use only one tense, e.g. past
>>> simple. Then, the messages would rather look like this [0]:
>>> 1. Removed the filter for the field 'digest'.
>>> 2. Added support for mirror mode.
>>>
>>> Please feel free to support this idea or raise any concerns. If we
>>> reach a viable consensus I will create a PR which will add a note about
>>> acceptable changelog messages to the corresponding section here
>>> https://docs.pulpproject.org/en/master/nightly/contributing/git.html#changelog-update.
>>> Thank you in advance.
>>>
>>> [0] https://keepachangelog.com/en/1.0.0/#how
>>> ___
>>> 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] RPM plugin meeting notes

[Tatiana Tereshchenko]

Forgot to add for Pulp 3:

   - Metadata signing merged - https://pulp.plan.io/issues/4812


On Thu, Mar 12, 2020 at 5:43 PM Tatiana Tereshchenko 
wrote:

> Pulp 3:
>
>-
>
>Copy
>-
>
>   Merged, waiting on testing from Katello
>   -
>
>   Beta may be released ‘today’
>   -
>
>Tests
>-
>
>   conversion to bindings
>   -
>
>  S3 test has some issues, hte rest are done
>  -
>
>  Finish and get signoff today?
>  -
>
>Features
>-
>
>   Opensuse support
>   -
>
>  Some version issues, treeinfo parsing - otherwise working
>  -
>
>  Treeinfo is ‘productmd problem’ (with validations) - need to
>  work w/ productmd gang to figure out where fix needs to be
>  -
>
>  ppicka to submit WIP PR for review, reach out to productmd
>  -
>
>   Sync optimizations
>   -
>
>  In testing
>  -
>
>Import/export
>-
>
>   High-level stories are in redmine
>   -
>
>   Initial CRUD for Exporter in progress
>   -
>
>   AI: everyone, check out the pulp-dev e-mail and review the design
>
>
>
>-
>
>Pulp_rpm 3.3.0beta1 release today or tomorrow
>
>
> Pulp 2:
>
>-
>
>Applicability performance discussions
>-
>
>Some issues/bzs investigated, likely to close w/no change
>-
>
>   4524 <https://pulp.plan.io/issues/4524> - need to close loop w/paji
>   and then close WONTFIX
>   -
>
>   6327 <https://pulp.plan.io/issues/6327> - users can turn on
>   validate:true to fix their broken /var/lib/pulp directory (see also
>   1775154
>   <https://bugzilla.redhat.com/buglist.cgi?quicksearch=1775154>) -
>   prob close NOTABUG
>
>
> Open PRs:
>
>-
>
>https://github.com/pulp/pulp_rpm/pulls
>
>
> Triage:
>
>- Un-triaged bugs
>https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Copy
   -

  Merged, waiting on testing from Katello
  -

  Beta may be released ‘today’
  -

   Tests
   -

  conversion to bindings
  -

 S3 test has some issues, hte rest are done
 -

 Finish and get signoff today?
 -

   Features
   -

  Opensuse support
  -

 Some version issues, treeinfo parsing - otherwise working
 -

 Treeinfo is ‘productmd problem’ (with validations) - need to work
 w/ productmd gang to figure out where fix needs to be
 -

 ppicka to submit WIP PR for review, reach out to productmd
 -

  Sync optimizations
  -

 In testing
 -

   Import/export
   -

  High-level stories are in redmine
  -

  Initial CRUD for Exporter in progress
  -

  AI: everyone, check out the pulp-dev e-mail and review the design



   -

   Pulp_rpm 3.3.0beta1 release today or tomorrow


Pulp 2:

   -

   Applicability performance discussions
   -

   Some issues/bzs investigated, likely to close w/no change
   -

  4524  - need to close loop w/paji
  and then close WONTFIX
  -

  6327  - users can turn on
  validate:true to fix their broken /var/lib/pulp directory (see also
  1775154 )
  - prob close NOTABUG


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   - Un-triaged bugs
   https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Copy API Status (dalley out-of-office)
   -

  General API shape + implementation: done
  -

  Depsolving: done
  -

  Incremental update: done
  -

  Multi-repo-copy: almost done
  -

 just need to hook the backend to the API properly, no serious
 implementation effort required
 -

  Thorough functional tests: discussions taking place
  -

   When do we want Z release
   -

  https://pulp.plan.io/issues/6229
  -

  ‘Now’ would be good
  -

   Tests conversion status (ppicka)
   -

  Hopefully today/tomorrow parity w/Pulp2
  -

   Features status (anyone working on features)
   -

  Opensuse support (ppicka)
  -

 started
 -

  Optimize sync (dawalker)
  -

 testing scenarios now
 -

  https://pulp.plan.io/issues/6281
  -

 Looking for volunteer
 -

 pulpcore item driven by rpm needs
 -

   Need to test new createrepo_c which supports parsing of xml_snippets
   (needed for the migration plugin)
   -

   Whenever it’s released, we need to publish new version to PyPI



Pulp 2:

   -

   Check applicability and depsolving for modularity multicontext issues



Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30


Sprint planning prep:

   -

   Items planned to be worked on during sprint and estimated time for each
   -

  David
  -

 Copy: 1-2 days
 -

 Importers/exporters 3-4 days
 -

  Pavel
  -

 Opensuse support 1-3 days (hard to say with this one)
 -

 Finish modularity upload or higher prio
 -

  Dana
  -

 Checksum options work, 4 days?
 -

 Available for other work
 -

  Daniel (out today)
  -

 [ttereshc guess] Finishing up Copy work
 -

  Grant
  -

 Import/Export: 5 days
 -

 #4534  (if critical): 2 days
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] [Pulp-list] pulpcore 3.2.0 and pulp_file 0.2.0 releases

[Tatiana Tereshchenko]

pulp_rpm 3.2.0 has been released. It is compatible with pulpcore 3.2.
For a list of all changes, please check the changelog.

PyPI: https://pypi.org/project/pulp-rpm/
Changelog: https://pulp-rpm.readthedocs.io/en/3.2/changes.html
Docs: https://pulp-rpm.readthedocs.io/en/3.2/
Python bindings: https://pypi.org/project/pulp-rpm-client/
Ruby bindings: https://rubygems.org/gems/pulp_rpm_client/versions/3.2.0/

Tanya


On Thu, Feb 27, 2020 at 10:02 PM David Davis  wrote:

> pulpcore 3.2.0[0] and pulp_file 0.2.0[1] have been released. For a list of
> all changes, please check the changelogs for pulpcore[2] and pulp_file[3].
>
> # Installation and Upgrade
>
> Users should use the 3.2.0 release of ansible-pulp installer[4] to install
> or upgrade their installations. This version of the installer will check
> compatibility of all installed plugins with pulpcore 3.2. The installer
> will abort if any plugin is incompatible.
>
> # Plugin API
>
> Plugin writers can see the plugin API changelog here (
> https://docs.pulpproject.org/en/3.2.0/changes.html#plugin-api ). There
> was only one backwards incompatible change[5], and in keeping with the
> recommended strategy to pin plugins to a 3.y version of pulpcore, plugins
> should release compatibility releases with 3.2 as soon as they can. We
> recommend using "pulpcore>=3.0,<3.3".
>
> The installer also has a backwards incompatible change in 3.2.0 where it
> no longer attempts to handle custom URLs for plugins automatically. If your
> plugin uses URLs outside of /pulp/api/v3/ or /pulp/content/ you will need
> to add a snippet. See these docs[6] for more.
>
> [0]: https://pypi.org/project/pulpcore/3.2.0/
> [1]: https://pypi.org/project/pulp-file/0.2.0/
> [2]: https://docs.pulpproject.org/changes.html#id1
> [3]: https://pulp-file.readthedocs.io/en/0.2.0/changes.html#id1
> [4]: https://github.com/pulp/ansible-pulp/releases/tag/3.2.0
> [5]: https://github.com/pulp/pulpcore/pull/555
> [6]: https://pulp.plan.io/issues/6057
>
> David
> ___
> Pulp-list mailing list
> pulp-l...@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] pulp-2to3-migration 0.1.0 RC 1 is available

[Tatiana Tereshchenko]

The pulp-2to3-migration 0.1.0rc1 has been released.

This is a Pulp 3 plugin to migrate content and repositories from Pulp 2 to
Pulp 3.
Currently, it 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/
Release notes:
https://github.com/pulp/pulp-2to3-migration/blob/0.1.0rc1/CHANGES.rst#changelog
Docs: https://github.com/pulp/pulp-2to3-migration/blob/0.1.0rc1/README.md
Python bindings: https://pypi.org/project/pulp-2to3-migration-client/
Ruby bindings:
https://rubygems.org/gems/pulp_2to3_migration_client/versions/0.1.0rc1

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

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Copy status
   -

  Depsolving: DONE
  -

  Incremental Update: Almost done
  -

  Multi-repo-copy: Almost done
  -

  API:
  -

 Need to check with Katello that their needs are met
 -

 Need to work out how to accept repositories OR repository versions
 as source, & support base_version on dest
 -

  Questions:
  -

 Do we need distribution tree copy for Katello?
 - Probably.
- We need to check with Katello and test how it works now.
- It's outside of the scope of copy API.
 -

 Do we need to copy Comps children (PackageGroup -> RPMs,
 PackageEnvironment -> PackageGroups, etc.) for Katello?
 -

 No

 -

  Tests: Not nearly enough of them



   -

   Import/export status
   -

  ggainey & daviddavis meeting every day/every-other to brainstorm
  -

  Design doc braindump in progress
  -

  Top-level epic - 6134  - also has
  thoughts
  -

   Tests
   -

   3.x (katello release)
   -

  https://pulp.plan.io/projects/pulp_rpm/issues?query_id=149
  -

  Deadlines:
  -

 Beginning of March - to have ability to integrate for major
 features like Copy API
 -

 End of March - GA with all the features complete (bugs can be
 fixed later in Z releases) +  tests
 -

 April - import/export work  (it’s the only exception which is not
 required to finish in March but we aim to finish it in March)
 -

   Bucket of prioritised items outside of any release
   -

  https://pulp.plan.io/projects/pulp_rpm/issues?query_id=148
  -

  Don’t pick up this work unless you can’t contribute to the items
  aligned to a certain release
  -

  Items here are not groomed and descriptions might be outdated. If you
  are willing to work on it, reach out to the group and groom it first.
  -

   Modularity bug, a nasty one, should be fixed soon, on the sprint
   -

  https://pulp.plan.io/issues/6229



Pulp 2:

   - Couple of security requests closed, no issues identified


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:
Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Reminder to mark bugfixes which needs to be cherry picked
   -

  PR author and reviewer should check that
  -

   Remaining features for katello 3.16 which have redmine tickets in new
   and not assigned
   -

  Copy
  -

  Importers/exporters
  -

  OpenSUSE support
  -

 Waiting on createrepo_c
 -

  Maybe we should add mirrorlist support?
  -

 maybe by October
 -

 bmbouter has PoC for it
 -

  Certguard - in progress, bmbouter is on it
  -

  AI: ttereshc to bring katello milestone in redmine up to date, to
  have a prioritised list of issues to work on
  -

   pulp_rpm_prerequisites
   -

  licensing question: PR #35
  , although
  tiny, was submitted before re-licensing. I rebased and amended the commit
  message #38 .
  Do we need the author’s relicense affirmation?
  -

 All good.
 -

  Not auto-importing  to galaxy since
  GHA migration, but I will work on the versioned release instead.



Pulp 2:

   -

   All blockers have been resolved.


Sprint planning prep:

   -

   Items planned to be worked on during sprint and estimated time for each
   -

  fao89 (1-2 days)
  -

 work on bindings problem
 -

 S3 test
 -

  ggainey
  -

 import/export - design/use-cases in progress, 3 days (??)
 -

 Errata-migration discussion(s), 1 day
 -

  daviddavis
  -

 copy: 1-2 days
 -

 importers/exporters: 3 days?
 -

  dawalker
  -

 Finishing optimize sync and optional checksum PRs through merging
 (6055, 4458): 3 days?
 -

 Open to work on whatever is needed the remainder of the sprint
 -

  dalley
  -

 Modulemd and modulemddefault depsolving: 3 days?
 -

 Child unit copy (errata-RPMs, packagegroup-RPMs): 2 days?
 -

 Multi-repo copy: 3 days?
 -

 Testing all of the above properly, including generating better
 fixtures: 5+ days?
 -

 Pre-built binary Python packages: any remaining free time
 -

  bmbouter
  -

 Certguard candlepin support and GA release 3-5 days
 -

  ppicka
  -

 TBD (ppicka was out today)


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Read access in Github

[Tatiana Tereshchenko]

+1 to make restarting travis jobs available to everyone in pulp org

On Fri, Feb 14, 2020 at 6:33 AM Brian Bouterse  wrote:

> +1 this would be helpful
>
> On Thu, Feb 13, 2020, 8:44 PM Daniel Alley  wrote:
>
>> +1, I occasionally come across a repo where I can't even restart my own
>> CI jobs, which is frustrating.  Probably even moreso to any new devs with
>> less access.
>>
>> On Thu, Feb 13, 2020 at 1:30 PM David Davis 
>> wrote:
>>
>>> At our CI/CD meeting, Fabricio pointed out that anyone with read access
>>> to a repository can restart a Travis job. I think we could create a team in
>>> Github with all Pulp organization members that has read access to all of
>>> our repos. Then anyone could restart Travis jobs.
>>>
>>> Thoughts?
>>>
>>> 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

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Support repos with primary.xml only
   https://bugzilla.redhat.com/show_bug.cgi?id=1627372
   -

  Question is whether to support them or not?
  -

 Probably no, David will comment on the BZ and close in a week if
 there is no disagreement.
 -

 Old issue/discussion https://pulp.plan.io/issues/1287#note-9
 -

   Copy work
   -

  RPM-only depsolving now working
  -

  Libsolv packaged as Python package, querying if upstream is
  interested in the work at all
  -

  Next items:
  -

 Support module & module default depsolving <- Daniel
 -

 Support “standard” advanced copy w/ RPMs referenced by Errata,
 PackageGroups
 -

 Support multi-repo copy
 -

 Support copy by unit href <-David
 -

   pulp_rpm_prerequisites relicensing PR
   
   -

  semi-urgent because we want to publish an actual version to Galaxy
  
  -

  Only 1 author missing review or “I affirm” message: bmbouter (on PTO)
  -

  About half of people wrote “I affirm the re-licensing” or similar.
  -

  Plan to go to rchan after all reviews


Pulp 2:

   -

 https://bugzilla.redhat.com/show_bug.cgi?id=1784165
   -

  Patch ready, needs to be tested
  -

  GA blocker


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls
   -

   good job on closing/merging PRs



Triage:
Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] pulp-2to3-migration 0.0.1 RC 1 is available

[Tatiana Tereshchenko]

The pulp-2to3-migration 0.0.1rc1 has been released.

This is a Pulp 3 plugin to migrate content and repositories from Pulp 2 to
Pulp 3.
Currently, it 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/
Release notes:
https://github.com/pulp/pulp-2to3-migration/blob/0.0.1rc1/CHANGES.rst#changelog
Docs: https://github.com/pulp/pulp-2to3-migration/blob/0.0.1rc1/README.md
Python bindings: https://pypi.org/project/pulp-2to3-migration-client/
Ruby bindings:
https://rubygems.org/gems/pulp_2to3_migration_client/versions/0.0.1rc1

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

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Copy API work
   -

  No change since last meeting, David out, Daniel doing other work
  -

   Libsolv python 3 bindings (python3-libsolv subpackage RPM)
   -

  Also missing .egg-info / .dist-info
  -

  Probably possible to package as a Python package, not done yet, on
  backburner
  -

  To get RPM for py3-bindings need to file a BZ - should be able to get
  into next RHEL; until then, katello would need to carry
  - Everyone has issues to work on, no one is blocked


Pulp 2:

   -

   Dep solving bugs
   -

  Grant sent a doc with his evaluation of dep solving bugs
  -

  No blockers


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls
   -

   a lot of PRs, need review



Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

>From last week.


Pulp 3:

   -

   Distribution trees (main topic, Katello devs are joining this time)
   -

  Currently pulp implementation assumes that there is a main repo
  -

 It might not be correct because there can be multiple variants and
 no main repo
 -

 Repo path == “.” == remote url
 -

 (addon/variant) repo path == “.” is considered as main repo
 -

 (addon/variant) repo path != “.” is considered as sub repo
 -


 
https://github.com/pulp/pulp_rpm/blob/master/pulp_rpm/app/tasks/synchronizing.py#L125-L150
 -

 When publishing [general] repository == first variant ordered by
 uid
 
https://github.com/release-engineering/productmd/blob/f6d73c9822a6451ef4e3af98393bf3935102667a/productmd/treeinfo.py#L1009-L1015

 
https://github.com/release-engineering/productmd/blob/f6d73c9822a6451ef4e3af98393bf3935102667a/productmd/treeinfo.py#L358-L360

 
https://github.com/pulp/pulp_rpm/blob/master/pulp_rpm/app/kickstart/treeinfo.py#L150-L152

 -

  Main repo vs no main repo
  - keep implementation as is (aka have a main repo)
 - some repos don't have a dedicated kickstart repo, they just add
 .treeinfo to the existing repo.
  -

   Sync optimizations for Katello 3.16
   -

  Any optimization usually requires an option to switch it off
  -

 Goal: one switch to ‘turn off all optimizations’, only
 -

 AI: someone to test RHEL7 first/re-sync numbers
 -

 AI: figure out how best to optimize re-sync down to “less than 10
 seconds” if nothing to do
 -

 Treeinfo check and repomd.xml version. There are more things to
 think about (remote-url change? etc)
 - https://pulp.plan.io/issues/6055
 -

   Export
   -

  To filesystem
  -

  To dvd-iso
  -

  To dvd-blu-ray
  -

  incremental
  -

  Does katello need all 4 use-cases? Justin to share use cases.


Pulp 2:

   -

   Announced Z release schedule
   -

   dependency solving issues
   -

  Dalley investigating
  https://bugzilla.redhat.com/show_bug.cgi?id=1784165
  -

 Able to reproduce & bisected to a commit
 -

  Ggainey investigating
  https://bugzilla.redhat.com/show_bug.cgi?id=1725958
  -

 Specifically issue#5449 


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Bindings - Installer and functional tests

[Tatiana Tereshchenko]

Great job! Thank you!

On Tue, Jan 28, 2020 at 4:33 PM Brian Bouterse  wrote:

> I agree! Thank you!
>
> On Tue, Jan 28, 2020 at 10:19 AM Daniel Alley  wrote:
>
>> Excellent work, Fabricio!  This is a big deal :)
>>
>> On Tue, Jan 28, 2020 at 10:06 AM Fabricio Aguiar <
>> fabricio.agu...@redhat.com> wrote:
>>
>>>
>>> With #6020  *plugin_template*
>>> functional tests now use *bindings* instead of making REST calls to
>>> pulp. This brought the need for installing bindings for being able to run
>>> functional tests, due to this, pbindings
>>> 
>>> was introduced on pulp-devel role on ansible-pulp.
>>>
>>> pbindings is an alias for pulp-openapi-generator script
>>> ,
>>> it takes three positional arguments: module name, language, and version.
>>> When the optional version parameter is provided, it is used as the version
>>> string. When it is not provided, the version reported by Pulp's status API
>>> is used.
>>>
>>> *Examples:*
>>> - generating python bindings for pulp_file:
>>> $ pbindings pulp_file python
>>>
>>> - generating ruby bindings for pulp_file with '3.0.0rc1.dev.10' version
>>> $ pbindings pulp_file ruby 3.0.0rc1.dev.10
>>>
>>> *Pulp-devel, ansible-pulp, pulplift*
>>> pulp-devel role, during provisioning, automatically installs the python
>>> bindings for every plugin listed on pulp_install_plugins.
>>> If you want to make use of this, please update your pulplift
>>>
>>> Best regards,
>>> Fabricio Aguiar
>>> Software Engineer, Pulp Project
>>> Red Hat Brazil - Latam 
>>> +55 11 999652368
>>> ___
>>> 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] RPM stories, feedback is needed

[Tatiana Tereshchenko]

I'm looking for feedback on the stories below.  For both:
 - is the logic correct or if anything is missing?
 - where to store info (from a remote) which is needed later?

1. https://pulp.plan.io/issues/4458 As a user, I can configure which
checksum algorithm to use when creating metadata
 - the suggestion is to store a checksum type of a remote on a rpm repo
version model.

2. https://pulp.plan.io/issues/6055 As a user, my sync is not operational
if there are no changes
  - the suggestion is to store all the necessary details on a
rpm repository model.

Please comment on the issues (preferred) or discuss here.

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

[Pulp-dev] pulp-2to3-migration 0.0.1 beta 1 is available

[Tatiana Tereshchenko]

The pulp-2to3-migration 0.0.1b1 has been released.

This is a Pulp 3 plugin to migrate content and repositories from Pulp 2 to
Pulp 3.
Currently, it supports File and Container plugins. It means that you can
migrate ISO and Docker content and repositories from Pulp 2 to Pulp 3.

PyPI: https://pypi.org/project/pulp-2to3-migration/
Release notes:
https://github.com/pulp/pulp-2to3-migration/blob/0.0.1b1/CHANGES.rst#changelog
Docs: https://github.com/pulp/pulp-2to3-migration/blob/0.0.1b1/README.md
Python bindings: https://pypi.org/project/pulp-2to3-migration-client/
Ruby bindings:
https://rubygems.org/gems/pulp_2to3_migration_client/versions/0.0.1b1

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

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Applicability
   -

  Summary of the discussion w/ Katello about ownership of applicability
  feature
  -

  AI: [ggainey] check in with jsherrill RE moving applicability
  discussion to pulp-dev
  -

   Copy
   -

  https://hackmd.io/OIIpE4GUTXKYoQa8lRMgww?view
  -

  AI: meeting with Katello to finalize details

  -

   Review of the remaining (medium to small) RPM features


Pulp 2:

   -

   Z release
   -

  Fixes https://bit.ly/2RcWG56
  -

  Ina volunteered to be a release shepherd


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 3:

   -

   Copy API discussion (continued)
   -

  Complex unified endpoint vs content-type specific endpoints +
  accumulative changes (repository versions created by many tasks
+ “commit”)
  -

  leaning towards the unified endpoint

  -

  Keep epic story up to date and collect feedback later
  -

  AI: figure out Katello-specific needs
  -

   Applicability
   -

  Draft design doc sent to pulp-list@
  https://hackmd.io/ydvHuzXNRA6T9eXx6cqy5A?view#Definitions
  -

  Discussions in progress w/jsherrill on refining katello use-cases
  -

  epic/subtasks created and being added to -
  https://pulp.plan.io/issues/5933
  -

  Initial code work spinning up this week
  -

   RPM planning, feature completeness for Katello


Pulp 2:

   - The is_modular flag issue is fixed
   https://github.com/pulp/pulp_rpm/pull/1579
  - Katello blocker


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   - Un-triaged bugs
   https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Bindings Testing Epic

[Tatiana Tereshchenko]

+1 to use bindings to test Pulp 3.

We've already started using them (thanks to @dkliban) for
pulp-2to3-migration initial testing.
https://github.com/pulp/pulp-2to3-migration/blob/master/pulp_2to3_migration/tests/functional/test_file_migration.py

Tanya

On Mon, Dec 16, 2019 at 11:32 PM Bruno Rocha  wrote:

> Hi,
>
> +1 to this idea, we have discussed that a little bit in QE some time ago
> in this issue[1]
>
> This can solve the constants files dependency the current pulp-smash
> testing has.
>
> [1] https://github.com/PulpQE/pulp-smash/issues/1182
>
> Bruno Rocha
>
> Senior Quality Engineer - Management QE - Pulp Project
> *irc*: rochacbruno
>
> *social*: http://about.me/rochacbruno
>
> “Progress is the realization of utopia.”
> 
>
>
> On Mon, Dec 16, 2019 at 6:03 PM Brian Bouterse 
> wrote:
>
>> I believe we have an opportunity to improve Pulp's testing through the
>> use of bindings tests. I wrote up an epic to gather ideas and discussion.
>> https://pulp.plan.io/issues/5888
>>
>> Initially this would be for pulpcore and pulp_file, but the idea is we
>> would enable this automatically via the plugin_tempalte. Comments are
>> welcome! With more input, I hope we can prioritize this work.
>>
>> Thanks,
>> Brian
>>
>> ___
>> 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] RPM mirror repository

[Tatiana Tereshchenko]

+1 to what Brian said. We ran into this question and the outcome was #5708.

While #5708 can help to fix the issue Pavel is describing, I believe the
resolve_advisories was meant to be run for every repo version finalization.
I think there is a bug in the implementation if it doesn't work correctly
for the mirror case. I filed a bug https://pulp.plan.io/issues/5924.

Tanya

On Fri, Dec 20, 2019 at 9:37 PM Brian Bouterse  wrote:

> I haven't looked very closely yet, but I see that the PR [1] has a
> conditional check in `finalize_new_version` here:
> https://github.com/pulp/pulp_rpm/pull/1568/files#diff-886596b2b9cc3257ce61648f8aab8ebfR124
>
> When finalize_new_version was added, an issue came up similar to yours:
> "where should we put validation/checks that should only run some of the
> time"? I believe the consensus was that finalize_new_version should only
> contain checks that are safe to run in all situations. Plugin writers still
> need checks that can only be run during certain user operations, and so we
> filed this https://pulp.plan.io/issues/5708 as a plugin API feature
> request.
>
> Can you read https://pulp.plan.io/issues/5708 and let us know if that
> would help you towards your goal?
>
> Thanks,
> Brian
>
> On Thu, Dec 19, 2019 at 12:16 PM Pavel Picka  wrote:
>
>> As working on RPM feature to mirror repository[1], it needs to bypass
>> the resolve_advisory check. That means argument (if it is mirror or
>> not) must be passed to Repositorys' new_version.
>>
>> I ran into part where pulpcore needs to updated [0] that this argument
>> can be accepted everywhere.
>>
>> I'd like to avoid crashing other plugins which use the mirror feature
>> so bringing this up to discussion how we want/can process this part.
>>
>>
>> [0]
>> https://github.com/pulp/pulpcore/compare/master...pavelpicka:5738-mirror-repo
>> [1] https://github.com/pulp/pulp_rpm/pull/1568/files
>>
>> --
>> 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] pulpcore release freeze and release timeline details

[Tatiana Tereshchenko]

Apart from setting status to CLOSED-CURRENTRELEASE in redmine, should we
also set a version which features/bugfixes were released in?
Target release? Platform release?

Tanya

On Thu, Dec 12, 2019 at 12:46 AM Brian Bouterse  wrote:

> The 3.0.0 release is available on PyPI [0], and docs are available [1]
> along with the bindings [2][3]. This should unblock pulp_rpm,
> pulp_container, and pulp_file from releasing. For each of these three
> plugins, please reply-all to this note so we can know each is done. After
> all 3 are released we will announce publicly on twitter, the blog, and
> pulp-list. I will handle the pulp_file release.
>
> I'll reply to this note with links to release announcements and website
> revisions as soon as they are drafted (tomorrow morning Eastern time).
> Tomorrow @dkliban and I will replace https://docs.pulpproject.org/ to
> show [1] by default. Also tomorrow, I'll do a mass-close to CURRENTRELEASE
> in pulp.plan.io of both pulpcore and pulp_file issues once announced. It
> would be great if pulp_rpm and pulp_contianer could handle their own issue
> transitions.
>
> [0]: https://pypi.org/project/pulpcore/
> [1]: https://docs.pulpproject.org/en/3.0.0/
> [2]:  https://rubygems.org/gems/pulpcore_client/versions/3.0.0
> [3]: https://pypi.org/project/pulpcore-client/3.0.0/
>
>
> On Thu, Dec 5, 2019 at 12:51 PM Brian Bouterse 
> wrote:
>
>> Releasing takes time, and we need pulpcore to be available before the
>> releasing of plugins can start. Here's a proposed timeline to allow that to
>> happen.
>>
>> Dec 10 - 22:00 all code merged to 'master'
>> Dec 11 - pushing pulpcore 3.0.0 GA to pypi, then pulp_file 0.1.0 to pypi.
>> Announce only to pulp-dev (not the official announcement)
>> Dec 12 - pulp_rpm, pulp_container release
>> Dec 12 - the docs.pulpproject.org and pulpproject.org website changes
>> are applied
>> Dec 12 - Send out announcement to pulp-dev, twitter, and blog
>>
>> @ttereshc and @ipanova how does this look to you for releasing pulp_rpm
>> and pulp_container on the 12th?
>>
>> Any feedback or adjustment is welcome; please let me know.
>>
>> Thanks!
>> Brian
>>
>> ___
> 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] pulpcore release freeze and release timeline details

[Tatiana Tereshchenko]

pulp_rpm is released.

https://pypi.org/project/pulp-rpm/
https://pulp-rpm.readthedocs.io/en/3.0/
https://pypi.org/project/pulp-rpm-client/3.0.0/
https://rubygems.org/gems/pulp_rpm_client/versions/3.0.0

On Thu, Dec 12, 2019 at 5:51 PM Ina Panova  wrote:

> pulp_container is released.
>
> https://pypi.org/project/pulp-container/
> https://pulp-container.readthedocs.io/en/1.0/
> https://pypi.org/project/pulp-container-client/1.0.0/
> https://rubygems.org/gems/pulp_container_client/versions/1.0.0/
>
> 
> 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 Thu, Dec 12, 2019 at 4:59 PM Brian Bouterse 
> wrote:
>
>> pulp_file is released.
>>
>> https://pypi.org/project/pulp-file/
>> https://pulp-file.readthedocs.io/en/0.1.0/
>> https://pypi.org/project/pulp-file-client/0.1.0/
>> https://rubygems.org/gems/pulp_file_client/versions/0.1.0
>>
>>
>> On Wed, Dec 11, 2019 at 6:45 PM Brian Bouterse 
>> wrote:
>>
>>> The 3.0.0 release is available on PyPI [0], and docs are available [1]
>>> along with the bindings [2][3]. This should unblock pulp_rpm,
>>> pulp_container, and pulp_file from releasing. For each of these three
>>> plugins, please reply-all to this note so we can know each is done. After
>>> all 3 are released we will announce publicly on twitter, the blog, and
>>> pulp-list. I will handle the pulp_file release.
>>>
>>> I'll reply to this note with links to release announcements and website
>>> revisions as soon as they are drafted (tomorrow morning Eastern time).
>>> Tomorrow @dkliban and I will replace https://docs.pulpproject.org/ to
>>> show [1] by default. Also tomorrow, I'll do a mass-close to CURRENTRELEASE
>>> in pulp.plan.io of both pulpcore and pulp_file issues once announced.
>>> It would be great if pulp_rpm and pulp_contianer could handle their own
>>> issue transitions.
>>>
>>> [0]: https://pypi.org/project/pulpcore/
>>> [1]: https://docs.pulpproject.org/en/3.0.0/
>>> [2]:  https://rubygems.org/gems/pulpcore_client/versions/3.0.0
>>> [3]: https://pypi.org/project/pulpcore-client/3.0.0/
>>>
>>>
>>> On Thu, Dec 5, 2019 at 12:51 PM Brian Bouterse 
>>> wrote:
>>>
 Releasing takes time, and we need pulpcore to be available before the
 releasing of plugins can start. Here's a proposed timeline to allow that to
 happen.

 Dec 10 - 22:00 all code merged to 'master'
 Dec 11 - pushing pulpcore 3.0.0 GA to pypi, then pulp_file 0.1.0 to
 pypi. Announce only to pulp-dev (not the official announcement)
 Dec 12 - pulp_rpm, pulp_container release
 Dec 12 - the docs.pulpproject.org and pulpproject.org website changes
 are applied
 Dec 12 - Send out announcement to pulp-dev, twitter, and blog

 @ttereshc and @ipanova how does this look to you for releasing pulp_rpm
 and pulp_container on the 12th?

 Any feedback or adjustment is welcome; please let me know.

 Thanks!
 Brian

 ___
>> 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] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 2:

   -

   1770940  - figured
   out why there’s a performance difference, now need to figure out what to do
   about it
   -

   Katello calls differ (no clone distributor is used), Pulp does publish
   in the same way

   -

   https://github.com/pulp/pulp_rpm/pull/1558 sync perf improvement ( from
   CDT)
   -

  Ipanova will follow up ( next year)

Pulp 3:

   -

   Copy API
   -

  https://pulp.plan.io/issues/5344
  -

  discussed use cases, expect a follow-up email on pulp-dev list

  -

   Cherry picks next week
   -

  In the event of an emergency (eg Katello encounters a major blocker)
  is there someone who can cherry pick to the 3.0 branch? Or do we
just wait
  until Jan?
  -

  Yes, there will be pulp-committers available next week if needed
  -

   Release status
   -

  Will start after meeting
  -

   Applicability - draft design doc is out, feedback is needed
   -

   Is #5841  (Document how to install
   libcomps and dependencies) needed for GA?
   -

  https://github.com/pulp/pulp_rpm/pull/1570 - Needs cherry-pick
  -

   All 3 of Mike’s RPM-related Ansible installer issues are on QA/MODIFIED


Open PRs:

   -

   https://github.com/pulp/pulp_rpm/pulls


Triage:

   -

   Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] RPM file list can be confusing for users

[Tatiana Tereshchenko]

In my opinion, it's fine to show exactly what we have/store.
Maybe we can add some clarification to the docs about the format of the
filelists.

On Mon, Dec 9, 2019 at 11:09 AM Pavel Picka  wrote:

> There is the issue for $subject #5831 [0], I took a look at
> createrepo_c [1] and 'dir', 'ghost' or 'None/[null]' are the file
> types.
> It means some of the paths are only directories, others are files
> themselves.
>
> I would like to ask if we want to show it to users or adjust the
> serializer to show only files and not directories?
>
> [0] https://pulp.plan.io/issues/5831
> [1]
> http://rpm-software-management.github.io/createrepo_c/c/structcr___package_file.html
>
> --
> 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

Re: [Pulp-dev] Required fields for models at the DB level

[Tatiana Tereshchenko]

+1 to have additional serializer for validation content fields and use
current serializers for upload case
+1 to validate during sync

On Fri, Dec 6, 2019 at 8:31 PM David Davis  wrote:

> I talked to @ttereshc this afternoon and a couple questions came up.
>
> First, in pulp_rpm we have a PackageSerializer[0] that handles creating
> and displaying packages. The problem is that the package field values are
> derived from the artifact and not the user so most fields are readonly and
> not required. I'm imagining we'll have to split this serializer in two (ie
> a PackageSerializer and a PackageUploadSerializer) in order to use it to
> validate package data. Does that make sense or is there a better way?
>
> Secondly, I don't think we're validating data during sync. What if a user
> syncs data from a remote that has bad data? I think we'll need to have the
> stages somehow use serializers as well? If others agree, I can file an
> issue.
>
> [0]
> https://github.com/pulp/pulp_rpm/blob/326d189bbae9267d59282d62ada1fa36467a2d8f/pulp_rpm/app/serializers.py#L69
>
> David
>
>
> On Thu, Dec 5, 2019 at 6:32 AM David Davis  wrote:
>
>> This makes sense to me. I wonder if we should document what you've
>> outlined in the plugin writers guide? If so, then maybe we should repurpose
>> 5828?
>>
>> David
>>
>>
>> On Tue, Dec 3, 2019 at 12:14 PM Brian Bouterse 
>> wrote:
>>
>>> After some IRC discussion during open floor, I think the consensus is
>>> that we should not have BaseModel call full_clean(). Plugin writers doing a
>>> lot of object creation without involving DRF serializers should call
>>> full_clean() either in application code or their specific model's save()
>>> method. Here's some recap about the motivations for this:
>>>
>>> * By having full_clean() called with all model save it gives Pulp "two
>>> validation layers" when there only needs to be one. DRF's validation layer
>>> is the serializer, and it isn't prepared to do error handling from a
>>> "second" layer. This is partly an echo of the concerns from Tom Christie's
>>> writing.
>>> * DRF is primarily designed to have data flow through its serializers.
>>> This issue is more problematic in cases where data is not flowing through
>>> the serializer. Thus we should try to include the serializer whenever
>>> possible.
>>> * If we cannot include the serializer, those are cases where we would
>>> specifically benefit from calling full_clean manually.
>>>
>>> Other thoughts and concerns are welcome. If nothing major comes up then
>>> we can close https://pulp.plan.io/issues/5828 as WONTFIX.
>>>
>>>
>>>
>>> On Mon, Dec 2, 2019 at 6:52 PM Simon Baatz  wrote:
>>>
 On Mon, Dec 02, 2019 at 03:53:06PM -0500, Brian Bouterse wrote:
 >If anyone has concerns with us enabling Model validation by
 default on
 >all models please let us know soon.

 I don't know (yet) if I have concerns, but DRF seems to have, see

 https://www.django-rest-framework.org/community/3.0-announcement/#differences-between-modelserializer-validation-and-modelform

 According to DRF's design, all validation logic should be at one
 place, which is the serializer.  This seems to be a controversial
 issue, see e.g.
 https://github.com/encode/django-rest-framework/issues/3144.  From
 that issue:

 What happens in the case where in your models you are forcing a
 full_clean (perhaps by including it in the save method)?  Will
 serializers know how to handle an exception from an explicit
 full_clean?

 And Tom Christie's answer:

 I'd recommend that application level validation should generally
 happen prior to save, not during it.  Personally I'd avoid
 full_clean, and instead ensure that state changing operations on
 model instances are only ever made via method calls that can provide
 a boundary that ensures that only valid state changes may ever be
 made by the rest of the application.



 We need to be aware that we are leaving the path recommended by DRF
 if we implement this proposal and mix Django validation and DRF
 validation.  Unfortunately, I don't know what the alternative is.
 Using DRF serializers to construct all model instances looks clumsy
 when it comes to relations.

 ___
>>> 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] pulpcore release freeze and release timeline details

[Tatiana Tereshchenko]

Thank you.
It sounds good for pulp_rpm.
However, since not all the blockers are resolved at this moment, there is
no full confidence that we'll be able to release pulp_rpm on Dec 12.
The likelihood of solving them by that day is high, so let's set it as a
goal for pulp_rpm.

Tanya

On Fri, Dec 6, 2019 at 1:54 AM Ina Panova  wrote:

> Brian,
> Thank you for the provided details.
>
> Ack, on releasing pulp_container on Dec 12.
>
> On Thu, 5 Dec 2019, 18:52 Brian Bouterse,  wrote:
>
>> Releasing takes time, and we need pulpcore to be available before the
>> releasing of plugins can start. Here's a proposed timeline to allow that to
>> happen.
>>
>> Dec 10 - 22:00 all code merged to 'master'
>> Dec 11 - pushing pulpcore 3.0.0 GA to pypi, then pulp_file 0.1.0 to pypi.
>> Announce only to pulp-dev (not the official announcement)
>> Dec 12 - pulp_rpm, pulp_container release
>> Dec 12 - the docs.pulpproject.org and pulpproject.org website changes
>> are applied
>> Dec 12 - Send out announcement to pulp-dev, twitter, and blog
>>
>> @ttereshc and @ipanova how does this look to you for releasing pulp_rpm
>> and pulp_container on the 12th?
>>
>> Any feedback or adjustment is welcome; please let me know.
>>
>> Thanks!
>> Brian
>>
>> ___
>> 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] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 2:

   -

   Sat 6.6 publish performance issue bug(s) - investigating
   -

  1770940 
  -

  1773601 


Pulp 3:

   -

   Blockers https://pulp.plan.io/projects/pulp_rpm/issues?query_id=139
   -

  Performance
  -

 Increased batch-sizes has direct impact
 -

Configure per-plugin - maybe
-

Increase default in pulpcore stages api
-

 Fabricio found one more source of memory problem (pulpcore)

 
https://github.com/pulp/pulpcore/blob/master/pulpcore/app/models/repository.py#L473
 -

 Publish has similar pattern for the performance problem
 -

 Decrease worker-heartbeat writes to DB (~30% overhead?) (pulpcore)
 -

Might be an artifact of the sampling method. Would like to see
verification from cProfile before we change anything.
Heartbeat is in a
separate thread so if it’s waiting on IO, it doesn’t
really matter (dalley)
- UpdateRecord was saved one by one and not in batches, PR is
 posted
 -
  -

  Model level validation
  -

 Not sure full_clean is the correct solution
 -

 ttereshc will check how much plugin is currently affected
 - Comps publish issue
 - root cause not found yet
 - dawalker to send email with the current state of things for
 someone to pick up or collaborate on
  -

  Docs
  -

  Installer (libcomps)
  -

 On sprint, needs to be picked up - mikedep333 will take care of it
 -

 Current state - CentOS7 doesn’t install libcomps
 - Release
 - next RC when the code changes are ready
- optimistically - tomorrow, realistically - next week


   - Open PRs:
  - https://github.com/pulp/pulp_rpm/pulls


Triage:

Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev