Pulp 3 Minimum Viable Product » History » Revision 7
« Previous |
Revision 7/167
(diff)
| Next »
Ichimonji10, 11/07/2016 04:50 PM
Request that a goal be clarified
Pulp 3.0.0 Minimum Viable Product (MVP)¶
Authentication¶
I can login with a username and password that Pulp stores
I can CRUD a user
I can list all users
I can change the password of a user
I can acquire a token to access the API
I can invalidate all JWT tokens for a given user
Repositories¶
I can list all repos
I can CRUD a repository
I can list associated importers and publishers
I can list content in a repository
I can summarize content in a repo (including counts)
I can CRUD an importer
I can CRUD a publisher
Content Manipulation¶
I can sync an importer
I can publish a publisher
I can upload (What to where?)
I can copy (What from where to where?)
I can clean up orphans
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
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
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
Nectar Plugin Download API¶
I can download files via HTTP, HTTPS
I can download via file://
Authentication parity with 2.y
Recommend something for bandwidth limiting
Verify integrity of downloaded files
Alternate content source support
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
ISO exports¶
Export a group of repos to a single iso
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
Updated by Ichimonji10 about 8 years ago · 7 revisions