Re: [Pulp-dev] pulp3: Publishing Proposal

On Thu, Jun 29, 2017 at 5:17 PM, Brian Bouterse wrote: > Also what about content protection? Are we going to use redirects with > time-bombed urls? Or are we expecting the cert verification to occur twice > (once for the initial request, and again to follow the 301 redirect)? > I don't think the

Re: [Pulp-dev] pulp3: Publishing Proposal

+100 to this proposal as I understand it. Having a redirect engine to serve 100% of content that is looked up via the db is a must-have for pulp3. Besides opening up object storage use cases, solving practical file system limits with symlinks, it will allow us to reorganize content on the backend w

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

There is really one practical issue that is driving this convo (I think): Django's file upload handling wants to save a file when we receive it. We also don't want to be moving around files. Therefore we must save the file in the right place on the first save(). So given ^, the question reduces to

[Pulp-dev] pulp3: Task Resource proposal

I've been working on supporting tags in Pulp 3[0] and have gotten some feedback from various other developers. I'd like to open up the discussion though to a broader audience and see if anyone has any feedback. Background: Currently in Pulp 2, there are two types of task tags: action and resource

Re: [Pulp-dev] pulp3: Publishing Proposal

Another aspect I'm considering is pulp serving a single publication with multiple and/or limited protocols (schemes). This pertains to supporting both HTTP and HTTPS or limiting to only HTTPS. As proposed, I think we get both HTTP and HTTPS for free but don't yet have a way for the content app

Re: [Pulp-dev] pulp3: Publishing Proposal

I'm thinking we'd add functionality in the core that can export an existing publication. To disk, ISO, etc .. This maintains clean separation between composing the publication and supporting it being served by something external to pulp. On 06/28/2017 02:55 PM, Michael Hrivnak wrote: > One addi

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 > wrote: > > > I considered storing the base path in the Publication. But I don't see > how the query using the /path/ > component of the URL could be indexed if t

[Pulp-dev] linking units in pulp

In the developer guide, i have found the reference, that a given unit type can reference other units (referenced_types in 'Type Definitions' -> 'Attributes'). I also read, that in the importer you can call 'link_unit' to 'establish any relationships between units' (in 'Importers' -> 'Functionalit

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

Thanks for that explanation. That makes sense. I would describe this as saying there is a many-to-many relationship between Content and Artifact, and the ContentArtifact is the "glue" or "through" table. And again to just understand why... are we deliberately trying to prioritize a use case where

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

On Thu, Jun 29, 2017 at 7:40 AM, Michael Hrivnak wrote: > > On Thu, Jun 29, 2017 at 7:22 AM, Dennis Kliban wrote: > >> >> The many to many relationship is between Artifact and ContentArtifact. >> This allows a content unit to have multiple Artifacts associated with it. >> > > Could you elaborate

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

On Thu, Jun 29, 2017 at 7:22 AM, Dennis Kliban wrote: > > The many to many relationship is between Artifact and ContentArtifact. > This allows a content unit to have multiple Artifacts associated with it. > Could you elaborate on this? A content unit can have multiple artifacts just by artifact

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

On Wed, Jun 28, 2017 at 11:55 PM, Michael Hrivnak wrote: > For a unit like a Distribution, the relative path of the file does matter > with respect to other files associated with the same content unit and needs > to be preserved. That content type consists of a collection of arbitrary > files in