Re: [Pulp-dev] How to list orphan content in pulp3 before remocing them ?

Oh, ignore me, I didn't realize you don't need this to be via public HTTP API. On Thu, Apr 14, 2022 at 11:52 AM Daniel Alley wrote: > There is not a way to do this, figuring out which content are orphans is > pretty expensive so I'm not certain it would be suitable for an endpoint >

Re: [Pulp-dev] How to list orphan content in pulp3 before remocing them ?

There is not a way to do this, figuring out which content are orphans is pretty expensive so I'm not certain it would be suitable for an endpoint unless we changed how it works. On Thu, Apr 14, 2022 at 11:30 AM Sayan Das wrote: > Hello Grant, > > I hope you are doing great. > > Few other

[Pulp-dev] pulp_rpm 3.15.0 is generally available

For more information, check out the post on Discourse: https://discourse.pulpproject.org/t/pulp-rpm-3-15-0-release/102 ___ Pulp-dev mailing list Pulp-dev@redhat.com https://listman.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] [Pulp-list] Github Discussions

And Matrix integration. https://meta.discourse.org/t/chatroom-integration-plugin-discourse-chat-integration/66522 On Thu, Jun 17, 2021 at 1:11 PM David Davis wrote: > I was rather surprised but Discourse did approve us for a free plan. The > instance has been set up at

Re: [Pulp-dev] [Pulp-list] Github Discussions

> > It's pretty hard to do filtering of GitHub mail... I can't disagree with that. On Wed, Jun 16, 2021 at 4:35 PM Neal Gompa wrote: > Well, let's see if that works. Another concern I have is about > filtering stuff from discussions in Gmail. It's pretty hard to do > filtering of GitHub

Re: [Pulp-dev] Feedback Wanted, Upcoming Changes in Pulp Python

I mostly concur with Matthias, "pypi" is just as unlikely to lead to any namespace conflicts as "pulp_python/pypi/". It wouldn't be too significant either way, though. +1 to the general principle of the change. On Wed, May 19, 2021 at 4:01 AM Matthias Dellweg wrote: > Just one thought: > I

Re: [Pulp-dev] pulpcore 3.13.0 release schedule & go/no-go irc meeting

3.13.0 has been pushed back one more week, with a new date of May 25th. On Tue, May 11, 2021 at 10:58 PM Daniel Alley wrote: > Pulpcore 3.13.0 will be pushed back until next week, tentatively May 18th. > > Another go/no-go meeting will happen in #pulp-meeting at the time below: > &

[Pulp-dev] pulpcore 3.13.0 release schedule & go/no-go irc meeting

Pulpcore 3.13.0 will be pushed back until next week, tentatively May 18th. Another go/no-go meeting will happen in #pulp-meeting at the time below: May 11th, 3:00 PM UTC/May 7, 10:00 AM ET https://everytimezone.com/s/26b08bc3 ___ Pulp-dev mailing list

Re: [Pulp-dev] pulp_rpm and current backwards-compatibility problems

These are the commits that definitely need to be reverted (in-order). We also want to check up on the signing service, either to make sure the migration plugin doesn't hit that codepath, or that we're still compatible with 3.7 even though pulpcore 3.10 introduced some changes that we had to be

Re: [Pulp-dev] pulpcore 3.11.0 release schedule & go/no-go irc meeting

Correction: Pulpcore 3.13.0 On Thu, May 6, 2021 at 5:11 PM Daniel Alley wrote: > Here's the tracker for the pulpcore 3.13.0 release > https://pulp.plan.io/issues/8694 > The tentative GA date is May 12th, with a fallback date of May 18th. > > The first go/no-go meeting will

[Pulp-dev] pulpcore 3.11.0 release schedule & go/no-go irc meeting

Here's the tracker for the pulpcore 3.13.0 release https://pulp.plan.io/issues/8694 The tentative GA date is May 12th, with a fallback date of May 18th. The first go/no-go meeting will happen in #pulp-meeting at the time below: May 7th, 3:00 PM UTC/May 7, 10:00 AM ET

Re: [Pulp-dev] Tracking issues for plugin_template

I doubt there's any "good" way to link external bugs from Github because Mozilla doesn't do so. They just add an extra tag and you just have to find the link somewhere in the comments. e.g. https://github.com/servo/webrender/issues?q=is%3Aopen+is%3Aissue+label%3Abugzilled On Fri, Apr 23, 2021

Re: [Pulp-dev] Tasking System Changes and Feedback

e database today? > They aren't. We don't clean up anything automatically, cleanup is user-driven. On Tue, Apr 13, 2021 at 11:18 AM Eric Helms wrote: > > > On Thu, Apr 8, 2021 at 5:24 PM Daniel Alley wrote: > >> Eric, >> >> * The idea is to move away from RQ en

Re: [Pulp-dev] Tasking System Changes and Feedback

Eric, * The idea is to move away from RQ entirely. RQ is fine (and vastly better than Celery IMO), but managing task state across both 1) the database and 2) a separate, external registry is still problematic. If all of the information can simply be kept in the database, then it will be much

Re: [Pulp-dev] Content management and disk space clean-up

These bugs are not related to content management, but they are related to disk space (not being released) 4. Temporary artifacts not always cleaned up https://pulp.plan.io/issues/7316 5. Disk usage during sink https://pulp.plan.io/issues/8295 6. Worker directories not always cleaned up

Re: [Pulp-dev] Breaking change (for plugin writers) announcement

compatibility with 3.12. On Thu, Mar 4, 2021 at 3:49 PM Daniel Alley wrote: > *tl;dr* > > 1. Plugins compatible with 3.11 should *not* declare compatibility with > 3.12 > 2. Review the PR for your plugin below [0] and include it in your 3.12 > plugin compatibility release > >

[Pulp-dev] Breaking change (for plugin writers) announcement

*tl;dr* 1. Plugins compatible with 3.11 should *not* declare compatibility with 3.12 2. Review the PR for your plugin below [0] and include it in your 3.12 plugin compatibility release (PR review doesn't need to happen now, just in the next few weeks) *3.12 Plugin API Breaking Changes* In

Re: [Pulp-dev] [Pulp-list] Removing MD5 and SHA-1 as default available checksums in 3.11

Didn't know that about SLE 11, thanks. On Sun, Feb 14, 2021 at 9:28 PM Neal Gompa wrote: > On Sun, Feb 14, 2021 at 9:22 PM Daniel Alley wrote: > >> > >> RPM and Migration plugin users will need to add this back in at 3.11 > upgrade time for your systems to continue w

Re: [Pulp-dev] Backports and LTS

> > Matt, that is a good observation and meanwhile with pulp2 we had such a > policy, we cannot adopt it with pulp3. Release fast and release often is > something we are trying to stick to. > I don't think Matt was suggesting in any way that we not release fast and often, it's just that we have

Re: [Pulp-dev] RBAC: Secure by default?

+1 What happens if a new account is created on an existing Pulp installation (if that is possible)? Would it then start following the deny-by-default pattern? On Wed, Jan 6, 2021 at 8:57 AM David Davis wrote: > +1 from me. > > David > > > On Wed, Jan 6, 2021 at 8:28 AM Ina Panova wrote: > >>

[Pulp-dev] RPM plugin meeting notes

### November 19, 2020 AI review: none Pulp 3: * Do we need to generate SQLiteDBs at all? * https://pulp.plan.io/issues/7851 * https://pulp.plan.io/issues/7852 * https://pulp.plan.io/issues/7842 * introduce a switch, the default is not to generate sqlite metadata * black PR:

Re: [Pulp-dev] Travis pricing

It depends on how much the 80/20 rule applies. If we had a breakdown of which jobs are using how many minutes, I bet we could get that number way down just by cleaning up a couple of jobs. None of these platforms support nested virt (actually Travis doesn't officially support it either, it just

[Pulp-dev] RPM plugin meeting notes

### October 29, 2020 AI review: none Pulp 3: * Need to be able to specify a custom 'gpgkey' string for a Publication. * Should do a new release - any blockers? * check for deprecations in pulpcore that affect the plugin * decide at next week's meeting Pulp 2: * 2.21.4 release

[Pulp-dev] RPM plugin meeting notes

AI review: none Pulp 3: * Content upload API improvement: https://pulp.plan.io/issues/7708 * Valid UX problem, could be difficult to fix "correctly" * Potentially changes necessary to the task response * Pulp 4 change? * Multi-repo copy issues: https://pulp.plan.io/issues/7625

Re: [Pulp-dev] PR merging

ice "merge when CI passes >>> button" to decouple the merge question from the reviews. >>> The only way i could see this happen in Github is via setting a label >>> that instructs the PR processor to merge when (label is set) && (ci is >>> green)

Re: [Pulp-dev] PR merging

I have some doubts about the cost/benefit ratio of coding automation to merge PRs vs. simply changing the default option / being selective about which options are available. I like the idea in general though. A lot of projects do something like this. I occasionally contributed to the Servo

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

I suggest that we re-use the pulp_packaging github repo since it has a related purpose and already exists :) Also, for what it's worth, HackMD supports markdown checklists as well. I lean more towards the github issue approach personally but it's worth mentioning. On Wed, Aug 19, 2020 at 11:03

Re: [Pulp-dev] Meeting Minutes: Lockless pulp

I strongly support this, or at least strongly support having a discussion about it. I think we can't make this change for Pulp 3, but we should absolutely consider moving in this direction for Pulp 4. One (IMO large) "pro" which I didn't see mentioned here is auditability. It is essentially

Re: [Pulp-dev] saftladen pulp's take on asciinema?

> > Like a juice store whose shopman tells you no orange juice today, next > delivery in two weeks. > Reminds me of this Monty Python sketch https://www.youtube.com/watch?v=Hz1JWzyvv8A On Thu, Aug 6, 2020 at 3:24 AM Matthias Dellweg wrote: > > > On Wed, Aug 5, 2020 at 8:02 PM Robin Chan

Re: [Pulp-dev] pulp-owned pypi packages that pulp did not author

gt; > On Tue, Jul 14, 2020 at 5:22 PM Daniel Alley wrote: > >> Thanks Daniel, >>> >>> I've reposted to pulp-dev, so you might want to re-post your reply >>> there too, but: >>> >>> Great, if createrepo and libcomps is jus

Re: [Pulp-dev] pulp-owned pypi packages that pulp did not author

eren't even sure if it was possible - and I found this discussion at the same time as I was already wanting to package it anyway for Pulp. > > On Tue, Jul 14, 2020 at 9:47 AM Daniel Alley wrote: > My apologies! s/Evengi/Evgeni, the letters got swapped in my brain : / > > On Tue, J

Re: [Pulp-dev] pulp-owned pypi packages that pulp did not author

My apologies! s/Evengi/Evgeni, the letters got swapped in my brain : / On Tue, Jul 14, 2020 at 9:37 AM Daniel Alley wrote: > Reposting my response from the other thread: > > Hi Evengi, > > In the case of createrepo_c and libsolv, the upstream merged all of the > build script

Re: [Pulp-dev] pulp-owned pypi packages that pulp did not author

Reposting my response from the other thread: Hi Evengi, In the case of createrepo_c and libsolv, the upstream merged all of the build script changes that were necessary to enable producing Python packages, so in that sense the packages we are producing are completely unmodified. However, the

Re: [Pulp-dev] Name uniqueness problem in Pulp 3 REST API

Why would it cause pain (to relax the restriction)? On Tue, Jun 30, 2020 at 4:46 PM Grant Gainey wrote: > On Tue, Jun 30, 2020 at 3:54 PM Dennis Kliban wrote: > >> The REST APIs for repositories in Pulp 3 do not allow a name to be reused >> between repository types. e.g.: A File Repository

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

; though and is better in some ways. > > Changing the RepositoryContent model to point to ContentArtifacts and > store relative_paths is probably the best and most correct solution in > theory. However, it's going to be painful to implement for both core and > plugins. > > David &g

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

; On Tue, Apr 28, 2020 at 10:30 AM Matthias Dellweg > wrote: > >> That is only used for passthrough publication afaik. If you publish each >> content unit "by hand", you create a new relative path for each published >> artifact. That is, why it can be empty and still

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

oryContent would not be possible. On Mon, Apr 27, 2020 at 6:08 PM Daniel Alley wrote: > There is a video call scheduled to discuss this issue tomorrow (Tuesday > April 28th) at 13:30 UTC (please convert to your local time). > https://meet.google.com/scy-csbx-qiu > > On Sat, Apr 25, 20

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

ted to be kept in the loop as this moves >> forward. (Mailing list once there is some movement is entirely sufficient >> ) >> >> >> Thanks, >> >> Quirin Pamp >> -- >> *From:* pulp-dev-boun...@redhat.com on >> b

Re: [Pulp-dev] pulp_file 1.0

+1 to 1.0 On Mon, Apr 27, 2020 at 5:57 AM Ina Panova wrote: > Based on the extended reply from David referring to semver, I am in favour > or releasing pulp_file 1.0. > > Also, comments inline. > > Regards, > > Ina Panova > Senior Software Engineer| Pulp| Red Hat Inc. > > "Do not go

Re: [Pulp-dev] serializers in pulp 3 can't use write_only fields

I just want to point out that we have a somewhat similar kind of feature implemented, "minimal serializers", which uses the 2-serializer approach. It is a very tiny amount of extra code/work. e.g. https://github.com/pulp/pulpcore/blob/master/pulpcore/app/serializers/task.py#L119

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

lows 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 brok

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

> > 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.

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

c directly I like proposed move to 'RepositoryContent' and > add it to its uniqueness constraint (if I understand well). > > [0] https://github.com/pulp/pulp_rpm/pull/1657 > [1] https://github.com/pulp/pulp_rpm/pull/1642 > [2] tested with centos 7, 8, opensuse and SLE repositories > >

[Pulp-dev] the "relative path" problem

We'd like to start a discussion on the "relative path problem" identified recently. 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.

Re: [Pulp-dev] SUSE repositories in Pulp

I think, as long as the metadata is correct, using just the location_href would be OK. It should contain all the other bits of information. On Mon, Mar 23, 2020 at 3:57 PM David Davis wrote: > A couple questions below. > > On Mon, Mar 23, 2020 at 3:47 PM Tatiana Tereshchenko > wrote: > >>

Re: [Pulp-dev] SUSE repositories in Pulp

> > I propose that we not add a separate repository type for SUSE and simply > add the 'location' attribute of an RPM to it's uniqueness constraint. What > do you all think? +1 On Mon, Mar 23, 2020 at 2:01 PM Dennis Kliban wrote: > During last week's RPM team meeting, a concern was raised

Re: [Pulp-dev] PR Processor

This is great! Awesome work, David <3 On Sat, Mar 21, 2020 at 10:38 AM David Davis wrote: > I created a PR workflow in Github Actions so I could learn more about > Github Actions. > > Here's the issue and my PR against plugin_template: > > https://pulp.plan.io/issues/4365 >

Re: [Pulp-dev] Duplicate nevra but not pkgId (suse repos)

I discussed this a little bit on the #rpm.org channel. Here is the gist of that discussion - The metadata is "crazy, but technically valid" - "the entire SUSE ecosystem tends to do this a lot, anything using OBS, including nvidia and dell and friends" - "also, SUSE packages can have

Re: [Pulp-dev] Read access in Github

+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

Re: [Pulp-dev] Moving to Github Actions

f we look at the development team and determine if we can meet all > of our goals while fully dedicated 1-3 people to this other effort. > > Let me know how I can help. Thank you both and Fabricio for continuing to > drive this improvement for the community. > > -Brian > > &

Re: [Pulp-dev] Moving to Github Actions

I agree that Centos CI should be a high priority, however I think it is still important to discuss what we want our end-state to look like, because that will strongly influence our approach going forwards. And FWIW, I don't think Fabricio's work will do any harm in this respect, especially given

Re: [Pulp-dev] Moving to Github Actions

I think we should start by discussing what we ultimately want our CI to look like. Do we want to replace all of our CI with Centos CI, universally and exclusively? Do we want to run some tests on Centos CI nightly but retain something simpler for our standard PR test matrix? I definitely agree

Re: [Pulp-dev] Not equal filters

Going by the comments in this PR [0], if something like this would be used with the API bindings, wouldn't the name__ne=value scheme be better? It also just generally seems a bit more consistent. [0] https://github.com/pulp/pulpcore/pull/316/files On Wed, Jan 29, 2020 at 10:51 AM David Davis

Re: [Pulp-dev] Markdown conversion on pulp.plan.io

I vote "as soon as possible" :) Definitely a welcome change! On Wed, Jan 29, 2020 at 9:40 AM Brian Bouterse wrote: > plan.io (who hosts pulp.plan.io) is switching to markdown. See their > blogpost here [0]. They are offering a "conversion" service to convert > existing data to markdown. > > I

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

Excellent work, Fabricio! This is a big deal :) On Tue, Jan 28, 2020 at 10:06 AM Fabricio Aguiar wrote: > > With #6020 *plugin_template* > functional tests now use *bindings* instead of making REST calls to pulp. > This brought the need for installing

Re: [Pulp-dev] API for repairing bitrot -- input requested

Re: Option A, I'm not sure if my concern is warranted, but I'm a little wary of adding features to the RepositoryVersion endpoint because it already is special-cased in the bindings generator and it's kind of weird due to the nesting and the way it's sort-of generic but also exists under the

Re: [Pulp-dev] Hanging tasks (reloaded)

@Matthias Dellweg Would you be willing to file an issue? On Tue, Jan 21, 2020 at 4:51 PM Daniel Alley wrote: > I'm not sure why I can't reproduce the issue on either of my machines but > I think it would be proper to re-pin redis until we get it figured out. PR > here: https://g

Re: [Pulp-dev] Hanging tasks (reloaded)

s VM provider is libvirt with an additional > `domain.volume_cache = 'unsafe'` setting. Write I/O is probably > extremely fast in this setup (VM can't force flush to disk) > > > On Tue, Jan 21, 2020 at 12:22:33PM -0500, Daniel Alley wrote: > >4 runs on Fedora 31 has not trigger

Re: [Pulp-dev] Hanging tasks (reloaded)

4 runs on Fedora 31 has not triggered it either. This is using the latest version of redis-py, 3.3.11, and redis 5.0.7. On Tue, Jan 21, 2020 at 11:16 AM Daniel Alley wrote: > So far I've run it 4 times back to back on a CentOS 7 box and not had any > lockups. I'll try Fedora > > On

Re: [Pulp-dev] Hanging tasks (reloaded)

> (pinning) redis-py completely solves the issue. > > On Tue, 21 Jan 2020 09:16:43 -0500 > Daniel Alley wrote: > > > @Matthias Dellweg > > did you restart Pulp after upgrading redis-py? Are you seeing this on > > fresh boxes, or does it require some modifi

Re: [Pulp-dev] Hanging tasks (reloaded)

ite-packages/redis/connection.py", > line 1114, in release Jan 21 09:23:10 > pulp3-source-fedora30.anubis.example.com rq[23269]: > self._in_use_connections.remove(connection) Jan 21 09:23:10 > pulp3-source-fedora30.anubis.example.com rq[23269]: KeyError: > Connection Jan 21

Re: [Pulp-dev] Hanging tasks (reloaded)

Different issue perhaps? Are you seeing anything in the logs that looks like this? https://github.com/rq/rq/issues/1044 On Fri, Jan 17, 2020 at 9:06 AM Daniel Alley wrote: > Strange, I'm pretty sure an issue like this is why we pinned originally, > but upstream said that that particular

Re: [Pulp-dev] Hanging tasks (reloaded)

Strange, I'm pretty sure an issue like this is why we pinned originally, but upstream said that that particular issue was (supposedly) fixed. https://github.com/andymccurdy/redis-py/issues/1136#issuecomment-571168161 On Fri, Jan 17, 2020 at 4:15 AM Matthias Dellweg wrote: > Hello all, > I

Re: [Pulp-dev] RPM plugin Copy API discussion

Pulp Project > *irc*: rochacbruno > > *social*: http://about.me/rochacbruno > > “Progress is the realization of utopia.” > <https://red.ht/sig> > > > On Thu, Dec 12, 2019 at 5:52 PM Daniel Alley wrote: > >> In the coming weeks we will need to settle on a strateg

[Pulp-dev] RPM plugin Copy API discussion

In the coming weeks we will need to settle on a strategy for the Pulp 3 advanced copy APIs for the RPM plugin. This is one of, if not the most complicated plugins, so there are a lot of factors to consider. We'd like to invite the community to participate in the discussion and get an idea of what

[Pulp-dev] [Breaking] Minor change to typed repositories

There is a minor change for Pulp 3 plugin writers Repository models merging today. It's a very simple one-line code change. On your Repository subclass, define the CONTENT_TYPES constant as a list with all of the Content types (the classes) supported by this type of repository, like this:

Re: [Pulp-dev] Memory consumption on RPM sync

Fabricio, this is great work! One thing that stands out is that a very large amount of time is being spent in remove_duplicates(), 65% of the total runtime of the sync. - 13% of the total runtime spent on this inside cast()

Re: [Pulp-dev] [Breaking Change] Typed Repositories

e primary motivation for typed repositories was to resolve the design >> challenges encountered on https://pulp.plan.io/issues/3541 I'm going to >> do the following ASAP: >> >> 1) update 3541's design with the input from the thread: >> https://www.redhat.com/a

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

Agreed, I would also rather keep [noissue]. That is a good example of when it is useful. We can and should pay more attention to when it's being used in the PR review process, though. On Wed, Nov 6, 2019 at 12:26 PM Tatiana Tereshchenko wrote: > I'm leaning towards keeping [noissue] and have

[Pulp-dev] [Breaking Change] Typed Repositories

In accordance with the rationale laid out in issue #5625 [0], we will be merging a change that will make repositories a typed object in Pulp. This will require some work by plugin writers to become compatible post-merge. We're aiming to merge these changes on Wednesday if possible. There is

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

ust only import from pulpcore.plugin (still) > > On Wed, Oct 23, 2019 at 10:13 AM Daniel Alley wrote: > >> Since we decided to move forwards with this, here are the PRs: >> https://pulp.plan.io/issues/5580#note-8 >> >> On Fri, Oct 18, 2019 at 5:29 AM Ina Panova wrote

Re: [Pulp-dev] PulpCon Community Day videos

Link correction: https://bluejeans.com/s/4zL_F On Wed, Oct 23, 2019 at 6:59 AM Daniel Alley wrote: > Big thanks to all of our speakers yesterday! > > > https://redhat.bluejeans.com/playback/guid/OTQ4NDEwNzA1NjozOTU2MjgtNTJkMThlZjQtNjMxNC00OTExLTkwZWEtNjIx

[Pulp-dev] PulpCon Community Day videos

Big thanks to all of our speakers yesterday! https://redhat.bluejeans.com/playback/guid/OTQ4NDEwNzA1NjozOTU2MjgtNTJkMThlZjQtNjMxNC00OTExLTkwZWEtNjIxNjIwMzVkMTRl ___ Pulp-dev mailing list Pulp-dev@redhat.com

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

pcore==3.y.z >>>>>>>>> itself. >>>>>>>>> >>>>>>>> >>>>>>>> Great, that makes things easier for users' manual installs, and >>>>>>>> easier for containers/pack

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

Very Large +1 On Wed, Oct 16, 2019 at 2:10 PM Brian Bouterse wrote: > Having just released RC7, there are a variety of problems we are dealing > with as a result of having pulpcore and pulpcore-plugin being in separate > repos. @daviddavis and I were talking, and we want to ask for feedback on

[Pulp-dev] [BREAKING] Custom JSONField

Pulp 3 has previously exposed a custom JSONField implementation (backed by a normal Django TextField) for use by plugins. With the decision to specialize on Postgres, this is no longer necessary as Postgres has it's own native and well-supported JSONField implementation. Thus,

[Pulp-dev] Pulp 2.21.0 Dev Freeze

The code for 2.21.0 is frozen. The list of features and fixes can be found here [0]. The RC build is expected on September 18, 2019 (one week from today), see the release schedule [1]. [0] https://pulp.plan.io/issues?query_id=61 [1] https://pulp.plan.io/projects/pulp/wiki/2210_Release_Schedule

[Pulp-dev] Pulp 2.21.0 schedule

A 2.21.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 September 11th, 2019 @ 22:00 UTC. The full list of features and bug fixes to be released can be found here [1]. [0]

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

Ina and I discussed this earlier today and she made good points -- she pointed out that what I suggested wouldn't work for content types that have relations on non-content models, as several content types in the Docker and Python plugins do. So, I no longer think it's a good idea to have an

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

content/rpm/packages/copy/ > And pushing as many of the truly generic features to core as possible, such as copying all units of certain type(s). On Wed, Jul 31, 2019 at 12:43 PM Daniel Alley wrote: > revision to use case C) > > copying all units of a type (e.g. RPM) --> copying al

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

revision to use case C) copying all units of a type (e.g. RPM) --> copying all units of one or many types (e.g. RPM) On Wed, Jul 31, 2019 at 12:40 PM Daniel Alley wrote: > For the copy case, it's common to copy more than one type, I think, so >> probably 'plugin/copy/ types=[]

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

> > For the copy case, it's common to copy more than one type, I think, so > probably 'plugin/copy/ types=[]' makes more sense. > Thanks for this thread. I'm +1 on documenting these general conventions in > the pulpcore-plugin docs for plugin writers. Maybe we could include a > section on URLs so

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

+1 Y releases On Tue, Jul 30, 2019 at 12:01 PM Brian Bouterse wrote: > +1 to pin Y releases > > On Tue, Jul 30, 2019 at 8:41 AM Tatiana Tereshchenko > wrote: > >> +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

Re: [Pulp-dev] Install Pulp3 rpm plugin (createrepo_c install failure)

There's a couple of suggestions how to fix this in these issues https://github.com/pypa/setuptools/issues/1694#issuecomment-466010982 https://github.com/pypa/setuptools/issues/1685#issuecomment-462942577 On Mon, Jul 29, 2019 at 7:37 AM Pavel Picka wrote: > Hey, anyone tried install pulp3 rpm

Re: [Pulp-dev] Proposal to move Pulp 2 dev environment to CentOS

> dawal...@redhat.com >> > <https://www.redhat.com> >> > >> > >> > >> > On Wed, Jul 24, 2019 at 1:18 PM Grant Gainey >> > wrote: >> > >> > > +1 >> > > >> > > On Wed, Jul 24, 2019 at 12:52 PM Kers

Re: [Pulp-dev] Proposal to move Pulp 2 dev environment to CentOS

Absolutely! This applies to Pulp 2 only. Our Pulp 3 development environment already gives you the option to pick between different Fedora versions, CentOS, CentOS + FIPS, Debian, etc. On Wed, Jul 24, 2019 at 11:44 AM Neal Gompa wrote: > On Wed, Jul 24, 2019, 11:40 AM Daniel Alley wr

[Pulp-dev] Proposal to move Pulp 2 dev environment to CentOS

Proposal: The pulp/devel repository will install a CentOS 7 base box instead of a Fedora 28 one Rationale: * CentOS / RHEL is what our users are using. Using a different platform can result in different behavior in the development environment vs what users see -- this happened to me recently

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

We've already adopted Django 2.2 several months ago (in setup.py), so I'm not sure if any action item is needed there On Tue, Jul 23, 2019 at 10:42 AM Brian Bouterse wrote: > +1 to adopting the Django 2.2 since it's an LTS. We should get a ticket > written for it. > > In terms of the installer,

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

RC4. >>> To remove MariaDB testing from Travis I propose we remove it from the >>> plugin_template and use the Travis CI tool from @dkliban to push that >>> config out to all repositories. >>> >>> I'll be offline this week. I wanted to get this reply out the

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

One more note: Not all MySQL / MariaDB installations support transactions, which we use heavily (and rely on?) https://docs.djangoproject.com/en/2.2/topics/db/transactions/#transactions-in-mysql On Thu, Jul 11, 2019 at 3:55 PM David Davis wrote: > Two plugins are currently running into issues

Re: [Pulp-dev] black

+0 On Mon, Jun 17, 2019 at 1:15 PM Brian Bouterse wrote: > +1 to adopting this. Thank you @daviddavis for writing > > On Mon, Jun 10, 2019 at 1:58 PM David Davis wrote: > >> I opened PUP-8 that proposes adopting black and pydocstyle[0] along with >> a PR against pulpcore to demonstrate how it

Re: [Pulp-dev] Docstring linting

+1 to create a PUP (-0 to actually adopting it. No particularly strong feelings though.) On Thu, Jun 6, 2019 at 4:21 PM Dana Walker wrote: > +1 > > Dana Walker > > She / Her / Hers > > Software Engineer, Pulp Project > > Red Hat > > dawal...@redhat.com >

Re: [Pulp-dev] Release Note Process Improvements

+1 On Tue, May 28, 2019 at 2:23 PM Dennis Kliban wrote: > +1 > > I updated the task[0] slightly and marked it as groomed. > > > [0] https://pulp.plan.io/issues/4875 > > On Tue, May 28, 2019 at 12:14 PM Austin Macdonald > wrote: > >> The proposed changes look awesome! I'm +1 for moving forward

[Pulp-dev] ergonomics of providing Pulp with lists of items

Providing Pulp with lists of values from the command line is rather unweildy. There's a lot of unnecessary escaping going on. http POST :24817${REPO_HREF}versions/ add_content_units:="[\"$CONTENT_HREF\",\"$CONTENT_2_HREF\"]" http POST http://localhost:24817/pulp/api/v3/rpm/copy/

Re: [Pulp-dev] Content Copy (between repos)

objections? On Mon, Apr 8, 2019 at 10:35 AM Brian Bouterse wrote: > > > On Sat, Apr 6, 2019 at 11:48 AM Justin Sherrill > wrote: > >> >> On 4/4/19 2:35 PM, Daniel Alley wrote: >> >> Content copy between repositories is critically important to Katello >&

Re: [Pulp-dev] Pulp 3 tag

> > I feel like using the Pulp 3 tag is suboptimal since we are closing out > most of our Pulp 2 issues and a majority of the new bugs/tasks/stories are > for Pulp 3. Wouldn’t it make more sense to create a Pulp 2 tag and use it > on the rare Pulp 2 issues that get filed? Agreed, +1 to having a

Re: [Pulp-dev] YouTube Custom URL

"Only way to be sure is to try it, but if no one has any other suggestions, then the order we will try things would be Pulp, PulpProject, and PulpProj." +1 On Thu, Apr 11, 2019 at 8:47 AM Dana Walker wrote: > So it turns out youtube doesn't reserve channels to match users. The > *user* Pulp

[Pulp-dev] Content Copy (between repos)

Content copy between repositories is critically important to Katello integration and is something that we have not really addressed yet. It also needs to be completed before the RPM plugin can begin work on depsolving. The story that results from this discussion should probably be put on one of

Re: [Pulp-dev] Mirroring Anaconda Repositories

Hello Nathaniel, > I currently don’t see a Anaconda plugin available for Pulp. Do you know if > any of the other plugins would help facilitate that, or if there is an > Anaconda plugin being developed (didn’t see one on Git)? There isn't one yet (either developed or in development), but it's

[Pulp-dev] SUSE has an unrelated library named "libpulp"

A user on IRC pointed out that there is a new-ish C library by SUSE named libpulp. https://github.com/SUSE/libpulp Since it's a C library and contains no Python, there is no PyPI name conflict like there we had with PuLP, and I don't particularly see a need to ask them to rename their project.

  1   2   3   >