Re: [Pulp-dev] Merging forward commits

Thinking out loud, it would be nice if github would support a "cherry pick" PR that would be integrated with redmine. I'm imagining the process would be to do the normal PR process against master. Then, open a 2nd PR against the release branch to back-port. The PR could automate the cherry

Re: [Pulp-dev] 2.12.0 blocked(ish)

+1 option #2. On 01/31/2017 04:57 PM, Sean Myers wrote: > 2.12.0 has generally passed upgrade testing, but this guy over in pulp_python > land got kicked back to us: > > https://pulp.plan.io/issues/140 > > That's one of the new pulp_python 2.0 features. We have a few options for > how to

Re: [Pulp-dev] Importer and Distributor Modeling

Good questions. Here was my thinking when modeling them. In pulp2, we associate a distributor with either a repository or a repository group. Because of this, modeling as: Distributor | ---

Re: [Pulp-dev] Importer and Distributor Modeling

+1 to the proposal pending: 1. a more solid plan to provide for what the pulp2 group distributor is doing wrt group publishing with a single configuration. 2. let's keep the importer FK to repository required for now. That way we don't create the possibility of orphaned importers until we

Re: [Pulp-dev] Django app naming discussion summary

Great recap. All sounds good. Thanks, Sean. On 09/01/2016 03:55 PM, Sean Myers wrote: > This morning we had an ad hoc discussion regarding the naming/namespacing > of our django apps in the Pulp platform and its plugins in Pulp 3. While > we were there we also talked a little bit about the pulp

Re: [Pulp-dev] More Story cleanup (Building and testing)

Nope. On 09/13/2016 12:58 PM, Austin Macdonald wrote: > Anyone see any value in keeping these? > > https://pulp.plan.io/issues/72 > https://pulp.plan.io/issues/75 > https://pulp.plan.io/issues/76 > https://pulp.plan.io/issues/79 > > ___ > Pulp-dev

[Pulp-dev] groom #2677

All, Please review the proposed solution on #2677 in preparation for sprint planning. Thanks, Jeff https://pulp.plan.io/issues/2677 signature.asc Description: OpenPGP digital signature ___ Pulp-dev mailing list Pulp-dev@redhat.com

Re: [Pulp-dev] PyPI names for Pulp3

I'm very opposed to having any form of the word "project" as part of the name. It's like having Firefox be named "firefoxproj". Just as the Mozilla project and the Firefox application are completely different things, so are the Pulp project and the Pulp application. -1 for pulpproj -1 for

[Pulp-dev] MVP Today - Importer support in plugin API

In preparation of the MVP meeting today, this is the background for the work that I have done so far in the area of Importer support for pulp3. Problem Statement -- To provide tooling in the Plugin API to support repository synchronization. During a sync, and importer will

Re: [Pulp-dev] 3.0 Validation update

gt; probably be a descendent of PulpException since it's a predictable/common > error > ``` +1 > > [0]: > https://github.com/pulp/pulp/pull/2991/files#diff-b9ddc3416cf3909687419960d59316bbR30 > > -Brian > > > > On Wed, Apr 12, 2017 at 10:11 AM, Jeff Ortel

Re: [Pulp-dev] 3.0 Validation update

obably be a descendent of PulpException since it's a > predictable/common error > ``` > > [0]: > https://github.com/pulp/pulp/pull/2991/files#diff-b9ddc3416cf3909687419960d59316bbR30 > > <https://github.com/pulp/pulp/pull/2991/files#diff-b9ddc3416cf3909687419960d59316bbR30>

Re: [Pulp-dev] Publish API for Plugin Writers (Pulp3)

I like this Brian and want to take it one step further. I think there is value in abstracting how a publication is composed. Files like metadata need to be composed by the publisher (as needed) in the working_dir then "added" to the publication. Artifacts could be "associated" to the

Re: [Pulp-dev] Proposal to use google style docstrings (PUP-2)

+1 accept. On 04/12/2017 01:31 PM, Austin Macdonald wrote: > Thanks to everyone for thoughtful comments and suggestions. Since the > comments and changes are still rolling > in, we are going to extend the vote. > > Voting will take place April 17 at 9pm UTC [0]. > > [0]: http://bit.ly/2ophhod

Re: [Pulp-dev] migration tool for Pulp 3

On 04/18/2017 03:16 PM, David Davis wrote: > Comments inline. > > David > > On Tue, Apr 18, 2017 at 2:42 PM, Dennis Kliban > wrote: > > Do we want to provide a tool for migrating from Pulp 2 to 3? If yes, then > ... > > Would the

Re: [Pulp-dev] Redundancy in docstrings and serializer help_text

I'm not convinced, this is a good idea. The docstrings on the models document the data model. The docstrings in the serializers document the REST resource model. They are two different things. Although in the pulp case, there isn't much difference (maybe none), it still seems wrong to

Re: [Pulp-dev] [pulp 3] mutable Artifacts are too complicated

On 07/20/2017 09:48 AM, Dennis Kliban wrote: > > Neither of these scenarios is appealing to me. The REST API would be > simplified if we made Artifacts > immutable. Either a plugin creates an Artifact once or an Artifact is created > using the REST API. After that > it can only be retrieved

[Pulp-dev] pulp3: Publishing Proposal

I have been doing some thinking about pulp3 publishing with the following goals in mind: - Eliminate symlinks. - Eliminate need for each plugin to have its own Apache conf. - Prevent orphaned content that is still published from being deleted. The main concept is to store the relationship

Re: [Pulp-dev] pulp3: Publishing Proposal

On 06/28/2017 10:37 PM, Michael Hrivnak wrote: > > On Wed, Jun 28, 2017 at 4:52 PM, Jeff Ortel <jor...@redhat.com > <mailto:jor...@redhat.com>> wrote: > > > I considered storing the base path in the Publication. But I don't see > how the query using the

[Pulp-dev] sync abbreviations

For the most part, I have mixed feelings about abbreviated words in code. On one hand I value being concise but also value clarity. With this in mind, I propose we stop abbreviating `synchronize` in code and documentation. It seems unnecessary. Example: Importer.sync() -to-

Re: [Pulp-dev] 3.0 Validation update

On 04/25/2017 02:47 PM, Brian Bouterse wrote: > There are a few use cases and behaviors that I think only an asynchronous > update/delete for importers, > publishers, and repositories will satisfy. Thanks to @asmacdo for covering > some of these also. > > * As a plugin writer, I am in control

Re: [Pulp-dev] Publish API for Plugin Writers (Pulp3)

does the atomic > publish), but I think that's not > pretty. See above ^^. > > > On Fri, Apr 21, 2017 at 5:09 PM, Jeff Ortel <jor...@redhat.com > <mailto:jor...@redhat.com>> wrote: > > I like this Brian and want to take it one step further. I think there is &

Re: [Pulp-dev] proposing changes to pulp 3 upload API

On 06/27/2017 08:36 AM, Brian Bouterse wrote: > I thought that we pulled out the chunking uploads from the MVP. IIRC, @jortel > and I thought since that use > case was for high performing (parallel) uploads and it should be on the 3.1+ > page. > > +1 to just sending data without having a file

[Pulp-dev] Terms: unassociate vs. disassociate

During the last pulp3 MVP review, a terminology question was raised regarding "associating" content with a repository. And more specifically "unassociating" vs "disassociate" content. I took an action item to define those terms in the Glossary section of the MVP wiki[1] which I did. I added

Re: [Pulp-dev] natural key fields (task #3025)

+1 On 09/26/2017 06:54 AM, Dennis Kliban wrote: > The Content model in pulpcore defines a 'natural_key_fields' tuple that > models inheriting from it need to > populate with field names that make that content type unique. At the same > time each model defines database > uniqueness constraints

[Pulp-dev] Recommend #2950 be re-prioritized.

Team, I am fine with revisiting storage as some point but disagree that #2950 should be *high* priority (higher than most other tasks) and should not aligned with sprint 26. As noted in redmine, Our FileStorage implementation conforms to the django storage interface, is simple and tested. The

Re: [Pulp-dev] [pulp-internal] Recommend #2950 be re-prioritized.

On 09/28/2017 08:56 AM, Dennis Kliban wrote: > On Tue, Sep 26, 2017 at 11:14 AM, Jeff Ortel <jor...@redhat.com > <mailto:jor...@redhat.com>> wrote: > > Team, > > I am fine with revisiting storage as some point but disagree that #2950 > shoul

Re: [Pulp-dev] [pulp-internal] Recommend #2950 be re-prioritized.

u, Sep 28, 2017 at 11:06 AM, Jeff Ortel <jor...@redhat.com > <mailto:jor...@redhat.com>> wrote: > > > > On 09/28/2017 08:56 AM, Dennis Kliban wrote: > > On Tue, Sep 26, 2017 at 11:14 AM, Jeff Ortel <jor...@redhat.com > <mailto:jor...@redhat

Re: [Pulp-dev] Asyncio I/O Downloaders

On 08/24/2017 09:51 AM, Brian Bouterse wrote: > The next step in considering the asyncio downloaders is done and ready to be > looked at. The PR made [0] > replaces the existing downloaders and is "merge-ready". The best way to read > about them is through their docs > [1]. Here are some of

Re: [Pulp-dev] Many-to-many joins in the API

On 10/18/2017 11:45 AM, David Davis wrote: > Working on issue #3073 [1], there was a discussion that came up about how to > best handle updating many-to-many > joins in the API. We currently have a many-to-many relationship between > repositories and contents which is > handled by a

Re: [Pulp-dev] Task tagging in Pulp 3

On 11/14/2017 01:24 PM, Brian Bouterse wrote: > Thanks for all the discussion! I agree there are improvements to be made here. > > I don't think either of these proposals solve all the problems without > creating a few new ones. Rather than > saying +1 to either, I want to talk about the goals

Re: [Pulp-dev] Proposal and feedback request: un-nest urls

On 11/17/2017 08:55 AM, Patrick Creech wrote: > One of the things I like to think about in these types of situations is, > "what is good rest api > design". Nesting resources under other resources is a necessary part of good > api design, and has > its place. To borrow some terms from domain

Re: [Pulp-dev] repository versions update

On 11/29/2017 07:22 AM, David Davis wrote: > I think we could design an API in 3.0 that would support versioned repos in > 3.1+. However, our current API > does not. For example, the /repositorycontents/ endpoint doesn't make sense > with versioned repos as no one > would want to add/remove

Re: [Pulp-dev] Pulp 3: using JWT to request a JWT

+1 On 11/28/2017 04:34 PM, Dennis Kliban wrote: > Our MVP doc currently states "As an API user, I can authenticate any API call > (except to request a JWT) with a > JWT. (not certain if this should be the behavior) [in progress]" > > The uncertainty was due to the "except to request a JWT"

Re: [Pulp-dev] Proposal and feedback request: un-nest urls

orth the implied relationship in non-human-friendly urls? As > someone who has spent a lot of time > on this code, I don't think so. > > > > On Nov 28, 2017 06:12, "Patrick Creech" <pcre...@redhat.com > <mailto:pcre...@redhat.com>> wrote: > >

Re: [Pulp-dev] Proposal and feedback request: un-nest urls

> The complexity seems inherrent, so I doubt we will be able to > simplify this much. So, is all this > code and > > complexity worth the implied relationship in non-human-friendly > urls? As someone who has spent a lot > of time > > on this code

Re: [Pulp-dev] Partially constructed data in the DB

mainly that we don't want to leak them indefinitely. Any ideas? What are thoughts on these approaches, behaviors, and the attribute name? Should this be moved into Redmine? On Thu, Dec 14, 2017 at 11:14 AM, Jeff Ortel <jor...@redhat.com <mailto:jor...@redhat.com>> wrote:

Re: [Pulp-dev] Partially constructed data in the DB

our suggestion of “valid” sounds fine. Maybe some other options: finished, complete[d], ready. David On Wed, Dec 13, 2017 at 2:15 PM, Jeff Ortel <jor...@redhat.com <mailto:jor...@redhat.com>> wrote: On 12/13/2017 12:46 PM, David Davis wrote: A few q

[Pulp-dev] Partially constructed data in the DB

There has been discussion on IRC about a matter related to versioned repositories that needs to be broadened.  It dealt with situations whereby a new repository version exists in the DB in an incomplete state.  The incomplete state exists because conceptually a repository version includes both

Re: [Pulp-dev] Partially constructed data in the DB

, 2017 at 12:16 PM, Jeff Ortel <jor...@redhat.com <mailto:jor...@redhat.com>> wrote: There has been discussion on IRC about a matter related to versioned repositories that needs to be broadened. It dealt with situations whereby a new repository version exists in the DB in an

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

+1 On 12/12/2017 10:47 AM, Brian Bouterse wrote: As we get to the end of the MVP planning for Pulp3, I want to check-in about deferring 3 areas of Pulp functionality to the 3.1+ page [0]. I'm looking for feedback, especially -1s, about deferring the following 3 things from the Pulp 3.0

Re: [Pulp-dev] [pulp 3] proposed change to publishing REST api

gt; [0] http://jsonapi.org/format/#crud-creating-responses-202 > <http://jsonapi.org/format/#crud-creating-responses-202> > > > David > > On Wed, Nov 1, 2017 at 10:58 AM, Jeff Ortel <jor...@redhat.com > <mailto:jor...@redhat.com>> wrote: > > >

Re: [Pulp-dev] Consider moving distribution to top level resource.

I have updated #3102 with my understanding of the consensus reached on this thread. Please review and continue any outstanding discussion by posting comments. https://pulp.plan.io/issues/3102 signature.asc Description: OpenPGP digital signature

Re: [Pulp-dev] [pulp 3] proposed change to publishing REST api

I have updated #3033 with my understanding of the consensus reached on this thread. Please review and continue any outstanding discussion by posting comments. https://pulp.plan.io/issues/3033 signature.asc Description: OpenPGP digital signature

Re: [Pulp-dev] proposal: global importer settings

On 11/02/2017 10:25 AM, Michael Hrivnak wrote: > I've been working on a planning task for how Pulp 3 will handle global > importer settings. As part of that, > I've collected feedback from a number of stakeholders. You can view the > planning task here: > > https://pulp.plan.io/issues/2373 >

Re: [Pulp-dev] Webserver owning the entire url namespace?

Wont this mean users cannot run pulp as part of a stack .. like in Satellite? What about the Katello API? On 11/02/2017 04:19 PM, Brian Bouterse wrote: > We're looking at developing apache/nginx scripts, and I was thinking about > documenting the webserver > requirements. I think Pulp probably

Re: [Pulp-dev] [pulp 3] proposed change to publishing REST api

ait until 3.1 but we needed to ensure that the design did not "box us in". I'm +0 for the URL proposal which I believe results in consensus. Any disagreement? > > > On Wed, Nov 1, 2017 at 3:21 PM, Jeff Ortel <jor...@redhat.com > <mailto:jor...@redhat.com>> wrote

Re: [Pulp-dev] [pulp 3] proposed change to publishing REST api

I'm not yet convinced about the proposed URL change for publishing. Can you help me understand why a POST to the publications collection is more appropriate than the a POST to a publisher? A POST to the publications/ collection means the POST body should define the publication to be created.

Re: [Pulp-dev] Consider moving distribution to top level resource.

with this same > feature. So I'm +0 an MVP that can auto-update N Distributions after publish > but -1 on having the MVP perform > exactly 1 Distribution update for the semver concerns above ^. > > What do others think about ^? > > -Brian > > > On Fr

Re: [Pulp-dev] [pulp 3] proposed change to publishing REST api

On 11/01/2017 09:16 AM, Brian Bouterse wrote: > Thanks for the response. Let's not move forward until we have more agreement > in this area. I've written some > responses inline. > > On Wed, Nov 1, 2017 at 9:05 AM, Jeff Ortel <jor...@redhat.com > <mailto:j

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

+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 clients to have references to > resources that no longer exist. > All resources in Pulp

Re: [Pulp-dev] Task tagging in Pulp 3

On 11/07/2017 03:09 PM, Michael Hrivnak wrote: > > > Proposal 2 > --- > > We could keep the TaskTag relationship (perhaps even rename it to > TaskResource) and we could add a field > to indicate the nature of the relationship between task and resource > (e.g. created,

Re: [Pulp-dev] Move to pulpcore

+1 On 11/08/2017 07:57 AM, David Davis wrote: > I am working on issue #3089 [0] to rename the ‘platform' directory to > ‘pulpcore'. I should hopefully have some > PRs open today but I’d like to go ahead and set a date for making this change > as it has the potential to mess > up pulp PRs. It

Re: [Pulp-dev] Consider moving distribution to top level resource.

e > it. After the dust settles, they can go back to the normal repository and its > flow of changing content sets. > > What other factors can you folks think of? > > > On Tue, Oct 24, 2017 at 4:24 PM, Jeff Ortel <jor...@redhat.com > <mailto:jor...@redhat.com>> wrote

Re: [Pulp-dev] [pulp 3] proposed change to publishing REST api

On 10/25/2017 10:24 AM, David Davis wrote: > I don’t know that the ambiguity around whether a task has a publication or > not is a big deal. If I call the > publication endpoint, I’d expect a publication task which either has 1 > publication or 0 (if the publication > failed) attached to it. >

[Pulp-dev] Consider moving distribution to top level resource.

During a discussion with Austin to resolve a problem implementing #3033, an interested question was raised - "Why do Distributions needs to be owned by Publishers?" This question came up when considering a solution to a DRF difficulty related to both Publications and Distributions being nested

Re: [Pulp-dev] rethinking workers vs queues

+1 This approach makes sense to me. On 10/30/2017 05:26 PM, Michael Hrivnak wrote: > While it's on my mind, I just want to get this idea out to others for future > consideration. I do not think we > should necessarily make any changes to Pulp 3.0 based on this. > > Setup > --- > > What is

[Pulp-dev] Composed Repositories

Let's brainstorm on something. Pulp needs to deal with remote repositories that are composed of multiple content types which may span the domain of a single plugin.  Here are a few examples.  Some Red Hat RPM repositories are composed of: RPMs, DRPMs, , ISOs and Kickstart Trees.  Some OSTree

Re: [Pulp-dev] Pulp3 "auto-distribute" Feature?

On 05/07/2018 10:19 AM, Kersom Moura Oliveira wrote: Is there a specific user case that requires that a publisher and a publication to be part of a distribution? Just the publisher & publication, No. The Distribution.publication links a publication to the Distribution and is completely

Re: [Pulp-dev] Composed Repositories

n, May 14, 2018 at 9:44 PM, Jeff Ortel <jor...@redhat.com <mailto:jor...@redhat.com>> wrote: Let's brainstorm on something. Pulp needs to deal with remote repositories that are composed of multiple content types which may span the domain of a single plugin.  Here are

Re: [Pulp-dev] Composed Repositories

#2 speaks to me more for now. 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 Mon, May 14, 2018 at 9:44 PM, Jeff Ortel <jor...@redhat.com

Re: [Pulp-dev] Composed Repositories

On 05/15/2018 09:29 AM, Milan Kovacik wrote: Hi, On Tue, May 15, 2018 at 3:22 PM, Dennis Kliban <dkli...@redhat.com> wrote: On Mon, May 14, 2018 at 3:44 PM, Jeff Ortel <jor...@redhat.com> wrote: Let's brainstorm on something. Pulp needs to deal with remote repositories that

Re: [Pulp-dev] Composed Repositories

advocating for us to think about the problem as a specific plugin problem (step 1) and then after that is done, to look at generalizing it (step 2). On Tue, May 15, 2018 at 11:27 AM, Bryan Kearney <bkear...@redhat.com <mailto:bkear...@redhat.com>> wrote: On 05/14/2018 03:44 PM

Re: [Pulp-dev] Composed Repositories

On 05/15/2018 10:41 AM, Jeff Ortel wrote: On 05/15/2018 10:27 AM, Bryan Kearney wrote: On 05/14/2018 03:44 PM, Jeff Ortel wrote: Let's brainstorm on something. Pulp needs to deal with remote repositories that are composed of multiple content types which may span the domain of a single

Re: [Pulp-dev] Core Commit Bit Process

Thanks for the proposal, Brian.  Looks fine to me. On 05/21/2018 04:48 PM, Brian Bouterse wrote: For core and it's related tools, we don't have a written process to describe giving the commit bit to a contributor. We've been wanting to agree on and document that process for a while, so I'm

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

In classic relational modeling, using ID as the primary key is common practice.  Especially when ORMs are involved.  The "id" added by plugin writers is a natural key so naming it ID goes against convention.  Every field in base models used by plugins has potential for name collisions.  Where

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

On 05/17/2018 07:46 AM, Daniel Alley wrote: 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

Re: [Pulp-dev] Pulp CLI MVP User Stories

The main goal of the CLI is to make it easier (than using the REST API and http) for admins to perform routine tasks.  It seems likely that A CLI /could/ provide an improvement by reducing the REST syntax complexity without combining the steps to complete a task.  Also, I think we should

Re: [Pulp-dev] is 3.0-dev branch ready to become master?

On 05/23/2018 06:20 AM, Brian Bouterse wrote: It sounds like there isn't much blocking this, but does that mean the devs should go ahead with planning and making the branching changes? Also I want to confirm: is the scope of this planned change only for pulp/pulp and pulp/devel repos for

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

ecommending we rename the id field to pk in the database? I’m not sure if that would work. I'm wondering if its possible yes. #django says it is but they've been wrong before. I haven't had a chance to test it. On Tue, Jun 12, 2018 at 3:44 PM, Jeff Ortel mai

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

On 06/14/2018 08:08 AM, Brian Bouterse wrote: Jeff, can you elaborate more on your -1. I want to understand it. I'm struggling to appreciate an "it's a convention" argument without sources like an RFC or similar. I don't believe internet articles are credible sources because any viewpoint can

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

Thanks for your comment, Simon. This introduces a perspective that is helpful to the discussion.  Filtering on an 'ID' natural key field (such as errata_ID) in a way that is intuitive to the user is a significant use case. On 06/14/2018 12:32 PM, Simon Baatz wrote: My 2 cents (in my role as

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

On 06/14/2018 12:19 PM, Jeff Ortel wrote: On 06/14/2018 10:37 AM, Daniel Alley wrote: I will make one more suggestion.  What about naming "id" -> "uuid"?  This carries the clear connotation that it is a unique identifier so it is less likely to be confusing a la &qu

Re: [Pulp-dev] Lazy for Pulp3

Looks good. Made a few minor edits. On 05/25/2018 02:11 PM, Brian Bouterse wrote: A mini-team of core devs** met to talk through lazy use cases for Pulp3. It's effectively the same lazy from Pulp2 except: * it's now built into core (not just RPM) * It disincludes repo protection use cases

Re: [Pulp-dev] Lazy for Pulp3

On 05/31/2018 04:39 PM, Brian Bouterse wrote: I updated the epic (https://pulp.plan.io/issues/3693) to use this new language. policy=immediate  -> downloads now while the task runs (no lazy). Also the default if unspecified. policy=cache-and-save   -> All the steps in the diagram. Content

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

On 05/29/2018 08:24 AM, Brian Bouterse wrote: On Fri, May 25, 2018 at 7:39 PM, Dana Walker > wrote: I'm basically -1 for the reasons Jeff enumerated but if he is ok with this, I'm happy to go ahead with it. [Jeff]: In classic relational

Re: [Pulp-dev] Pagination in Pulp

On 06/26/2018 08:48 AM, Dennis Kliban wrote: The user should be able to specify a page size at request time. The user should also be able to specify which page they are requesting. + 1 On Tue, Jun 26, 2018 at 9:31 AM, David Davis > wrote: I was looking

Re: [Pulp-dev] Branching Pulp 2 for plugins

pulp-ostree has been updated. - 2-master created from master - master reset to 3.0-dev - 3.0-dev deleted On 07/02/2018 09:47 AM, David Davis wrote: In order to conform to the pulp/pulp repository, I propose we update our branches for our plugins. This would include: 1. Moving master to

Re: [Pulp-dev] Pulp CLI MVP User Stories

Thanks for putting this together.  Seems like the devil will be in the details pending REST API decisions. On 05/02/2018 01:09 PM, David Davis wrote: The CLI team has identified a set of user stories that we think we should try to accomplish for the MVP. These would be the minimum set of

Re: [Pulp-dev] Pulp api seemingly incompatible with generated bindings

On 04/30/2018 09:05 AM, David Davis wrote: So what I’d probably propose is exposing the UUIDs in the response and then extending HyperlinkedRelatedFields to accept UUID or href. Then third parties like Katello could store and just use UUIDs (and not worry about hrefs). +1 to

Re: [Pulp-dev] [pulp 3] proposed change to publishing REST api

On 10/23/2017 09:55 AM, Michael Hrivnak wrote: > > A task status should not include an exhaustive list of every resource > created. For example, a publish task > should not include a reference to every metadata artifact it made. It would > be sufficient to include a > reference to the

Re: [Pulp-dev] [pulp 3] proposed change to publishing REST api

On 10/19/2017 02:27 PM, Dennis Kliban wrote: > > This work would probably be done by whoever picks up issue 3033[1]. If adopted, I think this should be a separate story. > > [0] https://pulp.plan.io/issues/3035 > [1] https://pulp.plan.io/issues/3033 signature.asc Description: OpenPGP

Re: [Pulp-dev] [pulp 3] proposed change to publishing REST api

This is interesting. Some thoughts: If adopted, I propose the publication task create the publication and pass to the publisher which would require a change in the plugin API - Publisher.publish(publication). If the publisher fails, I think the publication should be deleted. On 10/19/2017

Re: [Pulp-dev] Consider moving distribution to top level resource.

would be good to write up into Redmine and share a link to it. https://pulp.plan.io/issues/3102 > > On Wed, Oct 25, 2017 at 9:15 AM, Jeff Ortel <jor...@redhat.com > <mailto:jor...@redhat.com>> wrote: > > > > On 10/24/2017 09:29 PM, Michael Hrivnak wro

Re: [Pulp-dev] repository version stories

Looking at 3209, I don't see the actual design documented. On 01/03/2018 04:58 PM, Dennis Kliban wrote: @bmbouter, @daviddavis, and I have put together a plan for implementing repository version use cases. The overall design is captured in issue 3209[0]. The individual use cases are captured

[Pulp-dev] Downloading Decision

The pulp 3 alpha included two solutions for providing downloading support in the plugin API.  Each solution was based on different concurrency technologies, protocol support libs and abstractions.  The goal was to test drive each, get community feedback and make a second pass at documenting

[Pulp-dev] Stop distributing gofer

The gofer package is distributed in Fedora and Copr[1] for EL6 & EL7.  Gofer is an external (to the project) dependency much like Celery.  I propose we stop distributing gofer and update our documentation to refer users to the existing sources. Thoughts? [1]

[Pulp-dev] Adding Model.created.

A few of our models have a field: created = models.DateTimeField(auto_now_add=True) To support ordering needed by a FilePlugin use case, I'm planning to add Content.created as it seems generally useful and I believe will be needed by most plugins. This raises a more general question: should

Re: [Pulp-dev] Adding Model.created.

last_updated field as well. David On Mon, Feb 12, 2018 at 12:22 PM, Jeff Ortel <jor...@redhat.com <mailto:jor...@redhat.com>> wrote: A few of our models have a field: created = models.DateTimeField(auto_now_add=True) To support ordering ne

Re: [Pulp-dev] Plugin Writer's Coding Workshop Feedback

Thanks for providing this feedback, Brian.!  Good stuff. On 02/12/2018 03:57 PM, Brian Bouterse wrote: At the Foreman Construction day [0] last Wednesday, we had our first code focused plugin writer's workshop. About 6 people were actively engaged as we talked through the plugin API, example

[Pulp-dev] Installing RQ

It has been my experience that /usr/bin/rq is only installed by 'pip install rq' and it's not installed by 'pip3 install rq'. The only work around I have found is to: 1. pip install rq 2. pip3 install rq 3. edit /usr/bin/rq to use python3. How is this handled in the vagrant environment?  It's

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

After long consideration, I have had a change of heart about this. I think.  In short, Pulp's data model has unique requirements that make it acceptable to deviate from common convention regarding ID as the PK.  Mainly that the schema is extensible by plugin writers. Given the plugin

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

On 08/07/2018 11:47 AM, Jeff Ortel wrote: After long consideration, I have had a change of heart about this.  I think.  In short, Pulp's data model has unique requirements that make it acceptable to deviate from common convention regarding ID as the PK.  Mainly that the schema is extensible

[Pulp-dev] Revisit: sync modes

I'm not convinced that /named/ sync mode is a good approach. I doubt it will ever be anything besides (additive|mirror) which really boils down to mirror (or not).  Perhaps the reasoning behind a /named/ mode is that it is potentially more extensible in that the API won't be impacted when a

Re: [Pulp-dev] Revisit: sync modes

mkova...@redhat.com>> wrote: On Wed, Aug 8, 2018 at 7:54 PM, Jeff Ortel mailto:jor...@redhat.com>> wrote: I'm not convinced that /named/ sync mode is a good approach.  I doubt it will ever be anything besides (additive|mirror) which really b

[Pulp-dev] Settings merge proposal.

This issue[1] highlighted a shortcoming in how server.yaml is applied to the settings.py.  Mainly that the marge algorithm does not support removing unwanted properties such as the logging handlers.  The change proposed on #3879 is to replace entire top-level properties (trees) instead of the

Re: [Pulp-dev] Requiring 2FA in Github

+1 On 08/15/2018 01:10 PM, David Davis wrote: Thanks everyone for the feedback. I have opened a PR for PUP-7 which (if approved) will require 2FA for the Pulp organization in Github: https://github.com/pulp/pups/pull/14 Feedback welcome. Also, I'd like to call for a vote by August 27, 2018.

Re: [Pulp-dev] Branch protection

+1 On 07/10/2018 02: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. unit tests, docs

Re: [Pulp-dev] Task groups in the Pulp 3 MVP

+1 On 03/08/2018 05:07 PM, Dennis Kliban wrote: +1 but we should also remove this[0] from the code. [0] https://github.com/pulp/pulp/blob/3.0-dev/pulpcore/pulpcore/app/models/task.py#L215 On Thu, Mar 8, 2018 at 5:45 PM, Brian Bouterse > wrote: +1 to

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

+1 On 09/07/2018 01:09 AM, Simon Baatz wrote: I had a discussion on IRC with Brian yesterday which led to the question whether we can drop support for Python 3.5. I think there are good reasons for this, see the rationale below. Brian proposed to initiate a vote on this topic (and find out

[Pulp-dev] Triage of #3915

Issue 3915 has been skipped several times during triage with a request for discussion on the issue.  I feel this issue identifies a serious concern.  Investigating has also raised questions about our approach to supporting bulk_create() of Artifact. Please review and comment before the next

  1   2   >