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

ar from anyone if you think there > is something we should do before the GA. > > > > On Mon, Dec 2, 2019 at 10:20 AM Tatiana Tereshchenko > wrote: > >> Bump. >> Any thoughts? >> >> If we decide to change something, we'd better do it before GA, I think. >&g

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

72674/5253051 >> [image: image.png]4 >> <https://stackoverflow.com/a/56272674/5253051> >> >> Best regards, >> Fabricio Aguiar >> Software Engineer, Pulp Project >> Red Hat Brazil - Latam <https://www.redhat.com/> >> +55 11 999652368 &g

Re: [Pulp-dev] pulplift is failing to provision pulp2-nightly-pulp3-source-centos7

I think this issue is filed here https://pulp.plan.io/issues/5553 and there is a PR open to fix it https://github.com/pulp/ansible-pulp/pull/178/. Tanya On Sun, Dec 1, 2019 at 10:35 PM Mike DePaulo wrote: > At the end of the entire ansible run for `vagrant up`, when it's finished > the devel

Re: [Pulp-dev] Cherry pick process

+1 to the automation of the process Can we configure Travis to send an e-mail if the job fails and not rely on human checking it every time? Tanya On Mon, Nov 25, 2019 at 6:14 PM David Davis wrote: > I opened an issue to outline the design we're discussing: > >

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

I noticed that there is no enforcement at the DB level to require certain fields to be present on a model. I haven't checked all the field types but at least for TextField it's seems to be true. Even though `null` is False by default (`blank` as well), I can save a model instance without most of

[Pulp-dev] RPM plugin meeting notes

Pulp 2: - #5658 - modulemd_defaults and copy - Potential fix in hand, PR today or tomorrow - Dep solving performance concerns - https://bugzilla.redhat.com/show_bug.cgi?id=1771780 Pulp 3: - Blockers

Re: [Pulp-dev] RPM plugin meeting notes

Hi Ales, Thanks for confirmation! I'll definitely file BZs when we analyze and figure out all the differences and what is needed. It was a quick pre-GA discussion about the path forward when we need to add opensuse advisories. Tanya ___ Pulp-dev

Re: [Pulp-dev] RPM plugin meeting notes

On Thu, Nov 7, 2019 at 10:04 PM Neal Gompa wrote: > On Thu, Nov 7, 2019 at 3:48 PM Tatiana Tereshchenko > wrote: > > > > Advisory > > > > Opensuse advisory > > > > some fields differs (reboot_suggested != restart_suggested) > > > > Thes

[Pulp-dev] RPM plugin meeting notes

Pulp 2: - 5359 /BZ#1744225 closed WONTFIX - Investigating 5658 Pulp 3: - Blockers https://pulp.plan.io/projects/pulp_rpm/issues?query_id=139 - All RPM endpoints, go/no-go

Re: [Pulp-dev] [noissue] considered harmful

I'm leaning towards keeping [noissue] and have it a responsibility of PR reviewer/merger to evaluate if it's a proper use or an issue is needed. Alternatively, can we block a merge of PR if there is no issue? at github level, not in travis? so tests run but you can only merge it "using your admin

Re: [Pulp-dev] Repo versions with no changes

+1 to not create empty repo versions for now On Tue, Nov 5, 2019 at 2:34 PM Fabricio Aguiar wrote: > Sounds good to me. > > Best regards, > Fabricio Aguiar > Software Engineer, Pulp Project > Red Hat Brazil - Latam > +55 11 999652368 > > > On Tue, Nov 5, 2019 at 1:38

[Pulp-dev] RPM plugin meeting notes

Pulp 3: - Blockers (aim is to close all by pulpcore dev freeze) - https://pulp.plan.io/projects/pulp_rpm/issues?query_id=139 - 3-4 docs, can be done after dev freeze - Few refactors - soft blockers - The rest must be done

[Pulp-dev] RPM plugin meeting notes

Pulp 2: - MONGO_X509 auth PR in - discussions w/ewoud about impacts on Katello installation - not pulp_rpm specific Pulp 3: - 3.0.0b7 released - Blockers status - Couple are waiting on 3541 https://pulp.plan.io/issues/3541 - If you have

Re: [Pulp-dev] Merging pulpcore.plugin into pulp/pulpcore repo?

Do I understand correctly, that the suggestion is not to have versioned api at all but document some conventions/expectations between pulpcore releases and plugin API? I wonder if there is still a benefit to keep it as a separate package and as-is. I understand that now we need to release both at

Re: [Pulp-dev] Repo version validation

On Wed, Oct 9, 2019 at 5:52 PM Brian Bouterse wrote: > > > On Wed, Oct 9, 2019 at 5:23 AM Tatiana Tereshchenko > wrote: > >> I think the main confusion I have is that we call it validation. >> Semantically, I'd expect the validation operation to complain if somethin

Re: [Pulp-dev] Repo version validation

thinking these use cases are for copy not sync, because only in the > copy case is the plugin writer's code not already involved. > > >> David >> >> >> On Tue, Oct 8, 2019 at 12:55 PM Tatiana Tereshchenko >> wrote: >> >>> The solution proposed in #3

Re: [Pulp-dev] [BREAKING] Names of Pulp 3 related services are going to be changed

e merged yet for the plugin repositories which are not maintained by Pulp team. Those PRs contain documentation changes only, so it should not be critical. Tanya On Fri, Oct 4, 2019 at 4:08 PM Tatiana Tereshchenko wrote: > As per additional renaming request, PRs have been opened to rename > pu

Re: [Pulp-dev] [BREAKING] Names of Pulp 3 related services are going to be changed

Wed, Oct 2, 2019 at 7:29 PM Tatiana Tereshchenko wrote: > Some questions and new requirements showed up during PR review,. > This is just to let you all know that the changes are not merged yet. > > Stay tuned. > > On Tue, Sep 24, 2019 at 12:58 AM Lubos Mjachky > wrote: &g

[Pulp-dev] RPM plugin meeting notes

- Modularity update (ppicka) - PR for upload sent - Comps.xml (dana) - Sync PR was blocked by segfault bug in libcomps, using workaround - Github issue filed: https://github.com/rpm-software-management/libcomps/issues/54 -

Re: [Pulp-dev] ContentViewset assumes that POST is needed for any content

Thanks everyone for discussion! PRs are up https://github.com/pulp/pulpcore/pull/322 https://github.com/pulp/pulpcore-plugin/pull/140 https://github.com/pulp/pulp_rpm/pull/1467 On Thu, Oct 3, 2019 at 10:27 AM Tatiana Tereshchenko wrote: > Thank you! > > I filed a task to provide a

Re: [Pulp-dev] ContentViewset assumes that POST is needed for any content

ore/pull/319 > https://github.com/pulp/pulp_rpm/pull/1465 > > [0] https://pulp.plan.io/issues/5533 > > David > > > On Wed, Oct 2, 2019 at 1:32 PM Tatiana Tereshchenko > wrote: > >> +1 to what David said. Thanks for detailed explanation. >> >> +1 to f

Re: [Pulp-dev] ContentViewset assumes that POST is needed for any content

ting it right. >> >> In the event it's not easy for the plugin writer to be in control of that >> then I would be in favor of GenericContentViewset. >> >> >>> >>>> >>>> Just to write it out for clarity I imagine it would be: >&

Re: [Pulp-dev] [BREAKING] Names of Pulp 3 related services are going to be changed

Some questions and new requirements showed up during PR review,. This is just to let you all know that the changes are not merged yet. Stay tuned. On Tue, Sep 24, 2019 at 12:58 AM Lubos Mjachky wrote: > As of now, all Pulp 3 related services will use prefix pulpcore-* instead > of pulp-*. This

Re: [Pulp-dev] ContentViewset assumes that POST is needed for any content

ly GET mixed in and leave the > 'standard' ContentViewset as is. > Cheers, Matthias > > On Wed, 2 Oct 2019 16:16:14 +0200 > Tatiana Tereshchenko wrote: > > > Current implementation of ContentViewset > > < > https://github.com/pulp/pulpcore/blob/master

[Pulp-dev] ContentViewset assumes that POST is needed for any content

Current implementation of ContentViewset includes mixins for create (POST) and retrieve/list (GET). In case a plugin doesn't need to support POST for a content endpoint, a plugin writer compiles a viewset from

Re: [Pulp-dev] Google's Code Reviewer Guide

Thanks for sharing! Tanya On Tue, Oct 1, 2019 at 1:52 PM David Davis wrote: > I've been reading through Google's Code Reviewer Guide and I've found it > rather interesting. While reviewing code may seem pretty basic, I have > found a couple rather insightful points in their guide. One example

Re: [Pulp-dev] [pulp-dev] modularity upload

+1 for custom endpoint for modules.yaml upload. As a reminder, modules are special, they often come in a batch which contains 2 content types. To upload modules.yaml file means to upload/add X modulemd content units and Y modulemd-defaults content units to Pulp, each of them would refer to a newly

[Pulp-dev] RPM plugin meeting notes

Pulp 2: - Pulp 2.21.0 GA going out today (24 hr delay due to docs build issues) - https://pulp.plan.io/issues/5447 - should add this to 2.21.1 - non-RPM specific Pulp 3: - Modularity update (ppicka) - Sync and publish are merged - Comps.xml update

[Pulp-dev] RPM plugin meeting notes

General: - Make the meeting optional? +1 - Make sure to fill the agenda and updates at least the day before, so others will know whether they should attend or not - Don’t plan anything on purpose for this time, in case you’ll be needed for a discussion

[Pulp-dev] RPM plugin meeting notes

Pulp 2: - Multi-repo copy update (dalley) - PRs ready for review - https://github.com/pulp/pulp_rpm/pull/1420/ - https://github.com/pulp/pulp/pull/3947 - Docs changes remain - Still no smash tests, will work with QE on this,

Re: [Pulp-dev] artifact stages adjustment or any other solution?

Austin, thank you. Your option is more explicit, so it's probably better. Tanya On Wed, Aug 28, 2019 at 6:38 PM Austin Macdonald wrote: > > > On Wed, Aug 28, 2019 at 11:34 AM Tatiana Tereshchenko > wrote: > >> Bump. >> >> Please provide feedback if yo

Re: [Pulp-dev] artifact stages adjustment or any other solution?

Bump. Please provide feedback if you have any. I'll start working on the PR to make the suggested change this week otherwise. Thank you, Tanya On Mon, Aug 26, 2019 at 12:46 PM Tatiana Tereshchenko wrote: > In RPM plugin we have Modulemd content. It comes from metadata as one file >

[Pulp-dev] artifact stages adjustment or any other solution?

In RPM plugin we have Modulemd content. It comes from metadata as one file and we parse it and then save each modulemd as a separate file/artifact. The question is how to handle this content in the sync pipeline. Modulemd content is artifactless on a remote source (metadata) but it's not

[Pulp-dev] RPM plugin meeting notes

Pulp 2: - Multi-repo copy update (dalley) - 2 PRs - https://github.com/pulp/pulp/pull/3947 - https://github.com/pulp/pulp_rpm/pull/1420 - Still testing the 2nd one, not returning exactly the same results yet for the standard test cases

[Pulp-dev] RPM plugin meeting notes

Pulp 2: - Dep solving - Finished the part which interacts with libsolv (the multi-repo copy feature is the last one left to close the dep solving features/bugs for pulp2) - No smash tests for the new stuff yet - *AI*: dalley will work with

[Pulp-dev] RPM meeting notes

Pulp 2: - Dep solving - Automatically copy modulemd-defaults PR is ready to go: https://github.com/pulp/pulp_rpm/pull/1400 - *AI:* ttereshc to review - all of the original documented recursive-conservative bugs are now seemingly fixed

Re: [Pulp-dev] pulp 2 to 3 upgrade experience concerns

On Wed, Jul 31, 2019 at 5:15 PM Dennis Kliban wrote: > On Wed, Jul 31, 2019 at 10:27 AM Brian Bouterse > wrote: > >> Thank you for raising this concern. >> >> On Wed, Jul 31, 2019 at 10:06 AM Dennis Kliban >> wrote: >> >>> Users of Pulp 2 that are upgrading to Pulp 3 need to make files stored

Re: [Pulp-dev] Namespacing one shot upload and copy endpoints

If the goal is to make endpoints unified across all actions, then I think we can only do POST /pulp/api/v3//plugin/action/ types=[] Having plugin/content_type/upload would be nice, however I'm not sure if it covers enough use cases. E.g. For pulp_rpm, it makes sense for packages or advisories to

Re: [Pulp-dev] uniqueness constraints within a repository version

: > > > On Mon, Jul 22, 2019 at 4:47 AM Tatiana Tereshchenko > wrote: > >> >> >> On Sun, Jul 21, 2019 at 3:00 PM Brian Bouterse >> wrote: >> >>> >>> >>> On Sun, Jul 21, 2019 at 6:23 AM Tatiana Tereshchenko < >>> tt

Re: [Pulp-dev] Pinning dependencies in Pulp 3

+1 to pin dependencies and use dependabot If we were to pin to Z releases, then we'd need to release pulp 3 package with any Z release of any dependency we pin. And in case of any [security] fix in any dependency, users would need to wait for us to release pulp with updated dependency version.

[Pulp-dev] RPM meeting notes

Pulp 2: - Dep solving - Multi-resource locking PR needs review - https://github.com/pulp/pulp/pull/3945/ - dkliban & bmbouter to review - After ^ we need to finish multi-repo dep solving story -

Re: [Pulp-dev] Require Django 2.2+ and PostgreSQL 9.6

e/start if PostgreSQL version < >> 9.6. >> >> >> On Tue, Jul 23, 2019 at 10:35 AM David Davis >> wrote: >> >>> +1. I wonder how we require a minimum version of PostgreSQL though? Will >>> that be a documentation change or is there some wa

[Pulp-dev] Require Django 2.2+ and PostgreSQL 9.6

Any objections to require Django 2.2+? And PostgreSQL 9.6+? It's not clear yet which Django will be in Centos8 or EPEL 8, if any. But I was told by package maintainers that if it's added, then it will likely be an LTS version, so Django 2.2

Re: [Pulp-dev] uniqueness constraints within a repository version

ink we should do? > > Thanks! > Brian > > > > > > On Thu, Jun 27, 2019 at 4:03 AM Tatiana Tereshchenko > wrote: > >> Sure, the code can be de-duplicated. >> My main worry is that it's a responsibility of a plugin writer not to >> forget to ensure uniq

[Pulp-dev] RPM plugin meeting notes

General: - Fabricio joined RPM mini-team. Welcome! Pulp 2: - Dependency solving - 3 PRs in progress - Address copying module-defaults with modules - https://github.com/pulp/pulp_rpm/pull/1400 - Blocked on

Re: [Pulp-dev] Database support in Pulp 3

+1 to drop MariaDB support On Sun, Jul 14, 2019 at 10:10 PM Brian Bouterse wrote: > I believe we have reached a point where Pulp (core and its plugins) can no > longer support MariaDB due to technical problems. I've been an advocate for > Pulp to support MariaDB because it's what our users

[Pulp-dev] RPM plugin meeting notes

Pulp 2: - Modularity dep solving - automatic module_default copy works!! but is buggy, *crashes* - under investigation - "too many packages/modules are copied" issue - clear what to do, just needs to be done - Multiple source/target repositories support for recursive

[Pulp-dev] Few new fields are enabled in pulp.plan.io

Don't be surprised if you see 'Start date", "Due date" or "Estimated time" fields on any of the trackers for devs (issue/story/task/refactor) in pulp.plan.io. Those has been enabled to experiment with the Gantt chart feature. The fields may be disabled later, so don't rely on them being present.

Re: [Pulp-dev] Pulpcore RC3 Updates and Planning

I agree, it's fine to do nothing until the state of the redmine issue is critical for Pulp 3 release process. On Tue, Jul 2, 2019 at 3:47 PM David Davis wrote: > I think doing nothing for now makes sense. ON_QA doesn't seem to fit the > state of the issues and users can use the changelog for

[Pulp-dev] RPM plugin meeting notes

*June **2**7**, 2019* Pulp 2: - Modularity dep solving - fixes are not in 2.20.0 for now - refactoring and future PR: - https://github.com/pulp/pulp_rpm/pull/1383 - issue with dependencies being spread across multiple repos - discussion with Katello is planned

Re: [Pulp-dev] Katello Pulp 3 priority tags

Thanks for sharing. Are those flags used for the core only or plugins' issues will be tagged using those flags as well? Tanya On Wed, Jun 26, 2019 at 11:16 PM David Davis wrote: > I wanted to notify everyone of how we're defining Katello's tags on the > Pulp 3 integration work so that we're

Re: [Pulp-dev] uniqueness constraints within a repository version

replace the existing one. Maybe we start to 'order' the units with >>> colliding repo keys and keep the newest one always? Would this work for >>> pulp_cookbook and pulp_rpm? Would it generalize? Is this what you imagined? >>> >>> On Tue, Jun 25, 2019 at 5:30 AM

Re: [Pulp-dev] 2.20.0 Release Schedule

/2200_Release_Schedule On Mon, Jun 24, 2019 at 10:00 PM Tatiana Tereshchenko wrote: > A 2.20.0 dev freeze is scheduled for tomorrow, June 25, 2019 @ 23:00 UTC. > Please make sure everything which should be in 2.20.0 is merged by then, > including bug fixes. > > Thank you! > > On Tue, Jun 18, 20

Re: [Pulp-dev] uniqueness constraints within a repository version

Do I understand correctly that it doesn't cover the sync case and it's only about explicit repo version creation? So the suggestion is to implement the same logic twice: for sync case - RemoveDuplicates stage and/or maybe some custom stage (e.g. to disallow overlapping paths), and for direct repo

Re: [Pulp-dev] 2.20.0 Release Schedule

A 2.20.0 dev freeze is scheduled for tomorrow, June 25, 2019 @ 23:00 UTC. Please make sure everything which should be in 2.20.0 is merged by then, including bug fixes. Thank you! On Tue, Jun 18, 2019 at 3:33 PM Tatiana Tereshchenko wrote: > Just a reminder that a 2.20 dev freeze is approach

[Pulp-dev] RPM plugin meeting notes

Pulp 2: - Modularity bug updates https://pulp.plan.io/issues/4693 - a lot of progress - smash test is written, thanks to bherring Pulp 3: - JFYI, version for the master branch has been updated - master branch should always refer to .dev - more attention is needed

Re: [Pulp-dev] Pulp 2 to 3 Migration meeting on Wednesday June 19th

ig.2019-06-19-16.00.log.html [1] https://etherpad.net/p/pulp-2to3-migration On Tue, Jun 18, 2019 at 6:34 PM Tatiana Tereshchenko wrote: > An IRC meeting will be held on Wednesday June 19th at 12pm Eastern[0]. The > meeting will take place in #pulp-2to3-sig on Freenode IRC network. >

[Pulp-dev] Pulp 2 to 3 Migration meeting on Wednesday June 19th

An IRC meeting will be held on Wednesday June 19th at 12pm Eastern[0]. The meeting will take place in #pulp-2to3-sig on Freenode IRC network. Tentative agenda: - continue on use cases, see etherpad L18+ * especially distributors migration part * verify that everything is covered by the

Re: [Pulp-dev] black

-0 I'm usually all for consistency, and having standard style sounds good in theory. 1. What worries me is that there is basically no way back, we can't just try it out. Maybe waiting a bit to see if black has more adoption in the Python community and goes GA is not a bad idea. 2. Is now the

Re: [Pulp-dev] [Pulp-list] Pulp 2 to 3 Migration meeting on Thursday June 14th

y Pulp 2 before I have switched to Pulp 3. > > On Thu, Jun 13, 2019 at 4:16 PM Tatiana Tereshchenko > wrote: > >> The logs from the meeting can be viewed here[0]. >> The agenda was quite ambitious, the first item was partially covered and >> discussion will con

Re: [Pulp-dev] Pulp 2 to 3 Migration meeting on Thursday June 14th

-meeting-June-13-2019.txt [1] https://etherpad.net/p/pulp-2to3-migration On Wed, Jun 12, 2019 at 8:56 PM Tatiana Tereshchenko wrote: > An IRC meeting will be held on Thursday June 14rg at 10am Eastern[0]. The > meeting will take place in #pulp-2to3-sig on Freenode IRC network. > > Tent

[Pulp-dev] RPM plugin meeting notes

Pulp 2: - Modularity bug updates https://pulp.plan.io/issues/4693 - investigation in progress - dalley planned to collaborate with QE Pulp 3: - bindings - docs updated - announcement sent - bmbouter/dkliban gave overview of how bindings are generated and

[Pulp-dev] Pulp 2 to 3 Migration meeting on Thursday June 14th

An IRC meeting will be held on Thursday June 14rg at 10am Eastern[0]. The meeting will take place in #pulp-2to3-sig on Freenode IRC network. Tentative agenda: - go through use cases and see if we forgot anything, see etherpad L184+ [1] - verify that everything is covered by the current MP

[Pulp-dev] Do you ever need to uninstall plugin and remove all data related to it?

Currently there is no [documented] way to remove data related to the Pulp 3 plugin after you uninstall it. What is the use case when it's important to uninstall a specific Pulp 3 plugin? Do you expect data to go away after plugin is uninstalled? If not, do you expect to have the ability to remove

[Pulp-dev] RPM plugin meeting notes

Pulp 2: - Modularity bug updates https://pulp.plan.io/issues/4693 - As noted, erroneous behavior reproduced w/ modules in the Fedora modules repo - It seems like a lot of modules are copied correctly, but some aren't. Trying to figure out the pattern. -

[Pulp-dev] uniqueness constraints within a repository version

A while ago RemoveDuplicates stage [0] was introduced to solve the problem of enforcing uniqueness constraints within a repository version at sync time. The same problem ought to be solved when content which already exists in Pulp is added to a repository. E.g. Content was uploaded, or content was

[Pulp-dev] 2.20.0 Release Schedule

A 2.20.0 release is being planned with some features and recent fixes. Here [0] is a release schedule page which outlines some tentative dates, starting with a dev freeze on June 25, 2019 @ 23:00 UTC. The full list of features and bug fixes is not finalized yet, the current one can be found here

Re: [Pulp-dev] Release Note Process Improvements

+1 to improve release notes process If we decide to use PR numbers and not redmine issues in the release notes, then there will be no limitation/requirement to have a redmine issue to add something to the release notes. Tanya On Fri, May 24, 2019 at 3:46 PM David Davis wrote: > +1 to

[Pulp-dev] RPM plugin meeting notes

*May **23**, 2019* Pulp 2: - schedule for 2.20 - dkliban and ttereshc discussed it the other day - ttereshc to put it together today Pulp 3: - simple copy PR https://github.com/pulp/pulp_rpm/pull/1328 - there were some merge conflicts but its fixed now and ready to

Re: [Pulp-dev] breaking change: accept Null instead of empty string

+1 and +1 to allow only null and not both. Tanya On Tue, May 21, 2019 at 7:10 PM Brian Bouterse wrote: > > > On Tue, May 21, 2019 at 12:25 PM Dennis Kliban wrote: > >> Pulp 3's REST API does not accept Null as a value for a string field. The >> only way for a user to unset a string field is

[Pulp-dev] RPM plugin meeting notes

Pulp 2: - Some old issues which are fixed are still at ON_QA. daviddavis will move it to CLOSED-CURRENTRELEASE - https://pulp.plan.io/issues/3047 - https://pulp.plan.io/issues/3100 - https://pulp.plan.io/issues/3115 - 2.19.1 work - low participation, probably

[Pulp-dev] RPM plugin meeting notes

Pulp2: - Dev freeze for 2.19.1 is May 14 - Look for the pulp2 issues of the sprint, most of them should be fixed for 2.19.1 - the nice-to-have ones have comments that they are not critical to go into 2.19.1 specifically. - dkliban set platform release for 2.19.1

Re: [Pulp-dev] Pulp 3 tag

; go instead where there is no path and leave a trail." >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Apr 11, 2019 at 3:48 PM Brian Bouterse < >>>>>&g

[Pulp-dev] RPM plugin meeting notes

Pulp2: - many Pulp 2 items are on the sprint, including publish dir race condition - any deadlines/priorities? - need them in 2.19.1 (tentatively by the end of May) - https://pulp.plan.io/issues/4534 Searching for modulemd_defaults without "profiles" field will crash:

Re: [Pulp-dev] Master-detail inheritance in Pulp 3

I'm leaning towards option 2 "defining one-to-one field". Are there any downsides of that approach apart from one more field specified by plugin writers? It will keep class names and autogenerated endpoints nice and less redundant, and fair for all the plugins. On Tue, Apr 23, 2019 at 4:31 PM

[Pulp-dev] RPM plugin meeting notes

Pulp 2: - High priority issues? - publish race condition https://pulp.plan.io/issues/3098 - not RPM specific but affects RPM plugin as well (mostly noticeable for the Docker plugin) - volunteer is needed - Pulp 2 RPM bugs, mass closing - AI:

Re: [Pulp-dev] Pulp2 Bug Backlog Closing?

please >>> reach out via the "developer mailing list": >>> https://www.redhat.com/mailman/listinfo/pulp-dev. >>> >>> --- commend end >>> >>> >> That looks great to me. >> >> >> >>> On Tue, Apr 9, 2

Re: [Pulp-dev] Pulp2 Bug Backlog Closing?

Sounds good to me. One suggestion. How about asking for a contribution before closing, however only in cases when we expect to accept the contribution? e.g. not a huge or risky change, and the bug fix is important for a reporter. It will be clear for community that we are still willing to accept

[Pulp-dev] RPM plugin meeting notes

General: - ppicka joined RPM mini-team - welcome :) Pulp 2: - dkliban to plan release of 2.19.1 soon to release the migration issue https://pulp.plan.io/issues/4617 and other bugfixes which will be completed in time for the release - https://pulp.plan.io/issues/4631 Pulp

[Pulp-dev] RPM plugin meeting notes

General: - changes in Fedora 30 - remaining items are being evaluated (see details in the previous e-mail) Pulp2 - there are few issues on the sprint, nothing urgent at the moment Pulp3 - installer updates - bmbouter plans to work with asmacdo in the upcoming days

Re: [Pulp-dev] Pulp 2 and 3 Service Name Clashes

avid >> >> >> On Wed, Mar 20, 2019 at 2:10 PM Daniel Alley wrote: >> >>> +1 >>> >>> On Wed, Mar 20, 2019 at 1:11 PM Tatiana Tereshchenko < >>> ttere...@redhat.com> wrote: >>> >>>> Hi everyone, >>>> &g

[Pulp-dev] RPM plugin meeting notes

General: - We should track changes in Fedora and evaluate impact on Pulp - https://fedoraproject.org/wiki/Releases/30/ChangeSet - any volunteers? - Daniel(@dalley) - Possibly relevant changes: - Zchunk Metadata

Re: [Pulp-dev] Pulp 2 and 3 Service Name Clashes

gt;>> As I am spending time looking at deploying Pulp 3 alongside Pulp 2 in a >>> Katello environment, I'd like to get this change implemented as soon as >>> possible. This is mostly an operational change and should have a minimal >>> impact. >>> >>

Re: [Pulp-dev] pulp_file ownership

+1 move the pulp_file repo under the core team On Tue, Mar 19, 2019 at 10:10 PM Austin Macdonald wrote: > +1 for the latter. > > Since some changes to pulpcore or pulpcore-plugin also require changes to > pulp_file (anything backwards incompatible) everyone on the core team needs > to be able

Re: [Pulp-dev] 2.19.0 Dev Freeze , Monday, March 18 at 23:59 UTC

On Fri, Mar 15, 2019 at 10:34 PM Tatiana Tereshchenko wrote: > A 2.19.0 is planned to be released soon with some features and recent > fixes [0]. > The dev freeze for 2.19.0 will be on Monday. > > At the moment GA is expected to be on April 2. > More detailed schedule with t

[Pulp-dev] 2.19.0 Dev Freeze , Monday, March 18 at 23:59 UTC

A 2.19.0 is planned to be released soon with some features and recent fixes [0]. The dev freeze for 2.19.0 will be on Monday. At the moment GA is expected to be on April 2. More detailed schedule with the tentative dates for each Beta/RC/GA build will be posted in this thread later. [0]

[Pulp-dev] RPM plugin meeting notes

Pulp2 - https://pulp.plan.io/issues/4477 modular errata publication issue - on the sprint - should it be considered as a blocker for upcoming 2.19.0 - ttereshc will work on it - https://pulp.plan.io/issues/4541 packages are published twice, in different layouts -

[Pulp-dev] regenerate plugin migrations

The app label changed for the core, PR is merged [0]. Since plugin migrations depend on the core ones, please, regenerate migrations for the plugins you use after pulling the latest changes from the master branch. E.g. for pulp_file: remove everything from the migrations directory of the plugin,

[Pulp-dev] RPM plugin meeting notes

Pulp2 - https://pulp.plan.io/issues/4477 modular errata publication issue - needs to be worked on sooner rather than later, added to the sprint Pulp3 - Sync is failing https://pulp.plan.io/issues/4505#note-2 - likely a problem in core but easy to reproduce with RPM plugin

Re: [Pulp-dev] Pulp 2 and 3 Service Name Clashes

+1 to option 2, rename of Pulp2 services. It's a low risk change for Pulp2, in my opinion, and clear distinction of legacy version. I also agree with all the mentioned reasons to keep Pulp3 ones unchanged and more importantly without version in the name. -0 to make names configurable. Tanya On

[Pulp-dev] RPM plugin meeting notes

Pulp2 - recursive copy docs https://pulp.plan.io/issues/4371 , in progress - should be done today - new libsolv package, QE are blocked - if no news from the build team by the end of the week, bring up on Monday meeting Pulp3 - https://pulp.plan.io/issues/4424 -

Re: [Pulp-dev] Skipping plugin issues during triage

+1 to triage only pulp2/pulp3 core + pulp3 file plugin at that IRC meeting. We are doing it de facto anyway. It would be less !skip-!accept for a triage leader. ___ Pulp-dev mailing list Pulp-dev@redhat.com

[Pulp-dev] RPM plugin meeting notes

Pulp2: - https://github.com/pulp/pulp_rpm/pull/1269 approved, about to merge +1 +1 - AI: Ina to check with stakeholders if there is any required release date - checked, we can release according to our schedule Pulp 3: - https://pulp.plan.io/issues/4424 - How

Re: [Pulp-dev] Replicate a directory structure of a remote repo or not?

+pulp-list On Mon, Feb 18, 2019 at 6:14 PM Tatiana Tereshchenko wrote: > RPM plugin team discussed this question recently and we are leaning > towards a conclusion that by default Pulp is expected to publish a repo > with a directory structure of a remote repository. > > E.g

[Pulp-dev] Replicate a directory structure of a remote repo or not?

RPM plugin team discussed this question recently and we are leaning towards a conclusion that by default Pulp is expected to publish a repo with a directory structure of a remote repository. E.g. At the moment if no base_path is configured for a distribution, those two repositories [0][1] (same

[Pulp-dev] RPM plugin meeting notes

General discussion: - The commit bit to pulp/pulp_rpm has been given to QE team. - Codeowners [0] for functional tests in pulp/pulp_rpm - Agreed to add - AI: David to open PR to add codeowners. Add some docs to wiki. Pulp 2: - Potentially an issue with sync of Fedora 29

[Pulp-dev] app label changes merged, update your plugin

Hi all, There was a thread here about namespacing plugins + the idea of dropping `pulp_` from the app label. Those changes [0] are merged now and some plugins have already been updated. It is not necessary but it's encouraged to update the label of your plugin - to drop 'pulp_' part of it if you

[Pulp-dev] RPM plugin meeting notes

General discussion: - We had a discussion about a commit bit to pulp/pulp_rpm for QE team. Everyone who was present is on board. Many team members were out today, so the final decision is deferred till they are back. Pulp 2: - Modularity issues are solved and merged, thanks to

[Pulp-dev] pin pulpcore?

With more plugins going Beta and with frequent releases of pulpcore and pulpcore-plugin an issue with dependencies version showed up: - plugin requires pulpcore-plugin == 0.1.0bX - pulpcore-plugin 0.1.0bX requires pulpcore >= 3.0.0bY - at some point pulpcore introduces backward incompatible

Re: [Pulp-dev] QE commit bit

+1 On Wed, Jan 16, 2019 at 8:32 PM Brian Bouterse wrote: > This all sounds good to me. > > On Tue, Jan 15, 2019 at 2:25 PM Kersom wrote: > >> Robin, yeap. Exactly what you described it. >> >> On Tue, Jan 15, 2019 at 2:22 PM Robin Chan wrote: >> >>> Great. I withdraw: >>> #3. Shall we also

<    1   2   3   >