Re: [Pulp-dev] Importer Name

> > On Mon, Mar 12, 2018 at 9:50 AM, Justin Sherrill > wrote: > >> I'm fairly apathetic to a name change. It would be annoying to us in >> katello land, but not really a huge deal either way. I don't think >> importer a bad name, as it does hold configuration around

[Pulp-dev] Plugin relationship to tasks

tldr; I am running with an idea that Milan brought up. I think this will create a simpler user experience while providing an obvious pattern to plugin writers. This pattern will offer greater plugin control and flexibility. Problem: Tasks that add/remove content to a repo (which creates

Re: [Pulp-dev] Github Required Checks

+1 pulpcore +0 pulp_file -1 Other plugins. I'm thinking about the situation where we need to fix a bug with a PR to pulpcore and to a plugin. How is the version of pulpcore determined for runnning the plugin tests? In the past, we used nightly builds, so plugins would have to wait 24 hours after

[Pulp-dev] Importer Name

Motivation: The name "importer" carries some inaccurate implications. 1) Importers should "import". Tasks like "sync" will do the actual importing. The object only holds the configuration that happens to be used by sync tasks. 2) Sync tasks on mirror mode remove content as well as add it, so

Re: [Pulp-dev] issue #3360 follow up

+1 @daviddavis, @dkliban, @jortel's plan. I've added a comment to the issue, https://pulp.plan.io/issues/3360#note-11 On Fri, Feb 23, 2018 at 2:25 PM, David Davis wrote: > After meeting with @dkliban and @jortel to discuss #3360, we came up with > an alternative proposal

Re: [Pulp-dev] pulp-gem

https://github.com/ATIX-AG/pulp_gem Nice work! On Tue, Feb 20, 2018 at 10:03 AM, Dennis Kliban wrote: > Could you share a link for the repo? > > On Tue, Feb 20, 2018 at 9:30 AM, Matthias Dellweg wrote: > >> In order to get to know the pulp3 plugin api and

Re: [Pulp-dev] Seeking Nomenclature

We also have called it "Pulp to Pulp sync" informally. On Mon, Feb 19, 2018 at 3:23 PM, David Davis wrote: > So syncing from one Pulp server to another Pulp server is usually called > 'natural syncing'. See [0][1]. > > AFAIK, there is no official concept of

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

+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 Pulp serves bits using its webserver) would stay the > same. Currently the names Distributor and

[Pulp-dev] Context Manager meeting recap

Today, some of the developers met to discuss our new context managers. These objects are the interface for creating and using RepositoryVersion and Publication objects and they are used by both core developers and plugin writers. They described in detail in https://pulp.plan.io/issues/3285 and

[Pulp-dev] RepositoryVersion high level design

The parent issue of RepositoryVersions has been updated with the high level design of its child stories/tasks. https://pulp.plan.io/issues/3209 ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Pulp 3 Proposed Plugin API changes

As part of the changes for RepositoryVersions [0], we are adding some tools to the plugin API that will allow plugins to define their own celery tasks, as well as deploy them. The changes to the plugin API are made in this PR [1] and are summarized below. Added: Allow plugin writers to create

[Pulp-dev] Repository Versions stories update

In the RepositoryVersions discussion this morning, we identified some issues that needed to be updated to the current design. The issue changes have been made and they are ready for all to review. We will discuss adding them to the sprint in another meeting tomorrow.

Re: [Pulp-dev] creating repository version resources using a single REST endpoint

I like the concept of single REST endpoint that is responsible for all the ways to create a RepositoryVersion, but I don't quite understand how this would work. Since the endpoint is purely pulpcore, how can the RepositoryVersionViewSet import the plugin defined tasks that correspond to the action

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

+1 On Wed, Dec 13, 2017 at 10:02 AM, Bihan Zhang wrote: > +1 > > On Wed, Dec 13, 2017 at 10:01 AM, Jeff Ortel wrote: > >> +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

[Pulp-dev] [Pulp 3 REST API] Breaking URL structure changes

I am merging changes [0] that will flatten our URL structure. These changes have been previously discussed in this thread [1] and this issue [2]. For example, a call to `v3/repositories//importers/file//` will now be made to `v3/importers/file//` [0]: https://github.com/pulp/pulp/pull/3237 [1]:

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

30, 2017 at 10:49 PM, Austin Macdonald <amacd...@redhat.com> wrote: > I have a first-draft of the POC https://github.com/pulp/pulp/pull/3232 > > On Thu, Nov 30, 2017 at 6:23 PM, Jeremy Audet <jau...@redhat.com> wrote: > >> For deletes, the db relationships are

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

When I look at this, the most important point is that we have a hyperlinked REST API, which means that the urls are specifically not going to be built by users. For a user to retrieve an importer, they would first GET the importers for a repository. The next call would be the exact href returned

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

On Thu, Nov 16, 2017 at 5:30 PM, Jeremy Audet wrote: ...snip > > Worse, let's say I'm a developer debugging an issue, and I want to find > every concentrated sprayflesh in the known world. Do I need to make several > thousand API calls? Both of these use cases are more

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

We recently decided to reference objects by their pks in the urls, primarily so they will be immutable. Problem: UUIDs are long, and not human friendly. Add nesting and urls get ugly. Nested PK URL for a Publication (artist's rendering):

[Pulp-dev] Pulp's Ansible Roles

At PulpCon we identified a need to get on the same page with our Ansible Roles. We have multiple use cases (dev setup, QE install, users), and some of them are sharing roles. Obviously, we want to share as much as possible, but we also need to make sure all the cases are covered. I took an action

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

+1, thanks Dennis. I see some issues on the "external" tracker, and some in the "pulp" tracker. Is the plan to move them all to the "pulp" tracker and add the installer tag? On Tue, Oct 17, 2017 at 2:53 PM, Dennis Kliban wrote: > This tag should be used when reporting issues

Re: [Pulp-dev] REST API Milestone/alpha?

> >> This etherpad deployment has been returning 503s for a few days. Any >> chance you could easily re-generate that list of endpoints with methods and >> put it somewhere else? >> >> On Thu, Oct 5, 2017 at 12:49 PM, Austin Macdonald <aus...@redhat.com> >>

[Pulp-dev] Requested Plugins Wiki page?

Unless this already exists somewhere, I think it would be nice to have a new wiki document called "Requested Plugins". For each plugin, we might include a brief description, links to related docs, and redmine issues if we have any. I think this would help us to prioritize them, and provide a good

Re: [Pulp-dev] REST API Milestone/alpha?

On Thu, Oct 5, 2017 at 2:16 PM, Jeremy Audet wrote: > I don't see any API endpoints for getting JWT tokens. How will > authorization be handled? > I made this list by looking through the schema at http://pulphost/v3/ so it only includes endpoints that already exist. JWT

Re: [Pulp-dev] REST API Milestone/alpha?

I don't think there are any actions which can schedule tasks in Pulp 3. Any requests that trigger a task will return a url for that task. On Thu, Oct 5, 2017 at 2:25 PM, Og Maciel <omac...@redhat.com> wrote: > On Thu, Oct 5, 2017 at 2:20 PM, Austin Macdonald <aus...@redhat.

Re: [Pulp-dev] REST API Milestone/alpha?

Consumers are not going to be a part of Pulp 3 (except for calculating applicability), so we don't need to worry about #3041 regarding Pulp3. On Thu, Oct 5, 2017 at 2:01 PM, Og Maciel wrote: > I'd like to recommend https://pulp.plan.io/issues/3041 for > consideration and

Re: [Pulp-dev] REST API Milestone/alpha?

:29.078859Z", "state": "completed", "tags": [], "worker": " http://pulp3.dev:8000/api/v3/workers/reserved_resource_worke...@pulp3.dev/; } On Thu, Oct 5, 2017 at 2:15 PM, Og Maciel <omac...@redha

[Pulp-dev] REST API Milestone/alpha?

I think we are ready to start considering an alpha for our REST API. (REST API and plugin API are versioned separately.) I've started a list of all our endpoints along with accepted methods and the expected responses. I hope this list will be useful for QE as well.

Re: [Pulp-dev] De-duplicating Demo Content

>>>> that be a way to solve this? We have docs here [0] about how to do that. >>>>> Feedback about this idea would be great. >>>>> >>>>> [0]: https://pulp.plan.io/projects/pulp/wiki/Sprint_Demo_Notes >>>>> >>>>> &g

Re: [Pulp-dev] Reconsidering PUP-3

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

Re: [Pulp-dev] De-duplicating Demo Content

+1 to "Release Updates" because it doesn't make an artificial distinction between work done by Red Hat employees and work done by the community. On Thu, Sep 28, 2017 at 10:38 AM, Brian Bouterse wrote: > During the sprint demos there are two sections which regularly (if not

Re: [Pulp-dev] Is it time to commit our migrations?

of core or not. The changes to allow this installation workflow have been merged. [0]: https://pulp.plan.io/issues/3012] On Fri, Sep 15, 2017 at 6:51 PM, Austin Macdonald <aus...@redhat.com> wrote: > Users who install using Ansible + pip/git cannot run the db-reset script. > (Ansible r

Re: [Pulp-dev] Is it time to commit our migrations?

e migrations is after we do a release > where we don’t support upgrades (e.g. the alpha release of Pulp 3.0). > > > David > > On Thu, Sep 14, 2017 at 2:26 PM, Austin Macdonald <aus...@redhat.com> > wrote: > >> Today I filed and fixed https://pulp.plan.io/issue

[Pulp-dev] Is it time to commit our migrations?

Today I filed and fixed https://pulp.plan.io/issues/3012, which is an issue related to creating the migrations in the right order. It is a temporary problem that we will have until we take the step of committing the migrations to version control. The reason migrations are not in git right now is

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

be any more work to write different docstrings later, but it will be more work to keep them identical for now. > > On 08/09/2017 01:48 PM, Austin Macdonald wrote: > > I propose that we remove fields from the docstrings of our models with > serializers and exclusively use the >

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

;>>>>>> buy-in" >>>>>>>>>> and "default to change." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>>

[Pulp-dev] Redundancy in docstrings and serializer help_text

I propose that we remove fields from the docstrings of our models with serializers and exclusively use the help_text of the serializers. Reasons: 1. docstrings and help_text contain identical information. 2. help_text will become documentation, so we have to use it. 3. For master/detail models

Re: [Pulp-dev] [Breaking Changes] Concurrent dev envs for Pulp 2 and Pulp 3

Correction: If you use vagrant-hostmanager (not vagrant-hostname), you will have a slight adjustment to your workflow, On Wed, Jul 5, 2017 at 7:58 AM, Austin Macdonald <aus...@redhat.com> wrote: > This work [0] will make it easier to have 2 Vagrant vms, one for Pulp 2 > and on

[Pulp-dev] [Breaking Changes] Concurrent dev envs for Pulp 2 and Pulp 3

This work [0] will make it easier to have 2 Vagrant vms, one for Pulp 2 and one for Pulp 3. It is optional and instructions on the wiki [1]. This work was done in these PRs. [2][3] Action Required: 1. Pick up the Vagrantfile.example changes 2. Delete the old libvirt machine with virt-manager 3.

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

This reminds me of the concept of a "Do-ocracy". If developers take the time to research and write up a proposal, they have "done". It seems completely reasonable to default to the opinion of the people that cared enough to do the work. If it isn't the right decision, then someone must actively

Re: [Pulp-dev] [pulp 3] cast() method for casting from a Master to Detail model instance

> > > I think there is still an improvement to be made with cast() when it fails > to cast. The cast method itself can't know if you're dealing with the > master or most detailed object, but the code author calling cast() always > knows and if they don't need it cast() they shouldn't call cast().

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

+1 add/remove It sounds like we are arriving at this language: content units are created and deleted content units can be added to and removed from repositories On Wed, May 24, 2017 at 10:06 AM, Brian Bouterse wrote: > +1 to using remove and not delete. Delete to me

Re: [Pulp-dev] 3.0 Validation update

th try/catch and raise a PulpException when the DB exception is > raised. The sync would terminate > immediately and the task would report that the importer had been deleted > which seems reasonable. > > > > > Thank you to everyone who is participating in this convo. We don't have >

Re: [Pulp-dev] PyPI names for Pulp3

My vote will be +0 for pulpproj to imitate pulpproject.org. Since the only perfect option is "pulp" I doubt that we will come up with anything that is great. That's ok though because this name shouldn't affect very much. +1 to pushing this through, thanks Ina! On Thu, May 4, 2017 at 8:25 AM, Ina

Re: [Pulp-dev] 3.0 Validation update

I think we have arrived at a consensus around these points: * Django's ModelForm validations that are used during `full_clean` is an anti-pattern in DjangoRestFramework and should not be used * Validation, by our definition, will be done by the serializers in the API layer * The Task layer should

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

With 5 +1 votes and 4 +0 votes, PUP 2 has been accepted and merged. ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev

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

gt; +1 to accepting this proposal. >> >> I left my final round of very small language nitpicks. >> >> On Wed, Apr 12, 2017 at 2:31 PM, Austin Macdonald <aus...@redhat.com> >> wrote: >> >>> Thanks to everyone for thoughtful comments and suggestions. Sinc

Re: [Pulp-dev] 3.0 Validation update

> > I think everyone seems to be leaning in the direction that update does > not [need to be a task]. I am leaning that updates and deletes should be tasks for importers and publishers in order to get the full benefit of the reserved resource system. The most important point is that related

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

d > > Thanks @asmacdo for leading this. > > -Brian > > On Mon, Apr 10, 2017 at 2:14 PM, Austin Macdonald <aus...@redhat.com> > wrote: > >> PUP 2 [0] is still getting feedback and changing, so we are extending the >> vote to April 12 at 9pm UTC [1]. Votin

Re: [Pulp-dev] 3.0 Validation update

Where should business logic live? As an example, I want to consider the sync task [0] and the need to ensure that an importer is syncable. For now, let's say that an importer is syncable if it has a feed_url. Since the call to sync an importer comes from the API, the earliest we can check that

Re: [Pulp-dev] PyPI names for Pulp3

+1 for the pcreech {datadir} plan. If we go with the pcreech plan, I am -0 on using `pulpproj` for our PyPI name. If we are not using the PyPI name at import time, then the length problem [0] no longer exists, and we are abbreviating without a good reason. I think "pulpproject" would be best,

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

PUP 2 [0] is still getting feedback and changing, so we are extending the vote to April 12 at 9pm UTC [1]. Voting procedure is described in PUP 1. [2] Comments, nitpicks, and votes are welcome from anyone who is interested! [0] - https://github.com/pulp/pups/pull/2 [1] - http://bit.ly/2oXOREo

Re: [Pulp-dev] PyPI names for Pulp3

I think that we can actually go with pulp_platform. PyPI will normalize this to pulp-platform. Basically, it boils down to this sentence from PEP 426: "All comparisons of distribution names MUST be case insensitive, and MUST consider hyphens and underscores to be equivalent." This is a

Re: [Pulp-dev] [pulp-internal] Vagrant pulp2 pulp3 switching usage question

Ambiguity! I keep my pulp code in $HOME/devel, which is the directory I copied. As opposed to the devel project that holds our vagrant and ansible stuff. (Sadly that lives in devel/devel for me.) On Thu, Apr 6, 2017 at 6:45 PM, Austin Macdonald <amacd...@redhat.com> wrote: > I recursive

Re: [Pulp-dev] [pulp-internal] Vagrant pulp2 pulp3 switching usage question

I recursively copied my entire devel directory. I have one that stays in 2 mode, and one that stays in 3 mode. They need different hostnames to run simultaneously, but I don't bother with that-- I just shut it down. On Thu, Apr 6, 2017 at 6:30 PM, Filip Dobrovolny wrote: >

[Pulp-dev] 3.0 Validation update

tldr; 1. Serializer errors won't be caught by serializer validation. 2. DRF does not use full_clean(), so if data passes serializer validation, it gets into the db. 3. We can use full_clean for process level validation. During a lengthy discussion on IRC, I incorrectly asserted that

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

Up for consideration: PUP-2 [0], which proposes using Google style docstring conventions for Pulp 3. Some relevant discussion has already happened on this task [1]. The ratification process for this PUP is defined by PUP-1 [2]. Votes will be counted on Monday April 10 at 9pm UTC. Use [3] to

Re: [Pulp-dev] RFC: Use Napoleon when Writing Docs

:15 AM, Austin Macdonald wrote: > tldr; I'm strongly in favor of switching to Napoleon. I was not > previously opinionated on the matter, but after trying it out I see a > lot of benefits. > > Reasoning: *We drown ourselves with useless information.* > > :param repo_name:

Re: [Pulp-dev] RFC: Replace LGTM with github reviews

On 10/03/2016 05:43 PM, Sean Myers wrote: > Github's new review feature is supported by another new github feature, > protected branches. If wanted to, we could combine the two ideas, and > only push to protected branches if there is at least one approved review > and no review with required

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

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 mailing list Pulp-dev@redhat.com

Re: [Pulp-dev] [pulp-internal] story backlog reduction

I have been closing more stories, and I would like some feedback for these 10. IMHO, these do not convey a clear idea, but might have more meaning to one of you and perhaps be expanded into a proper story. Please have a glance at these and let me know if there are any that should *not* be closed.

<    1   2