Re: [Pulp-dev] Pulp3 Installer CI Blocked -- Need Help

In addition to your user being a member of the docker group, there is some weirdness (irritatingly hidden, even in debug mode). Molecule requires libselinux-python, which has its own issues. The easiest way to fix this is to enable system-site-packages in your venv. Bmbouter: > > 2) Getting more

Re: [Pulp-dev] Pulpcore RC5 Release Planning

There was a new feature, but it was missed because it wasn't in the release notes: https://github.com/pulp/pulpcore-plugin/pull/125 The docker plugin is already using the new filter, so a new rc would be helpful. On Tue, Sep 3, 2019 at 12:12 PM Ina Panova wrote: > Thank for clarification, then

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

On Wed, Aug 28, 2019 at 11:34 AM Tatiana Tereshchenko wrote: > Bump. > > Please provide feedback if you have any. > I'll start working on the PR to make the suggested change this week > otherwise. > > Thank you, > Tanya > > On Mon, Aug 26, 2019 at 12:46 PM Tatiana Tereshchenko > wrote: > >> In

Re: [Pulp-dev] Call for Presenters: Hiatus does not stop demos!

I suggest posting demos individually. This will be more searchable, better to link to, and easier to consume. The community update portion could also be uploaded separately. The downside of fully asynchronous demos is that we lose the Q in real time, but we haven't gotten much traction there. On

Re: [Pulp-dev] [Breaking] Stopping the installer from auto-creating migrations - Sept 3rd

This all sounds good to me. FYI, I closed https://pulp.plan.io/issues/5361 as a dupe since https://pulp.plan.io/issues/5321 has already been added to the sprint. Feel free to use 5361 and close 5321 if you prefer. On Tue, Aug 27, 2019 at 2:16 PM Brian Bouterse wrote: > tl;dr if we make this

Re: [Pulp-dev] Travis PR tests are broken (installation on ubuntu)

The CI is up and running again. (No changes made on our stuff.) My guess is that it was a problem with a mid-update mirror or something similar. On Mon, Aug 26, 2019 at 11:48 AM Austin Macdonald wrote: > I tried to replicate on an ubuntu box, but I was able to run > `sudo add-apt-repo

Re: [Pulp-dev] Travis PR tests are broken (installation on ubuntu)

t; incompatible with. > > [1]: https://travis-ci.org/pulp/pulp_ansible/builds/576843005 > [2]: https://www.traviscistatus.com/ > > > On Mon, Aug 26, 2019 at 11:03 AM Austin Macdonald > wrote: > >> On travis, the ansible installer fails on the task to add a redis >

[Pulp-dev] Travis PR tests are broken (installation on ubuntu)

On travis, the ansible installer fails on the task to add a redis repository TASK [pulp-redis : Add redis repository] *** fatal: [127.0.0.1]: FAILED! => {"changed": false, "msg": "E:Failed to fetch

Re: [Pulp-dev] Docker plugin: Creation of a new repository version for the same tag and digest

Great question. Currently, we are creating empty repository versions for no-op add/remove calls in all plugins as you demonstrated. Lets keep that same behavior for tags for now (option A). On Fri, Aug 2, 2019 at 10:08 AM Lubos Mjachky wrote: > Dear colleagues, > > currently, I am working on

Re: [Pulp-dev] [BREAKING] drf 3.10 has breaking changes

CI breakage *resolved*. https://pulp.plan.io/issues/5125 has not been fixed yet, it is blocked upstream. In the meantime we have restricted drf version to < 3.10. https://github.com/pulp/pulpcore/pull/209/ On Mon, Jul 15, 2019 at 12:59 PM Austin Macdonald wrote: > This will probably b

Re: [Pulp-dev] [BREAKING] drf 3.10 has breaking changes

This will probably be a CI blocker. (It does prevent pulplift from completing.) I've taken https://pulp.plan.io/issues/5125 as assigned. I'll update the issue as I go, and respond here when things are working again. On Mon, Jul 15, 2019 at 12:08 PM David Davis wrote: > A new version of DRF was

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

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

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

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

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

I have a design in mind for solving this problem: 1. Remove POST to RepositoryVersion (no general add/remove endpoint). 2. Add an endpoint to kick off an add/remove task, namespaced by plugin. ie `POST pulp/api/v3/docker/add-remove/` This view can be provided to all plugins by the plugin

Re: [Pulp-dev] black

+1. I like the consistency but it's easy to overwhelm new contributors with minor style comments, even if they are "standard". On Tue, Jun 18, 2019 at 5:55 PM David Davis wrote: > Agreed. You don't have to use black to autoformat your code if you don't > want to. You could run black to check

Re: [Pulp-dev] black

h, sorry I missed that. I'd like to see what it does to pulpcore before we make the final call, but unless its terrible +1 > > > On Tue, Jun 4, 2019 at 1:41 PM Austin Macdonald wrote: > >> I think there are enough big projects that use black to consider it >> ready. (PyP

Re: [Pulp-dev] black

On Tue, Jun 4, 2019 at 1:40 PM Matt Pusateri wrote: > > > > On Tue, Jun 4, 2019 at 1:15 PM Mike DePaulo wrote: > >> On Tue, Jun 4, 2019 at 12:09 PM Robin Chan wrote: >> >>> Mike, clarification question below... >>> >>> On Tue, Jun 4, 2019 at 11:45 AM Mike DePaulo >>> wrote: >>> On Tue,

Re: [Pulp-dev] black

I think there are enough big projects that use black to consider it ready. (PyPI for another example, and we also know it is being actively developed). IMO the way to make this choice is to determine whether the style it uses/enforces works well for the project. There might be legitimate reasons

Re: [Pulp-dev] Release Note Process Improvements

The proposed changes look awesome! I'm +1 for moving forward with it for pulpcore and pulpcore-plugin. If there is consensus (looks like we are close), lets go ahead. If anyone has concerns, we also have the option to implement this change for one plugin before we go all in. On Mon, May 27, 2019

Re: [Pulp-dev] Docstring linting

Something else to consider: some docstrings are rendered as user-facing documentation in the autogenerated REST docs. This means that docstring linting needs to be ignored for ViewSets. For example, I have a PR open that alters pulp_file viewset docstrings to contain html, to pass the linter, we

Re: [Pulp-dev] Ansible Galaxy Content Changes

+1 I think we are ok to remove. On Mon, Apr 15, 2019 at 1:46 PM Brian Bouterse wrote: > There are some early Ansible roles posted on the 'pulp' namespace in > Galaxy here: https://galaxy.ansible.com/pulp > > Who can modify this content? > > Can we add the role from this repo to it? >

Re: [Pulp-dev] Pulp 3 tag

Pulp2 tag sounds great to me. On Fri, Apr 12, 2019, 16:23 Brian Bouterse wrote: > +1 to making a 'Pulp 2' tag > > > On Fri, Apr 12, 2019 at 3:16 PM David Davis wrote: > >> I’ve been thinking through this and I think there are 3 steps to perform: >> >> 1. Create a Pulp 2 tag >> 2. Assign the

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

I think its possible you will have a url collision with variant 1. (We had a similar problem trying to use /v3/publications/docker/) variant 1: POST /pulp/v3/api/content/rpm/packages/copy/ content_units=[...] source="..." destination="..." [more params...] Assuming that

[Pulp-dev] State of the docs & Docs drive kickoff

The Pulp community is beginning our drive to improve the user docs for Pulp 3. Docs work is tracked with the redmine tags [Pulp 3, Documentation] and can be viewed from the query: https://pulp.plan.io/issues?query_id=128 . (Note that the query is for

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

the effort and move through it over time. On Tue, Apr 2, 2019 at 5:22 PM Austin Macdonald wrote: > I think if we close a lot of them, closed issues will be very difficult to > find with ~4500 bugs (open and closed). I've been spending some time > combing the backlog recently, and I'm compil

Re: [Pulp-dev] installer team

Oops, this is a draft for my own organization, please disregard :) On Mon, Mar 25, 2019 at 6:13 PM Austin Macdonald wrote: > - create meeting for installer team > - dev installer docs > - point to pulplift docs >- remove any instructions that should be documented

[Pulp-dev] installer team

- create meeting for installer team - dev installer docs - point to pulplift docs - remove any instructions that should be documented on pulplift - remove mention of specific repos, ( use ":get the source") - update "get the source" - ansible-pulp3 ->

[Pulp-dev] Travis CI is broken for pulpcore PRs

Today, I merged a change to ansible-pulp that broke the CI. I have an open PR to fix it, but we are running into an unrelated problem (Travis is trying to double the number of builds, and cannot ever pass.) https://github.com/pulp/pulpcore/pull/51#issuecomment-476389752 Until this PR (or its

[Pulp-dev] Please update pulplift when you merge a PR to ansible-pulp

I've been merging lots of changes to ansible-pulp and pulplift recently, and I noticed that fairly often, the pulplift update moves forward by a few unrelated commits. This makes it difficult to make a commit message that makes sense for pulplift, and can confuse pulplift users, forcing them to

Re: [Pulp-dev] Changing behavior of the pclean alias

roy db after itself. > so take only +1 and skip everything after > > On Wed, Mar 20, 2019 at 3:56 PM Austin Macdonald > wrote: > >> Pavel, can you elaborate? >> >> On Wed, Mar 20, 2019 at 9:43 AM Pavel Picka wrote: >> >>> +1 and what do you think ab

Re: [Pulp-dev] Changing behavior of the pclean alias

Pavel, can you elaborate? On Wed, Mar 20, 2019 at 9:43 AM Pavel Picka wrote: > +1 and what do you think about idea of dropping all DBs as sometimes test > let there some (it doesn't affect pulp but when clean db so clean it > whole)? > > On Wed, Mar 20, 2019 at 12:12 PM Dennis Kliban wrote: >

Re: [Pulp-dev] pulp_file ownership

+1 for the latter. Since some changes to pulpcore or pulpcore-plugin also require changes to pulp_file (anything backwards incompatible) everyone on the core team needs to be able to quickly make changes to pulp_file as well. (And vice versa.) On Tue, Mar 19, 2019 at 5:04 PM David Davis wrote:

Re: [Pulp-dev] Nomenclature Clarification

We don't have an official process, but bringing it up here is a good place to start. Depending on the changes, it would be best to update the docs: https://docs.pulpproject.org/en/3.0/nightly/concepts.html https://docs.pulpproject.org/en/3.0/nightly/glossary.html

Re: [Pulp-dev] Unified interface for plugin actions

tandable by reading the api docs, rather than scanning the >>> README's of the respective plugin and trying to work out what is >>> different. >>> >>> Justin >>> >>> On 2/28/19 1:42 PM, Austin Macdonald wrote: >>> > Now tha

[Pulp-dev] Unified interface for plugin actions

Now that we have a handful of plugins that have somewhat different workflows, surprising user-facing differences in the interface for plugin-related actions are becoming apparent. Example: Publish File: Create a publisher v3/publishers/file/1/publish/ repository=$REPO

[Pulp-dev] plugin API versioning for RC

An issue has come up for plugins when declaring their dependence on pulpcore-plugin. Background: The plugin API is semantically versioned at 0.1.0b20, which is separate from pulpcore. The plan has always been that pulpcore would GA while the plugin API is released as "0.1", indicating that even

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

like to keep the >> 'traditional' create anyway. >> The problem i see with create and one shot upload is, that another >> thing could have triggered 'delete orphans' at the wrong time, and you >> shiny new content unit disappears, before you can add it to a >> repository versio

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

Originally, our upload story was as follows: The user will upload a new file to Pulp via POST to /artifacts/ (provided by core) The user will create a new plugin specific Content via POST to /path/to/plugin/content/, referencing whatever artifacts that are contained, and whatever fields are

Re: [Pulp-dev] [Pulp-list] Pulp 3 RC info

> > > On Thu, Jan 31, 2019 at 8:45 AM Bryan Kearney wrote: > >> -- pulp-list >> >> RC for a year? That seems way long. I get the idea of semanti=c >> versioning, but is there any other path for that? >> >> We haven't really discussed this idea, so this is just me talking: Another possible path

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

nfig.label > > On Tue, Jan 8, 2019 at 8:22 PM Daniel Alley wrote: > >> 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 t

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

On Tue, Jan 8, 2019 at 12:12 PM Brian Bouterse wrote: > My understanding is that it's for both. It would be dropped from app_label > and that will automatically be used in master/detail urls. Is that what > others thought? > > This seems like the simplest approach to me. My only concern with

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

>> >>>> For consistency, i would prefer to see same format i see in >>>> `content_summary` as in content endpoints, even if it does not make sense >>>> from user's perspective, because what we now have in content_summary, i >>>> would not say that it makes

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

serializer mixin like you said). > > On Mon, Jan 7, 2019 at 10:41 AM Austin Macdonald > wrote: > >> The serializer just needs to remove the _artifacts field and add an >> _artifact field. Here's how I did it in docker, which is a total ripoff of >> the file plugin. >&g

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

definitely make it _artifact. > > > +1 to this, I don't much like having to redefine this in every plugin. > I'm curious about how to make it work with the serializers though. > > On Mon, Jan 7, 2019 at 10:13 AM Austin Macdonald > wrote: > >> We have single-artifact Content in

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

We have single-artifact Content in Docker as well. I've gone ahead and named the field _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

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

+1 automatic namespacing for master/detail. I realize the easiest way to do this would be to use the app_label, giving us: /api/v3/content/pulp_rpm/packages/ However, I feel like this url is pretty clunky. The "pulp_" is totally unnecessary, from the user's perspective. Instead, I think I'd

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

On Wed, Oct 31, 2018, 3:57 PM Austin Macdonald On Wed, Oct 31, 2018, 2:23 PM Daniel Alley >> 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? >> >> &g

Re: [Pulp-dev] Possible Pulp3 RC Blocker issues from backlog

I think. > > David > > > On Mon, Dec 3, 2018 at 2:41 PM Austin Macdonald wrote: > >> To be on the safe side, I'd like to highlight issues that *might* need to >> be RC blockers. Please reply directly onto the issue, I'll update this >> thread periodically if nec

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

+1, nice catch Daniel. On Tue, Dec 4, 2018, 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 > > > On Mon,

Re: [Pulp-dev] Auto-distribution

Yes, and AFAIK this is already complete. There are 2 fields on the Distribution that allow auto-distribution. These fields must both be set, and when they are, new publications will automatically update the distribution.

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

On Wed, Oct 31, 2018, 2:23 PM Daniel Alley 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? > > @dalley, sounds right to me. I think this could be implemented using bmbouters b)

Re: [Pulp-dev] commit-bit nomination

+1, I agree that Milan has met the criteria. I think we should go forward with giving him the bit and larger discussions about decision making can happen separately. On Mon, Sep 10, 2018 at 9:03 AM Ina Panova wrote: > Brian, > > it feels like your reply is in contradiction of what we are trying

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

Seems reasonable to me. Even without python 3.6 in the official repositories for Debian and trusty Ubuntu, it isn't very difficult to install 3.6 with tools like anaconda and pyenv. From my perspective, dropping 3.5 would introduce short term inconvenience for those systems, and simplify our long

Re: [Pulp-dev] Theme of the bachelor thesis

How about reproducibility? Bihan and I presented on this topic at scipy but there is a lot left to say/research. https://www.youtube.com/watch?v=5czGgUG0oXA In the scientific community, reproducibility is a hot topic (I bet grad schools would love this!), and the computational aspect of it has

Re: [Pulp-dev] Proposed Update to PUP-4

gt;> updated PR. >> >> --Dana >> >> Dana Walker >> >> Associate Software Engineer >> >> Red Hat >> >> <https://www.redhat.com> >> <https://red.ht/sig> >> >> On Tue, Jul 24, 2018 at 1:20 PM, Austin Macdonald

Re: [Pulp-dev] Proposed Update to PUP-4

I'm a firm +1 on this, but I do have a related thought. I think I speak for everyone, but please correct me if I'm wrong, one of our goals is to have an inclusive community that has very very simple requirements to be a part of. At the moment, I think we may have taken this as far as it can go,

Re: [Pulp-dev] Revising PUPs

+1 I suggested an addition, to increment the PUP version whenever a change is made. I considered suggesting a version scheme to indicate major and minor changes, but AFAICT there isn't a practical need beyond a simple integer. If the process is too cumbersome for typo fixing (for example), we can

Re: [Pulp-dev] bulk_create for Artifact, Content, ContentArtifact, and RemoteArtifact?

On Thu, Jun 21, 2018 at 4:19 PM, Brian Bouterse wrote: > I'm only considering these changes for the plugin writer API to help > resolve the performance issues. > Cool. +1 ___ Pulp-dev mailing list Pulp-dev@redhat.com

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

oftware 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 Thu, Jun 14, 2018 at 10:19 PM, Bihan Zhang >&

[Pulp-dev] Ideas for the plugin template

I've recently updated the plugin_template to work with the latest master (3.0). [0] The template handles almost all of the bootstrapping work necessary to write a new plugin, so it is valuable to keep it up to date. Given human nature, it's likely that the plugin_template will tend to fall behind

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

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

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

+1 On Fri, Jun 1, 2018 at 8:54 AM, Dana Walker wrote: > +1 > > Dana Walker > > Associate Software Engineer > > Red Hat > > > > > On Thu, May 31, 2018 at 4:08 PM, Daniel Alley wrote: > >> +0 >> >> On Thu, May 31, 2018 at 3:49 PM, Robin Chan wrote:

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

I have a few concerns, but they all may be addressable. 1. URLs and security. If this integer is in the url, it is easy to guess other urls. Hopefully, our security model won't depend on obscurity, so maybe this isn't much of a concern. 2. bulk_create. Apparently, bulk_creates would work, but

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

In Pulp 2, having id fields bit us really badly. The reason may have been specific to Mongoengine, but my understanding is that it is bad practice anyway. 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

Re: [Pulp-dev] Setting naming conventions

+1 to make it more consistent. -0 for option 3 since it leaves our settings inconsistent. The other options seem reasonable. On Fri, May 18, 2018 at 5:24 PM, David Davis wrote: > Background > = > > We discovered that some of our settings in server.yaml all

[Pulp-dev] Pulp/Pulp Puppet Module removed from Forge

Pulp had a puppet module on the forge: https://forge.puppet.com/pulp/pulp This module has not been kept up to date and was broken. Instead, please use: https://forge.puppet.com/katello/pulp ___ Pulp-dev mailing list Pulp-dev@redhat.com

Re: [Pulp-dev] Composed Repositories

Here's another complexity, how do 2 plugins create a single publication? We basically have the same problem of 2 parallel operations creating content from a single source. On Tue, May 15, 2018, 06:27 Ina Panova wrote: > +1 on not introducing dependencies between plugins. > >

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

On Mon, May 7, 2018 at 10:55 AM, Brian Bouterse wrote: > I'm confused about the feature claim of the auto-distribute feature for > Pulp 3.0 GA. The distribution object takes both 'repository' and > 'publisher' as options currently... > > As a user, can I create a

Re: [Pulp-dev] Tracking GA issues

+1 a little late :) For clarity I'll state how I assume this will work: - Milestone of 3.0 blocks GA release - Milestone of 3.1 blocks 3.1 - Pulp 3 Tag indicates that the issue is Pulp 3+, no blocking relationship (aka, not Pulp 2) - Pulp 3 MVP will only be used for historical

Re: [Pulp-dev] Pulp 3 REST API Challenges

> > *1. Core endpoints do not delegate/redirect to plugins.* > - POST to /RepositoryVersion/ is removed. > - POST to /Publications/ (stays gone) > - Plugins provide endpoints for sync and other to create new > repository versions. > - Plugins provide endpoints for creating

Re: [Pulp-dev] Pulp 3 REST API Challenges

> > - We don't have a convention for where plug-in-specific, custom repository version creation endpoints. - example POST@/api/v3//docker/add/ - needs to be discoverable through the schema What does discoverable via the schema ^ mean? Aren't all

[Pulp-dev] Pulp 3 MVP issue cleanup (round 2)

Note: there will be some redundancy with "Various MVP micro-discussions". That email includes all changes to the MVP document, this thread covers all changes to issues with the "Pulp 3 MVP" tag. *Needs attention (please respond on issue):* - single resource OperationPostponed

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

CLI, Ansible Installer, and the Migration >> tool as part of one version of Pulp or will these all be versioned >> separately? >> >> >> Separately. >> >> >> Meant to clarify. The CLI can be released separately but I think the >> migration t

Re: [Pulp-dev] Content paths in Pulp 3

ightly/contributing/3.0-development/rest-api.html#rest-api-guidelines On Tue, Apr 10, 2018 at 11:38 AM, Austin Macdonald <amacd...@redhat.com> wrote: > If ya'll don't mind leaving out v3/content// endpoints, then I > think we are all set. https://pulp.plan.io/issues/3472 should be ready

Re: [Pulp-dev] Content paths in Pulp 3

If ya'll don't mind leaving out v3/content// endpoints, then I think we are all set. https://pulp.plan.io/issues/3472 should be ready to be groomed. Since I updated with the suggested implementation, would one of you mind marking it groomed? On Tue, Apr 10, 2018 at 9:03 AM, Austin Macdonald

Re: [Pulp-dev] Changesets Challenges

> > > 1. There is redundant "differencing" code in all plugins. The Changeset > interface requires the plugin writer to determine what units need to be > added and those to be removed. This requires all plugin writers to write > the same non-trivial differencing code over and over. For example,

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

so I > think we should just leave this out of the MVP. > > That's fine with me. I'll update the issue. David > > On Mon, Apr 9, 2018 at 12:19 PM, Austin Macdonald <aus...@redhat.com> > wrote: > >> Here's another one that needs to be groomed and added to the &g

[Pulp-dev] Pulp 3 REST API Challenges

Folks, Austin, Dennis, and Milan have identified the following issues with current Pulp3 REST API design: - Action endpoints are problematic. - Example POST@/importers//sync/ - They are non-RESTful and would make client code tightly coupled with the server code. - These

Re: [Pulp-dev] Content paths in Pulp 3

Dennis Kliban <dkli...@redhat.com> wrote: > >> Option 1 is the most consistent. +1 to option 1 >> >> >> On Fri, Apr 6, 2018 at 10:19 AM, Austin Macdonald <amacd...@redhat.com> >> wrote: >> >>> IMO: >>> We should suggest v3/content//

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

://pulp.plan.io/issues/3298 - https://pulp.plan.io/issues/3220 - https://pulp.plan.io/issues/3081 - https://pulp.plan.io/issues/3082 - https://pulp.plan.io/issues/3546 On Thu, Apr 5, 2018 at 9:53 AM, Austin Macdonald <aus...@redhat.com> wrote: > David and I went through all the

Re: [Pulp-dev] Content paths in Pulp 3

IMO: We should suggest v3/content///. [Proposal 1] We should mention the other options with the pros, cons in the plugin writer docs. On Thu, Apr 5, 2018 at 10:54 AM, David Davis wrote: > > [0] https://pulp.plan.io/issues/3407 > The correct link is:

Re: [Pulp-dev] Pulp 3 MVP Issue Cleanup

oks will not be released. The Migration tool is tricky. A pulpcore migration tool would be one thing, but each plugin will probably need its own migration tool. So... /me shugs. > > On Wed, Apr 4, 2018 at 5:41 PM, Austin Macdonald <aus...@redhat.com> > wrote: > >> >>>>

Re: [Pulp-dev] Improving technical decision making

; The first ever technical and community leads would be elected by folks >> with the commit bit, the election would be organized by our current >> community representatives. >> >> Unless there are objections, I'd file a PUP to summarize these points. >> >> >> Chee

Re: [Pulp-dev] remove AUTHORS

One reason to keep the AUTHORS file is that it allows contributors to specify their contact info instead of just linking to their GitHub page, were they might not have an email listed. I assume this discussion is restricted to pulp/pulp. The plugins are free to handle however they prefer.

[Pulp-dev] Improving technical decision making

d use Redmine for release planning. This would be a starter idea > > towards a solution for us to modify together. > > > > > > > > On Mon, Apr 2, 2018 at 9:08 AM, Austin Macdonald <aus...@redhat.com> >

Re: [Pulp-dev] Plugin relationship to tasks

Thanks for the classifications. On Mon, Apr 2, 2018 at 2:37 PM, Dennis Kliban wrote: I think of these actions as 2 new types of resource in Pulp. Unlike > Remotes(Importers currently) and Content, these resources are singletons > that each plugin provides. Since users don't

Re: [Pulp-dev] Pulp 3.0 REST API gap analysis

On Fri, Mar 30, 2018 at 9:23 AM, David Davis wrote: > Sorry, I think the Importer and Publisher subclass user stories probably > need to be updated to more accurately reflect how plugin writers implement > syncing and publishing. > > > David > > On Fri, Mar 30, 2018 at

Re: [Pulp-dev] Plugin relationship to tasks

; >>> version by adding or removing content to the latest version." To >> facilitate >> >>> that in a generic way, we need a core endpoint to do that, i.e. >> >>> /api/v3/repositories//versions/. My concern is that removing >> it would >> &g

Re: [Pulp-dev] Roadmap Challenges

I agree with the problems that Brian listed, but I hope we can focus on the decision making process itself in addition to how those decisions are communicated. ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Plugin relationship to tasks

> > I haven't seen a counterargument to the assertion that it is **incorrect** >> to control repo membership without allowing plugin validation. >> > > We could add hooks for plugins to provide validation for each content > type. The Content model in pulpcore could define >

Re: [Pulp-dev] Plugin relationship to tasks

n be easily integrated with core. That said, I >> agree on the counterpoints raise about the new resource endpoints and >> turning much of pulp into a task running system. So I am a bit mixed on >> which approach is better. >> >> I do think that we should

Re: [Pulp-dev] Plugin relationship to tasks

> > >- /api/v3/repositories//versions/ endpoint does not perform >plugin specific validation which can lead to "broken" repository versions. >- Plugin authors don't have any convention to follow when creating >custom REST API endpoints for creating repository versions. >- As a

Re: [Pulp-dev] Plugin relationship to tasks

On Mon, Mar 26, 2018 at 4:43 PM, Dennis Kliban <dkli...@redhat.com> wrote: > On Mon, Mar 26, 2018 at 3:38 PM, Austin Macdonald <aus...@redhat.com> > wrote: > >> >> >> On Mon, Mar 26, 2018 at 2:30 PM, Dennis Kliban <dkli...@redhat.com> >> w

Re: [Pulp-dev] Plugin relationship to tasks

On Mon, Mar 26, 2018 at 2:30 PM, Dennis Kliban wrote: > This proposal does not make the plugin writer's job any easier. This > simply changes where the plugin writer is providing validation logic, in a > serializer vs. in a view. > It does make the plugin writer's job easier

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

-1 For a blocking check, -1 for attempting 100% coverage. There is a *lot* of code in Pulp 3 that simply involves inheriting from parents classes and defining attributes. If we add a ViewSet for instance, there is nothing to test other than "asserting that we did what we did". I have written lots

Re: [Pulp-dev] Plugin relationship to tasks

com> wrote: > On Fri, Mar 16, 2018 at 4:55 PM, Milan Kovacik <mkova...@redhat.com> > wrote: > > > > > > > > On Thu, Mar 15, 2018 at 9:21 PM, Austin Macdonald <aus...@redhat.com> > wrote: > >> > >> I spoke with daviddavis about this

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

Not being familiar with RQ, I have questions (but no opinion). Will we also be replacing RabbitMQ with Redis? Does anyone on the team have experience with RQ? In production? How well does RQ scale? Is RQ's use of `pickle` a problem? https://pulp.plan.io/issues/23 RQ doesn't work on Windows. Is

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

"Snapshot" is a nice way to explain what a RepositoryVersion is, especially in the context of Publications. "Publish a snapshot." I like the idea, and I informally floated it around PulpCon but decided not to propose it because: - Snapshot is a little misleading about the actual data we

Re: [Pulp-dev] Importer Name

ng because I still see >> the point that you and Justin raised about dropping the fields as an issue. >> >> >> David >> >> On Mon, Mar 12, 2018 at 12:31 PM, Jeff Ortel <jor...@redhat.com> wrote: >> >>> >>> >>> On 03/12/2018 1

Re: [Pulp-dev] Plugin relationship to tasks

I spoke with daviddavis about this and I would like to narrow the scope a bit. This discussion should be limited to endpoints that deploy tasks. The possibility for collisions that David pointed out regarding v3/content// is real, but should be discussed separately because Content objects should

  1   2   >