Re: [Pulp-dev] PyPI names for Pulp3

I would prefer pulp3 over pulpproj, nice idea Bihan! On Wed, Apr 12, 2017 at 1:47 AM, Dennis Kliban wrote: > I like using the pulp3 namespace. > > On Tue, Apr 11, 2017 at 9:13 AM, Bihan Zhang wrote: > >> What about pulp3 as a potential namespace? With

Re: [Pulp-dev] PyPI names for Pulp3

+1 pulpapp +0 pulpproj On Thu, Apr 20, 2017 at 7:05 AM, Ina Panova wrote: > we have not considered yet 'pulpapp' > > pip install pulpapp > pip install pulpapp_cli > pip install pulpapp_streamer > > > > > Regards, > > Ina Panova > Software Engineer| Pulp| Red Hat

Re: [Pulp-dev] Merging forward commits

+1 On Mon, Feb 6, 2017 at 12:09 PM, Ina Panova wrote: > Seems like we are trying to choose/figure out what's more important - > linear commit history which is readable or confidence and ability to track > where exactly change had been applied? > > I agree with Mike and think

Re: [Pulp-dev] PyPI names for Pulp3

>>> 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 > > -- Daniel Alley Associate Software Engineer Red Hat <https://www.redhat.com> <https://red.ht/sig> ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] python namespace proposal

+1 On Fri, May 12, 2017 at 12:13 PM, Jeff Ortel wrote: > +1, This sounds good to me. > > On 05/11/2017 10:59 AM, Michael Hrivnak wrote: > > We had a brainstorm session today to re-evaluate the > previously-identified options, and try to come up with > > some new ones. None of

Re: [Pulp-dev] PUP Process: "obvious consensus"

We could use the metric that a PUP passes if there are no -1s and more than 1/3 of the team considers it an improvement (+0 or +1). If more than 2/3rds the team is voting -0, it probably needs more discussion. On Mon, Jun 12, 2017 at 11:49 AM, Bryan Kearney wrote: > I

Re: [Pulp-dev] Terms: unassociate vs. disassociate

+1 Add/remove is definitely more clear. Associate/disassociate feels like more of an engineering terminology. On Wed, May 24, 2017 at 6:06 AM, Ina Panova wrote: > +1 for add/remove. An aside note, i want to make sure we stick to 'remove' > specifically' and not 'delete'. >

Re: [Pulp-dev] 'Pulp 3 installer' tag added to pulp.plan.io

+1, the ansible roles are large enough that having their own tracker makes a lot of sense. On Tue, Oct 17, 2017 at 3:17 PM, Dennis Kliban wrote: > We should tag all these as 'Pulp 3 installer'. If you have some issues in > mind, please add that tag. > > On Tue, Oct 17, 2017

[Pulp-dev] [pulp_python] Roadmap and wishlist for future versions of the Pulp Python plugin

Pulp 3 development is in full swing, and we've begun thinking about what we may want out of future versions of the Python plugin. We would love your input, too! We've created a wiki page on pulp.plan.io detailing our initial thoughts on what the Pulp Python plugin should look like, and how the

Re: [Pulp-dev] Infrastructure tracker on pulp.plan.io

Would this new tracker be the proper home for issues regarding Jenkins, Travis, nodepool, etc? And, if so, should we move those issues out of whichever trackers they exist in currently (many in "Pulp Packaging" [0], a few in "Pulp" [1] [2] [3], etc.) [0]

Re: [Pulp-dev] Feedback Requested: Language Guide PR

+1 to this, thank you Austin! On Thu, Dec 14, 2017 at 11:20 AM, Austin Macdonald wrote: > I've written up a high level overview of Pulp 3 concepts and definitions. > It is my hope that sharpening our language will help us to be internally > consistent in our docs, on the

Re: [Pulp-dev] Voting for PUP 4: Code of Conduct

+1 On Tue, Dec 12, 2017 at 12:25 PM, Dennis Kliban wrote: > We had some discussion about this PUP in a separate thread[0]. We have now > reached consensus on the wording of the PUP to open it up to voting. > > To refresh everyone’s memory, voting is outlined in PUP-1: > >

Re: [Pulp-dev] Deferring 3 things for Pulp3 to 3.1+

+1 here too On Wed, Dec 13, 2017 at 8:28 AM, David Davis wrote: > I think this makes sense. +1 from me. > > > David > > On Tue, Dec 12, 2017 at 11:47 AM, Brian Bouterse > wrote: > >> As we get to the end of the MVP planning for Pulp3, I want to

Re: [Pulp-dev] Proposing dropping old fedora releases for 2.15

+1 On Mon, Nov 20, 2017 at 9:24 AM, Ina Panova wrote: > +1 > > > > > Regards, > > Ina Panova > 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, Nov 14, 2017 at 4:18 PM,

Re: [Pulp-dev] Let's use immutable resource URIs for all resources in pulp 3

+1 On Thu, Nov 9, 2017 at 3:27 PM, Jeff Ortel wrote: > +1 > > On 11/09/2017 02:01 PM, Dennis Kliban wrote: > > Pulp 3 currently uses a resource's 'name' attribute to form a URI for > that resource. However, the name is > > usually mutable and as a result can cause some

Re: [Pulp-dev] [pulp_python] Roadmap and wishlist for future versions of the Pulp Python plugin

ally like the use cases > presented. Since this document is meant to be shared with Pulp users and > most of our users are probably not subscribed to pulp-dev list, we should > probably send out this email to the pulp-list also. What do you think? > > -Dennis > > On Mon, Oct 23,

Re: [Pulp-dev] Port Pulp3 to use RQ

idea is that it's valuable and looks >>> > feasible, but we won't really know until we prototype it a bit. Based >>> on the >>> > technical outline in the previous email, I believe it can be >>> prototyped in a >>> > day or two. I plan to do th

[Pulp-dev] Content types which are not compatible with the normal pulp workflow

Some content types are not going to be compatible with the normal sync/publish/distribute Pulp workflows, and will need to be live API-only. To what degree should Pulp accomodate these use cases? Example: Pulp makes the assumptions that A) the metadata for a repository can be generated in its

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

Maybe _created > _id > _last_updated > ? I'm not sure whether we use pk or id more often, but we use both quite a lot. On Wed, May 23, 2018 at 9:22 AM, David Davis wrote: > Correct me if I’m wrong but don’t we call pk in most places instead of id? > If so, it would

Re: [Pulp-dev] Content types which are not compatible with the normal pulp workflow

ntent into one place, and that > place having a tasking system that plugin writers can control how their > content can be analyzed continuously. > > Also +1 to jortel's idea. I think that's a great idea and exactly what we > need. > > > On Thu, May 24, 2018 at 1:3

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

> > The article[1] you mentioned states that 'ID' *should* be used for the PK It does say this, but it says that the reasons for doing that are because id is "short, simple, and unambiguous", and that the reason you shouldn't prefix is because "the extra prefix is redundant". I think it's

Re: [Pulp-dev] Ideas for the plugin template

+1 On Mon, Jun 18, 2018 at 12:16 PM, Brian Bouterse wrote: > +1 > > On Mon, Jun 18, 2018 at 8:47 AM, Ina Panova wrote: > >> +1 >> >> >> >> >> Regards, >> >> Ina Panova >> Software Engineer| Pulp| Red Hat Inc. >> >> "Do not go where the path may lead, >> go instead where there is no

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

quot;Do not go where the path may lead, >> go instead where there is no path and leave a trail." >> >> On Thu, Jun 14, 2018 at 9:38 PM, Jeff Ortel wrote: >> >>> >>> >>> On 06/14/2018 12:19 PM, Jeff Ortel wrote: >>> >>>> >>>>

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

> > just curious, where does the rpm 'id' come from and how is it used > differently than the NEVREA composite natural key. It's a part of Erratum, not the actual RPM content, so it's unrelated to NVREA. An example of an errata "id" would be "RHEA-2013:1777". I agree with your point about '_id'

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

> > 1) If we do this, what happens when someone uses multiple plugins and both > of them want to use id as well? Wouldn't it be better to have the core > application reserving it and *all* plugins doing some derivative name? > One plugin wouldn't affect another since it's namespaced by table -

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

it would have "pk" as > reserved and "_id" since we define the primary key in the ancestor class > they inherit from. It also would have "_created" and "_last_updated" > reserved. This should cause minimal collisions with the plugin writer's >

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

ld then core code using using 'object.pk' will cause >>> core code to receive their attribute and not the primary key. I think >>> overall the strategy I think to minimize collisions we should use >>> 'object._id' directly. How does that sound? >>> >>> @jorte

Re: [Pulp-dev] PUP5 -- Adopting the "Common Cure Rights Commitment" for Pulp Core

+0 On Thu, May 31, 2018 at 3:49 PM, Robin Chan wrote: > Voting closes June 2nd. > > I have read this through and appreciate @richardfontana's > response/explanation to questions: https://github.com/pulp/pups/ > pull/9#issuecomment-393317027 > > +1 > > On Wed, May 23, 2018 at 11:29 AM, Dennis

Re: [Pulp-dev] Content types which are not compatible with the normal pulp workflow

ing synced / uploaded into Pulp One of them has to give. On Mon, May 28, 2018 at 8:01 AM, Milan Kovacik <mkova...@redhat.com> wrote: > On Sat, May 26, 2018 at 2:23 AM, Daniel Alley <dal...@redhat.com> wrote: > > @Brian > > > > I agree with a lot of those p

Re: [Pulp-dev] Pagination in Pulp

Until Pulp actually goes GA I don't think we need to be concerned too strongly about semantic versioning. I agree that we should avoid painful changes unless they're truly necessary, though. On Tue, Jun 26, 2018 at 10:34 AM, Dana Walker wrote: > Thanks, Jeremy, for pointing that out! > > Those

Re: [Pulp-dev] Github keywords

Even if we don't change this, It's something we should keep in mind since our PR #s are currently in a spot where they may frequently overlap with issue #s. At some point they'll diverge again and it won't be so much of an issue, but currently it is. I don't know precisely how the redmine

Re: [Pulp-dev] pulp 3 distributor use cases

+1 rename On Fri, Feb 2, 2018 at 10:51 AM, Austin Macdonald wrote: > +1 rename to Exporter. > > On Fri, Feb 2, 2018 at 10:13 AM, Brian Bouterse > wrote: > >> +1 to renaming a Pulp3 'Distributor' to be 'Exporter'. The name of a >> 'Distribution' (when

Re: [Pulp-dev] Github Required Checks

I don't think we should make it a hard *physical* block on PR merging. Setting aside the occasional infrastructure issues, we also have some unit tests (in pulp core, at least) that rely on e.g. non-expired certificates, and fixing those once they break would require circumventing the process or

Re: [Pulp-dev] Github Required Checks

Jeremy, I don't think David was continuing our line of discussion on policy, but rather rebutting the original idea that Github's "required checks" be enforced for all plugins. That goes back to the whole difference between having a policy that requires green tests and making it physically

Re: [Pulp-dev] pulp 3 PR testing with pulp-smash

Would it be possible to have the required tests be Pulp core only, but to have an expanded set of non-mandatory smash tests which includes pulp_file? Which would mean, the pulp_file smash test results would be there as a visual indicator, but wouldn't cause problems over the next few months

Re: [Pulp-dev] Github Required Checks

update causing a legitimate failure because >>> of e.g backwards incompatibility). >>> When it comes to plugin independence, we could state that only plugins >>> conforming with these (core) PR criteria can be "adopted" and tagged as >>> Pulp-approved

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

Another way of thinking of it would be: "don't store store this unless you absolutely know that the base of the URL will never, ever change". Storing IDs is fine, storing hrefs may potentially not be, because it can change out from underneath you. I think it's actually a similar concept. On

Re: [Pulp-dev] Proposal to change default logging to console in Pulp 3

> > Not to say syslog is dead, it's especially useful for clustered installs > which need fancier logging like centralization or off-site replication, etc. And a lot of people who do use syslog are just telling journald to forward logs there, in which case, console logging is still a good

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

ngo will generate foreign key fields with double > understores. Eg: content__id > > I'm still -1 for using a *pulp_* prefix. > > Thoughts? > > > On 06/18/2018 01:15 PM, Daniel Alley wrote: > > I'm -1 on going the underscore idea, partly because of the aforem

Re: [Pulp-dev] 2.17.0 Dev Freeze - Tuesday, August 7 at 16:00 UTC

I think it's because the problem only ever existed on master and never made it into to a release. On Tue, Aug 7, 2018 at 12:55 PM, Jeremy Audet wrote: > https://pulp.plan.io/issues/3875 is a regression and does not appear to > be included in the list of fixed bugs, above. > >

Re: [Pulp-dev] Installing RQ

Yup. (pulp) [vagrant@pulp3 pulp_python]$ which rq > ~/.virtualenvs/pulp/bin/rq > Inside a virtualenv everything is kind of weird, for example "pip" and "python" both map to the python 3 variants instead of the python 2 variants, which you would typically expect those names to map to. On Tue,

Re: [Pulp-dev] Plan to handle ids and hrefs

As per the other discussion thread, I assume the names will actually be _id, _type, _href? Errata have both "id" and "type" fields, so if we're going to attempt to keep the Pulp metadata field names out of the way of Content field names, we need to do it for all of them. On Wed, Aug 8, 2018 at

Re: [Pulp-dev] PUP-1 template missing field

+1 On Mon, Aug 13, 2018 at 3:35 PM, David Davis wrote: > I am making a small tweak to PUP-1 to include version in the template. I > forgot to do so when I added the revision process to PUP-1. > > https://github.com/pulp/pups/pull/13 > > Please vote by August 25, 2018. Again the options are: > >

Re: [Pulp-dev] Pulp Code Owners

+1. My understanding is that this will not directly limit who can review or merge code, but should streamline the review process by notifying relevant parties? On Mon, Aug 13, 2018 at 5:29 PM, David Davis wrote: > We have come up with initial proposal of how to use code owners feature in >

Re: [Pulp-dev] Revisit: sync modes

> > It's possible we could want additional sync_modes in the future. To me, > sync mode deals with the contents of the repo during the sync. There are > other ways you would want to have a sync associate content with a > repository. Consider a retention behavior that retains 5 versions of each >

Re: [Pulp-dev] Pulp Code Owners

; +0 who's the relevant party if not the commit bit owner? >> +1 for commit bit owners receiving automatic notification to review >> >> -- >> milan >> >> On Tue, Aug 14, 2018 at 12:56 AM, Daniel Alley wrote: >> >>> +1. My understanding is that t

Re: [Pulp-dev] Pulp smash test docs and issues

> > I think this is fine where it is. pulp2 is going into maintenance mode at > some point here soon. That makes sense for the Pulp 2 smash test docs, but it's still a problem if we want to have smash test docs for Pulp 3 (which, we do) On Thu, Aug 9, 2018 at 5:12 PM, Brian Bouterse wrote: >

Re: [Pulp-dev] Switching Pulp3 settings.yaml to settings.py file

So, right now, our settings actually *are* in settings.py. When settings.py gets evaluated it looks up settings.yaml, parses it into a dictionary, and then uses that dictionary to modify it's own attributes.

Re: [Pulp-dev] proposed changes to Pulp 3 auto generated docs

Keep in mind that as of yesterday, unless we revert the change, we are using Integers IDs instead of UUIDs https://github.com/pulp/pulp/pull/3549 On Wed, Jul 18, 2018 at 9:57 PM, Bihan Zhang wrote: > > > On Wed, Jul 18, 2018 at 1:05 PM, Dennis Kliban wrote: > >> I was asked on IRC to state

Re: [Pulp-dev] Proposal to drop support of Python 3.5 for Pulp 3

Personally, +1. I ran into this issue myself and it was infuriating to deal with. dict objects preserve insertion-order (officially declared part of > the language with Python 3.7). Eliminates a source of subtle > "works on 3.6, sometimes works on 3.5" bugs. > Just to expand on this though:

Re: [Pulp-dev] Branch protection

+1 On Tue, Jul 10, 2018 at 3:30 PM, David Davis wrote: > We noticed in Pulp that the 2-master branch has branch protection but only > to prevent force pushes and deletion. I was wondering if we should also add > these checks: > > - Require an approving review > - Require status checks (e.g.

Re: [Pulp-dev] Integer IDs in Pulp 3

So, since I've already been working on some Pulp 3 benchmarking I decided to go ahead and benchmark this to get some actual data. Disclaimer: The following data is using bulk_create() with a modified, flat, non-inheriting content model, not the current multi-table inherited content model we're

Re: [Pulp-dev] Integer IDs in Pulp 3

the fields) takes about 0.44 seconds if the model has a UUID pk and about 0.33 seconds if the model has a default Django auto-incrementing PK. On Wed, Jul 11, 2018 at 11:03 AM, Daniel Alley wrote: > So, since I've already been working on some Pulp 3 benchmarking I decided > to go

Re: [Pulp-dev] Revising PUPs

+1 On Mon, Jul 9, 2018 at 9:02 AM, Milan Kovacik wrote: > Hey David, > > thanks, +1 > > -- > milan > > On Mon, Jul 9, 2018 at 1:49 PM, David Davis wrote: > >> I’ve opened a PR with the process on how to revise a PUP. >> Reviews/feedback are welcome: >> >> https://github.com/pulp/pups/pull/11

Re: [Pulp-dev] Github Required Checks

orarily disable them. I wrote up this issue here >>>>> to >>>>> do that: https://pulp.plan.io/issues/3379 >>>>> >>>>> I think we should enable these because we have a human-enforced policy >>>>> that expects fail

Re: [Pulp-dev] Importer Name

+1 +1 On Fri, Mar 9, 2018 at 3:28 PM, Brian Bouterse wrote: > I left some responses inline. > > On Thu, Mar 8, 2018 at 11:13 AM, Austin Macdonald > wrote: > >> Motivation: >> The name "importer" carries some inaccurate implications. >> 1) Importers

Re: [Pulp-dev] Improving technical decision making

> > > My opinion is that we have stalled and punted several very important > issues when lazy consensus was too lazy. This has slowed our progress > enough that I am interested in fleshing out alternatives. > +1 On Wed, Apr 4, 2018 at 11:14 AM, Austin Macdonald wrote: > > >

Re: [Pulp-dev] Tracking GA issues

+1 On Wed, Apr 18, 2018 at 12:11 PM, Dana Walker wrote: > +1 > > I like this idea for tracking purposes so that things do not fall by the > wayside and for organization of future aims. > > --Dana > > Dana Walker > > Associate Software Engineer > > Red Hat > >

Re: [Pulp-dev] Pulp 3 Release Process Questions

> > Are those Travis jobs testing combinations of web servers, AMQP brokers, > databases, etc? If not, is testing across those combinations a goal? The travis jobs currently text a matrix of Django version (2.0 and 1.1 LTS), database (sqlite and postgresql), and python version (3.5 and 3.6).

Re: [Pulp-dev] let's rename RepositoryVersion to Snapshot

large. However, I >> > agree with @dalley though about snapshot not fitting my mental model >> > of how I view snapshots so any work seems like a loss to me. >> > >> > I’m at -1 but am happy to talk more about it. >> > >> > >> > David &

Re: [Pulp-dev] Pulp 3 Unit Test Plan Proposal

We would still block on failing tests, yes. I'm also -1 blocking on coverage, and -1 against attempting 100%. I'm also generally -1 against trying to pick a number (100%, 80%, 60%) up-front. We should unit test what makes sense to unit test, push that number as high as reasonable, and otherwise

Re: [Pulp-dev] Plugin relationship to tasks

Nice choice of music :) On Mon, Mar 26, 2018 at 4:14 PM, Milan Kovacik wrote: > On Mon, Mar 26, 2018 at 9:38 PM, Austin Macdonald > wrote: > > > > > > On Mon, Mar 26, 2018 at 2:30 PM, Dennis Kliban > wrote: > >> > >> This proposal

Re: [Pulp-dev] Plugin triage

t;> Robin >> >> On Tue, Mar 6, 2018 at 12:30 PM, Ina Panova <ipan...@redhat.com> wrote: >> >>> It makes sense to let to mini-teams to triage the issues, but the >>> decision whether to put or not on the sprint still should be addressed by >>> whole team, or at least ac

Re: [Pulp-dev] let's rename RepositoryVersion to Snapshot

I think of a "snapshot" like a VM snapshot or a Windows restore point - an archival copy of a very fluid and non-discrete system at one point in time. By that understanding, the term RepositoryVersion probably fits better. I acknowledge the other benefits though. -/+0? On Tue, Mar 20, 2018 at

Re: [Pulp-dev] Port Pulp3 to use RQ

As Brian said, Celery has a lot of limitations and drawbacks, a lot of code complexity, and an upstream that is not terribly responsive. I, too, would love to see us move away from Celery at some point. But having done a little bit of research over the last few hours since it was mentioned, I

Re: [Pulp-dev] Port Pulp3 to use RQ

of whether that amount of change would be acceptable in the interim period between betas. On Tue, Mar 20, 2018 at 4:39 PM, Daniel Alley <dal...@redhat.com> wrote: > As Brian said, Celery has a lot of limitations and drawbacks, a lot of > code complexity, and an upstream that is

Re: [Pulp-dev] Port Pulp3 to use RQ

; I am +1 to get rid of celery, but with something that would not have >> other limitations which would bring just different kind of pain. [0] >> Let's keep searching and evaluating alternatives. >> >> [0] https://www.youtube.com/watch?v=Qmhc7tZ6ElQ >> >> >

Re: [Pulp-dev] Port Pulp3 to use RQ

I meant in the sense that, what is the aftermath when it comes back online, and is it screwed up in ways that cause side effects. On Wed, Mar 21, 2018 at 5:02 PM, Jeremy Audet wrote: > > RQ does not support revoking tasks. If you send the worker a SIGINT, it > will finish

Re: [Pulp-dev] Migrating Sprint to Custom Field

+1 On Mon, Mar 5, 2018 at 11:51 AM, David Davis wrote: > +1 > > > David > > On Mon, Mar 5, 2018 at 11:44 AM, Dennis Kliban wrote: > >> +1 to this plan >> >> On Mon, Mar 5, 2018 at 11:28 AM, Bihan Zhang wrote: >> >>> +1 I'm a fan

Re: [Pulp-dev] 'id' versus 'pulp_id' on Content

> > Base URLs should never change. That's an expectation that all web > application clients everywhere should be able to rely on. Isn't changing the hostname something that downstream explicitly supports? (I could be wrong here, I'm only recollecting random chats from months ago). On Thu, Jun

Re: [Pulp-dev] Replace pulp_template repo with cookiecutter template

Cookiecutter looks really nice and I'm not opposed to switching, but I don't expect we would save much maintenance work in doing so. We aren't doing / haven't needed to do too much maintenance on boostrap.py that I'm aware of, it seems like it's relatively complete and tested. Most of the

Re: [Pulp-dev] Spam on plan.io

Maybe the first comment / issue posted by an account would need to be approved, but once approved they could post subsequent comments / issues without delay? On Wed, Oct 31, 2018 at 1:28 PM, Brian Bouterse wrote: > Below is what plan.io got back to me with. I list some options below that. > >

Re: [Pulp-dev] Dev freeze

+1 On Mon, Nov 5, 2018 at 3:48 PM, Dana Walker wrote: > That sounds good to me, and consistent with the wikipedia definition of a > feature freeze. [0] > > > [0] https://en.wikipedia.org/wiki/Freeze_(software_engineering) > > > --Dana > > Dana Walker > > Associate Software Engineer > > Red Hat

Re: [Pulp-dev] Concerns about bulk_create and PostgreSQL

Brian, that's an excellent writup, thanks! >From what I can tell, it looks very very unlikely that MySQL will add the "returning" syntax. MariaDB however has supported "returning" for DELETE operations *only* for about 5 years, and has a 2 year old issue to add it for "INSERT"

Re: [Pulp-dev] Single-Table Content API Changes, Performance Discussion

> > Just thought of something. The URLs for specific content types are at > the discretion of the plugin writer so now I'm not convinced the user > has a way to reliably construct the URLs themselves. Yup, this is my view. The counterargument Dennis has been making is that the user could

Re: [Pulp-dev] [pulp-internal] Farewell party

Milan, thank you for working with us, I have really appreciated the experience! Good luck :) On Fri, Dec 21, 2018 at 7:33 AM Milan Kovacik wrote: > Hey guys, > > I'm just about to leave but I'd really like to thank You all for having me > --- I had a great time! > I'm staying in Brno --- let

Re: [Pulp-dev] Proposal to remove 'notes' fields from the Pulp 3 RC

7:14 AM David Davis > >>> Big +1. This seems like something we could add later on at any time when >>> we need it. Hopefully we can get Katello and our users involved in sussing >>> out the requirements for how this field should work too. >>> >>> David >

[Pulp-dev] Proposal to remove 'notes' fields from the Pulp 3 RC

*Background:* "Notes" are a generic key value store where data can be attached to repositories and content and publications and so forth. The eventual plan is to use this to enable adding tags to those sorts of objects, which is important for Katello. Most of the code for this is located in

Re: [Pulp-dev] Distributing Pulp3 Plans

No objection On Mon, Dec 3, 2018 at 11:52 AM Jeff Ortel wrote: > +1 > > On 12/1/18 6:01 AM, David Davis wrote: > > +1 from me. > > David > > > On Fri, Nov 30, 2018 at 10:26 AM Dennis Kliban wrote: > >> No objections from me. >> >> On Thu, Nov 29, 2018 at 7:50 AM Brian Bouterse >> wrote: >>

Re: [Pulp-dev] Single-Table Content API Changes, Performance Discussion

think that's possible, then I'm open to it. On Thu, Dec 6, 2018 at 4:53 PM Dennis Kliban wrote: > On Tue, Nov 20, 2018 at 12:31 PM Dennis Kliban wrote: > >> On Mon, Nov 19, 2018 at 6:20 PM Daniel Alley wrote: >> >>> Some of the API changes that are required by

Re: [Pulp-dev] Pulp 3 RC Blocker tag

upcoming Pulp RC? One > solution would be to have plugins use milestones and reserve the Pulp 3 RC > Blocker tag for the upcoming Pulp 3 RC. > > David > > > On Thu, Nov 29, 2018 at 7:36 AM Brian Bouterse > wrote: > >> >> >> On Wed, Nov 28, 2018

Re: [Pulp-dev] Concerns about bulk_create and PostgreSQL

To rephrase the problem a little bit: We need to bulk_create() a bunch of objects, and then after we do that we want to immediately be able to relate them with other objects, which means we need their PKs of the objects that were just created. In the case of auto-increment integer PKs, we can't

Re: [Pulp-dev] Pulp 3 RC Blocker tag

I am assuming that this can be used on a per-plugin basis, e.g. that applying this tag to an RPM plugin will be assumed to mean the RPM plugin RC as opposed to core? On Wed, Nov 28, 2018 at 9:45 AM David Davis wrote: > Just wanted to make a quick announcement that there’s a new RC Blocker tag >

Re: [Pulp-dev] Namespacing plugins, looking for feedback

I'm not opposed to this plan, I just want to point out that it would make the status API make slightly less sense. The names in the list of installed plugins would then not be the same as the packages themselves. It's probably close enough as to not be a problem though. On Tue, Jan 8, 2019 at

Re: [Pulp-dev] Renaming Content 'artifact' to '_artifact'

> > Given that single-artifact Content is likely to be a very common pattern > among plugins, maybe it would be best to add this as a mixin for pulpcore. > If that's the future of this field, we should definitely make it _artifact. +1 to this, I don't much like having to redefine this in every

Re: [Pulp-dev] Renaming Content 'artifact' to '_artifact'

_docker/pull/291/ > > It might be worth making a serializer mixin also? (I can almost hear > jortel cringing about all these mixins) > > On Mon, Jan 7, 2019 at 10:32 AM Daniel Alley wrote: > >> Given that single-artifact Content is likely to be a very common pattern >>&g

Re: [Pulp-dev] commit-bit nomination

ol beyond the basic level to mitigate risks. >>>>> >>>>> >>>>> >>>>> >>>>> Either way, this type of conversation is probably best suited for >>>>>> discussion amongst each plugin group as they determi

Re: [Pulp-dev] Namespacing plugins, looking for feedback

David, was that a vote to make it explicit? I would regard this as fairly intuitive as far as "magic-ness" goes, acceptable from the user POV in my opinion. And if Django is explicitly trying to support this functionality and relies on it working properly, and has a unittest for it going

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] 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] Performance testing results, autoincrement ID vs UUID primary keys

es to sync or if that's just > part of the sync. I think it's the former which I do find a bit troubling. > That said, I think I agree with your conclusion that we should probably > switch to UUIDs anyway. Perhaps we can find other ways to speed up sync > times. > > David > > > O

Re: [Pulp-dev] Performance testing results, autoincrement ID vs UUID primary keys

e: >> >>> I just want to bump this thread. If we hope to make the Pulp 3 RC date, >>> we need feedback today. >>> >>> David >>> >>> >>> On Wed, Feb 27, 2019 at 5:09 PM Matt Pusateri >>> wrote: >>> >>>> N

Re: [Pulp-dev] Changes in the Pulp 3 Upload story

separate artifact creation and content creation routes? >>> >>> David >>> >>> >>> On Tue, Feb 19, 2019 at 11:40 AM Austin Macdonald >>> wrote: >>> >>>> I think the key question to ask is: >>>> What circumstances

Re: [Pulp-dev] Changes in the Pulp 3 Upload story

hat circumstances would require the creation of Content that would not be > met by a one-shot upload? > > On Tue, Feb 19, 2019 at 11:34 AM Daniel Alley wrote: > >> @Matthias why would you prefer to keep the normal create? As you >> mention, the "orphan cleanup" issu

Re: [Pulp-dev] Changes in the Pulp 3 Upload story

know, the orphaning problem is really only circumvented by an atomic > one shot into the repo version endpoint. But i thought the problem is > related to this story. > > On Tue, 19 Feb 2019 11:33:18 -0500 > Daniel Alley wrote: > > > @Matthias why would you prefer to keep

[Pulp-dev] Performance testing results, autoincrement ID vs UUID primary keys

Hello all, We've had an ongoing discussion about whether Pulp would be able to perform acceptably if we switched back to UUID primary keys. I've finished doing the performance testing and I *think* the answer is yes. Although to be honest, I'm not sure that I understand why, in the case of

Re: [Pulp-dev] Missing plugin on https://pulpproject.org/pulp-3-plugins/

Hi Pat, Thanks for your interest in the Pulp project! In this case, the lack of mention is warranted. Even though the README describes it as the Puppet plugin for Pulp 3.0, it is actually just the boilerplate code for such a plugin, and it's 9 months out of date as we have been more focused on

[Pulp-dev] Changing behavior of the pclean alias

I created a new PR here [0] which changes the behavior of the pclean alias so that it also wipes out /var/lib/pulp/ in addition to dropping and recreating the database. Unless anyone objects, I plan to merge it tomorrow afternoon (Wednesday the 20th) [0]

Re: [Pulp-dev] pulp_file ownership

+1 On Wed, Mar 20, 2019 at 7:16 AM Brian Bouterse wrote: > +1 to moving pulp_file to the core team > > We should also remove the 'File' team on github with this change, since it > won't be a thing anymore. For those with Pulp org permissions that is > here:

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

+1 On Wed, Mar 20, 2019 at 1:11 PM Tatiana Tereshchenko wrote: > Hi everyone, > > We are approaching RC for pulpcore and we need to decide before that on > the naming of the services. > > To summarize the thread, our options: > >- Option #1: Include Pulp version in Pulp 3 services > -

  1   2   3   >