[Pulp-dev] Pulp 3 plugin for Chef cookbooks

I created the beginnings of a Pulp 3 plugin to manage Chef cookbooks [1]. Currently, it supports to create repos, create cookbook content units, and publish repos. A published & distributed repo will offer a "universe" API endpoint for tools like Berkshelf. I did not implement sync yet. I am wa

Re: [Pulp-dev] Composed Repositories

On Tue, May 15, 2018 at 4:48 PM, Jeff Ortel wrote: > > > On 05/15/2018 09:29 AM, Milan Kovacik wrote: >> >> Hi, >> >> On Tue, May 15, 2018 at 3:22 PM, Dennis Kliban wrote: >>> >>> On Mon, May 14, 2018 at 3:44 PM, Jeff Ortel wrote: Let's brainstorm on something. Pulp needs to

Re: [Pulp-dev] Composed Repositories

I agree these are specific cases for a few content types that are used by multiple plugins. I think the most productive thing would be for us to talk in specific only about kickstart trees being shared between RPM and ostree. It would be much easier to generalize after building something specific o

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 plug

Re: [Pulp-dev] Composed Repositories

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 plugin. Here are a few examples.  Some Red Hat RP

Re: [Pulp-dev] Composed Repositories

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 plugin.  > Here are a few examples.  Some Red Hat RPM repositories are composed of: > RPMs,

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 wrote: On Mon, May 14, 2018 at 3: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 t

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

@ipanova, I think of the core team as only maintaining pulp/pulp and pulp/devel so I limit the scope of this to those repos only. I think pulp_rpm (or any plugin) could adopt the CCRC without a PUP by following the "Displaying the CRCC section

Re: [Pulp-dev] Composed Repositories

On 05/15/2018 05:58 AM, Austin Macdonald wrote: Here's another complexity, how do 2 plugins create a single publication? The plugin API could make this seamless. We basically have the same problem of 2 parallel operations creating content from a single source. I don't think so.  plugins s

Re: [Pulp-dev] Composed Repositories

On 05/15/2018 05:26 AM, Ina Panova wrote: +1 on not introducing dependencies between plugins. What will be the behavior in case there is a composed repo of rpm and ks trees but just the rpm plugin is installed? I would expect the result would be to only sync the rpm content into the pulp r

Re: [Pulp-dev] Composed Repositories

Hi, On Tue, May 15, 2018 at 3:22 PM, Dennis Kliban wrote: > On Mon, May 14, 2018 at 3: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 plugin. Here

Re: [Pulp-dev] MODIFIED redmine issues for 3.0 beta

A few use cases where it would be useful for Pulp 3 issues released in a Beta would be considered closed are: 1. Sprint content 2. Your own queries on what is Open & assigned to you. - Query can just be changed. 3. If a user is seeing an issue in Pulp 3 (or Pulp 2) - can they easily find which

Re: [Pulp-dev] MODIFIED redmine issues for 3.0 beta

On Tue, May 15, 2018 at 6:03 AM, Ina Panova wrote: > If i am not mistaken as of now the person who takes care of a release > needs to manually change the issue status. > There is a possibility to select all the issues and actually move the > status in 1 click. Do you think to automate this will p

Re: [Pulp-dev] Composed Repositories

On Mon, May 14, 2018 at 3: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 plugin. Here are a few > examples. Some Red Hat RPM repositories are composed o

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. > > What will be the beh

Re: [Pulp-dev] Composed Repositories

+1 on not introducing dependencies between plugins. What will be the behavior in case there is a composed repo of rpm and ks trees but just the rpm plugin is installed? Do we fail and say we cannot sync this repo at all or we just sync the rpm part? Depends how we plan this ^ i guess we'll decide

Re: [Pulp-dev] MODIFIED redmine issues for 3.0 beta

If i am not mistaken as of now the person who takes care of a release needs to manually change the issue status. There is a possibility to select all the issues and actually move the status in 1 click. Do you think to automate this will pay off? I am fine to close issues as current release in case