Pulp

# Pulp 3.0.0 Minimum Viable Product (MVP)

<span style="color:red;">Lines highlighted in Red need more attention.</span>

## Authentication

As an authenticated user I can manage user(s).

  - Add a user

  - View user(s)

  - Update any user detail

  - Delete a user

As an API user, I can have documentation to generate a JSON Web Token (JWT) without the server being online.

A user authenticated with HTTP/HTTPS "Basic" auth can acquire a non-expiring JWT to access the API.

  - The JWT shall have a created timestamp which can be used to invalidate

  - The JWT shall have a user identifier (its primary key)

I can authenticate to any API call using HTTP/HTTPS "Basic" auth with a username and password that Pulp stores.

  - The password is stored as a hash (for security).

As an API user, I can authenticate any API call with a JWT.

As an API user, I can invalidate all JWT tokens for a given user issued earlier than now.

As an authenticated user, when deleting a user 'foo', all of user 'foo's JWTs are invalidated.

## Repositories

As an authenticated user, I can list all repos.

  - All fields are included

  - Pagination is supported

  - Filtering support

As an authenticated user, I can CRUD a repository

  - Create a repo

  - Read a repo

  - Update all mutable repo fields

  - Delete a repo

As an authenticated user, I can list a repository's associated importers and publishers

  - All fields are included

  - Pagination is supported

  - Filtering support

As an authenticated user, I can list content in a repository

  - All fields are included

  - Pagination is supported

  - Filtering support

<span style="color:red;">As an authenticated user, I can summarize content in a repo (including counts)</span>

As an authenticated user, I can CRUD an importer

  - Create an importer

  - Read an importer

  - Update all mutable importer fields

  - Delete an importer

As an authenticated user, I can CRUD a publisher

  - Create a publisher

  - Read a publisher

  - Update all mutable publisher fields

  - Delete a publisher

## Content Manipulation

As an authenticated user, I can trigger an importer to sync.

  - I can follow the progress of all syncs. (Syncs are asynchronous.)

  - I cannot pass "sync" options.

  - Auto-publish is not included as an importer property.

As an authenticated user, I can trigger a publisher to publish.

  - I can follow the progress of all publishes. (Publishes are asynchronous.)

  - I cannot pass "publish" options.

As an authenticated user, I can upload files that will become part of a unit

As an authenticated user, I can create a unit based on uploaded files

As an authenticated user, I can associate a unit with a repo.

As an authenticated user, I can copy a unit(s) from one repo to another

  - Filtering support for specifying the unit(s)

  - I can follow the progress of all copies. (Copies are asynchronous.)

<span style="color:red;">As an authenticated user, I can clean up orphans</span>  

<span style="color:red;">\* I can follow the progress of all cleanups. (Cleanups are asynchronous.)</span>

## Filter

I can filter all nouns *(What is the meaning of "filter?" What is a noun?)*

## Task Management

I can list all tasks and filter them *(Does this listing include only tasks that have not finished? If so, is there a way to list finished tasks?)*  

I can see a detail view for a specific task including its progress and results  

I can cancel tasks

## Task Group

I can view a summary of the status of all tasks in a group

## Event Listener Notifier

I can receive serialized task info via AMQP on each task save

*Can this be restated in more pedantic terms? Does this mean that an arbitrary host can attach itself to Pulp's AMQP message bus and get updates on the progress of tasks?*

## Status

I can view the status of all pulp components  

I can view an overall health attribute  

I can view information about unapplied migrations

## Plugin API

We will have one  

We will use one  

It will be semantically versioned at 0.x separate from the REST API

*Will this API be a Python code interface, a networked HTTP interface, or something else? In other words, for Pulp to use a plugin, will Pulp look for Python code, will it make HTTP calls to some networked resource, or something else?*

*What are three examples of plugins that will be written? (One goal is "we will use one," so presumably some specific plug-ins are already in mind.)*

## CLI

We will port what is there with as little effort as possible *(Does this mean that porting will be easy for developers, or that switching from the Pulp 2-3 CLI will be easy for users? If the former, isn't this an implementation detail that doesn't belong in an MVP document? If the latter, does this mean that we're going to carry forward the issues with pulp-admin, like a lack of status codes?)*

repo CRUD  

CRUD for importers  

CRUD for publishers  

trigger syncs  

trigger publish  

list content in a repo  

upload  

server status  

list and cancel tasks  

authn via basic auth  

*(Should the supported set of operations be stated in terms of "The capabilities listed in the 'Authenctication,' 'Repositories,' and 'Filter' sections will be supported by the CLI."?)*

## Nectar Plugin Download API

*(Is it correct to say that "I, the user, can download files via HTTP, HTTPS and file://," or "Nectar, the application, can download files via HTTP, HTTPS and file://?")*  

I can download files via HTTP, HTTPS  

I can download via file://  

Authentication parity with 2.y *(Again, is this an "I can do X" statement or a "Nectar can do X" statement?)*  

Recommend something for bandwidth limiting  

Verify integrity of downloaded files  

Alternate content source support *(Please clarify what this means. Does this mean that content can be downloaded via a protocol other than HTTP, HTTPS and file://? Does it mean that a single importer may attempt to download content from a prioritized list of locations? Something else? Assuming this is an importer-related things, which types of importers will support this? RPM? Python? Etc?)*  

Streamer parity with 2.y

## Consumer Applicability

Using consumer profiles and repo bindings I can compute applicability with 2.y parity  

Performance needs to be awesome

*(Is the Pulp Consumer going away in Pulp 3? If so, is this section still appropriate?)*

## ISO exports

Export a group of repos to a single iso *(What will the format be? A plain directory tree that's understandable by Pulp?)*

## Plugin compatibility

rpm will work with platform  

puppet will work with platform  

ostree will work with platform  

python will work with platform  

file_plugin will work with platform  

docker will work with platform

## Migrations

users can run an executable similar to pulp-manage-db that is not named pulp-manage-db *(Why the change in name?)*

<span style="color:red;">What about migrating fields that we don't use in 3.0 but will use in 3.1+. For example the auto-publish feature?</span>