On 05/15/2018 11:59 AM, Brian Bouterse wrote:
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 easi
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
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
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
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
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,
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
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
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
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
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
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
+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
13 matches
Mail list logo
