Project

Profile

Help

Task #2868

closed

Platform support for publishing.

Added by jortel@redhat.com almost 7 years ago. Updated over 4 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

100%

Estimated time:
(Total: 0:00 h)
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Quarter:

Description

Overview

The platform needs to support the composition and inventory of publications. Each publication is a representation of a repository's content that can be consumed by a specific technology. An example of a technology is YUM. A publication is created by a Publisher associated with the repository and is provided by a plugin. A repository may have multiple publishers. A publication is composed of two types of files. The first is a content Artifact. The second, is metadata created by the publisher when the publication is created. Once created, a publication may be distributed for consumption in many ways. The platform will support common online distributing such as HTTP and HTTPS and offline distributing such as creating an ISO.

Additional Goals

  • Clean separation between publishing and how a publication is distributed.
  • Eliminate the use of symlinks as the primary method of publishing.
  • Eliminate need for each plugin to provide an Apache .conf file for distributing via http/https.
  • Prevent orphaned content from being deleted while published.

Design

Tables

[Publisher]---*[publication]---*[distribution]

[Exporter]

The Publication table contains publications and is associated to the Publisher that created it. A Distribution defines a method for making publications available for consumption. Attributes currently modeled on Publisher pertaining to distribution such as Auth would be removed. Auth would be handled by Apache and selected by user based Distribution.base_path.

Publication

  • [pk] id - The primary key.
  • [fk] publisher_id - The publisher that created the publication. Constraint ensure it's deleted when the publication is deleted.
  • created - When the publication was created.

The PublishedArtifact table contains linkage to content Artifacts.

PublishedArtifact

  • [pk] id - The primary key.
  • [fk] publication_id - A publication. Constraint ensure it's deleted when the publication is deleted.
  • [fk] artifact_id - An associated content artifact.
  • relative_path - The relative path component within the URL that is also relative to the Publication.base_path.

The PublishedMetadata table contains linkage to generated metadata files.

PublishedMetadata

  • [pk] id - The primary key.
  • [fk] publication_id - A publication. Constraint ensure it's deleted when the publication is deleted.
  • file - An absolute path to a metadata file. Stored in: /var/lib/pulp/published/metadata/<id>/<name>
  • relative_path - The relative path component within the URL that is also relative to the Distribution.base_path.

Distribution

A Distribution maps a Publication of a distribution mechanism. It defines the URLs (paths) under which a publication is distributed, by which protocols and likely how access is authorized. Distributions also define which publications are live (visible for consumption) for a publisher (and thus repository).

Distribution

  • [pk] id - The primary key.
  • [fk] repository_id - An (optional) repository. When set, the publication is updated whenever a new publication is created by a publisher (for the specified repository).
  • [fk] publisher_id - An (optional) publisher. When set, the publication is updated whenever a new publication is created by the publisher (for the specified repository).
  • [fk] publication_id - An (optional) publication (mutable).
  • name - The distribution name (Eg: rawhide, stable).
  • base_path - The base path for the publication. This is the root of the path component of URLs.
  • http - HTTP is enabled (bool). The distribution is served by pulp using HTTP.
  • https - HTTPS is enabled (bool). The distribution is served by pulp using HTTPS.

An Exporter defines method of generating a static (external) file tree for a Distribution. An Exporter are not needed for the HTTP/HTTPS distribution mechanism provided by the pulp platform. They are only needed to generate an external representation of a Distribution. For example: rsync to static CDN or crane support. This is likely a master-detail pattern and only showing the master table here.

Exporter

  • [pk] id - The primary key.
  • name - The exporter name.
  • last_export - The timestamp of the last successful export.

Sample Data

Publisher
-------------------------------
publisher-1, ... 
Publication
-------------------------------
publication-1, publisher-1, ...
publication-2, publisher-1, ...
PublishedMetadata
-------------------------------
<id>, publication-1, /var/lib/pulp/published/../repodata/repomd.xml
<id>, publication-1, /var/lib/pulp/published/../repodata/primary.xml
PublishedArtifact
-------------------------------
<id>, publication-1, artifact-1, packages/dog.rpm
<id>, publication-1, artifact-2, packages/cat.rpm
Distribution
-------------------------------
<id>, publisher-1, publication-1, rawhide, f25/rawhide/x86_64, true
<id>, publisher-1, publication-2, stable, f25/stable/x86_64, false

General Flows

Create A Repository

1. Create a repository.
2. Create a publisher associated with the repository.
3. Create desired distributions associated with the publisher.  Each distribution will be configured with
   a base_path and http and/or https enabled as desired.

Publishing:

"The publisher will compose a publication"

1. Publisher creates a publication using the plugin API.
2. Publisher adds content artifacts to the publication.
3. Publisher generates some metadata files in the working dir.
4. Publisher adds the metadata files to the publication using the plugin API. 
5. Publisher commits (publishes) the publication.  The plugin API ensures this is atomic.
6. Distributions with auto_updated=true are updated with new publication_id.

Client makes a GET request for content (or metadata):

1. Request is routed to the content (WSGI) application (just like in pulp2 for RPM).
2. Query to get the Distribution.
3. Match the scheme against (http and https fields).  404 when scheme not enabled.
4. Query the PublishedArtifact and PublishedMetadata tables (in that order) by URL path component to get the artifact or the metadata.
5. forward the artifact storage path (or metadata path) to:
   <not stored locally>
       streamer
   <stored locally>
       x-send (or stream using django in dev environments)
6. Done.

Apache Configuration

The platform will provide an /etc/httpd/conf.d/pulp.conf that configures support for HTTP and HTTPS. Published content would be consumed using URLs with a base of:

/pulp/published/<path>

where path is the <Distribution.base_path>/(<PublishedArtifact.relative_path>|<PublishedMetadata.relative_path>)

Exporting

An exporter is executed using the plugin defined endpoint. Example: /api/exporter/<type>/export/.


Sub-issues 7 (0 open7 closed)

Task #2893: Add Publication and Distribution models.CLOSED - CURRENTRELEASEjortel@redhat.com

Actions
Task #2894: Add Exporter support.CLOSED - CURRENTRELEASEjortel@redhat.com

Actions
Task #2895: As a user, I can have content served to me by PulpCLOSED - CURRENTRELEASEjortel@redhat.com

Actions
Task #2914: Add support for Pulp to handle X-SEND and X-Accel-Redirect response headersCLOSED - CURRENTRELEASEjortel@redhat.com

Actions
Task #2916: Add Distribution serializer and viewset.CLOSED - CURRENTRELEASEamacdona@redhat.com

Actions
Task #3033: Add Publication API Endpoint.CLOSED - CURRENTRELEASEjortel@redhat.com

Actions
Task #3102: Make Distribution a top level resource in the API.CLOSED - CURRENTRELEASEjortel@redhat.com

Actions

Also available in: Atom PDF