Pulp 3 Minimum Viable Product » History » Revision 35
Revision 34 (jortel@redhat.com, 05/09/2017 12:16 AM) → Revision 35/167 (bmbouter, 05/09/2017 09:15 PM)
# 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 - <span style="color:red;">Filtering support</span> As an authenticated user, I can CRUD a repository - Create a repo - Read a repo - Update all mutable repo fields - Delete a repo (asynchronous) As an authenticated user, I can list a repository's associated importers and publishers - All fields are included - Pagination is supported - <span style="color:red;">Filtering support</span> As an authenticated user, I can list content in a repository - All fields are included - Pagination is supported - <span style="color:red;">Filtering support</span> <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 (asynchronous) As an authenticated user, I can CRUD a publisher - Create a publisher - Read a publisher - Update all mutable publisher fields - Delete a publisher (asynchronous) ## 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. ## Upload & Copy #### Getting bits from the client to Pulp As <span style="color:red;">As an authenticated user, I can request upload a file ID from the server to upload and track it with a file with UUID I provide.</span> As <span style="color:red;">As an authenticated user, I can upload a file with in parallel by providing the server provided file ID, an optional UUID, a chunk size, and an optional offset. offset.</span> As <span style="color:red;">During our meeting, we talked about deduplication. We don't have time to discuss this, but I want to point out that modern filesystems like BTRFS and ZFS can perform deduplication for you. -Jeremy</span> <span style="color:red;">As an authenticated user, I can rely on Pulp to auto-delete uploaded files after a configurable time. (Eg: 6 hours). hours.</span> As <span style="color:red;">As a user, I can delete an uploaded file by file ID UUID</span> #### Creating Artifacts and Content Units As a user, I can reference a file ID at Artifact creation time. As <span style="color:red;">As an authenticated user, I can create a content unit and its Artifacts to be used when creating artifacts using uploading files. An uploaded file upload IDs UUID may be used for the content unit metadata. Or, the metadata and file ID for each Artifact. The content unit metadata can also be supplied in the POST body. body.</span> As <span style="color:red;">As an authenticated user, I can reuse create an artifact referencing an uploaded file UUID.</span> <span style="color:red;">As an authenticated user, I can associate a content unit created using uploaded files (artifacts) with a repository.</span> <span style="color:red;">As an authenticated user, I can create two artifacts from a single file ID to create multiple Artifacts UUID without uploading the file twice. twice.</span> #### Associating content units with repositories <span style="color:red;">As an authenticated user, I can associate a unit with a repo.</span> <span style="color:red;">As an authenticated user, I can copy a unit(s) from one repo to another</span> <span style="color:red;">\* Filtering support for specifying the unit(s)</span> <span style="color:red;">\* I can follow the progress of all copies. (Copies are asynchronous.)</span> ## Orphans <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 As an authenticated user, I can list all tasks - Filtering support on \['state', 'id', 'group'\] - This does not include associated progress reports As an authenticated user, I can see a detail view for a specific task - all attributes of a task - all associated progress reports As an authenticated user, I can cancel a task - don't dare to use the DELETE verb! ## 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 As a plugin writer, I have a plugin API that is semantically versioned at 0.x separate from the REST API As a plugin writer, I can report progress with a message and state As a plugin writer, I can report progress with an optional suffix As a plugin writer, I can report progress with a total count of things to do an the current count of things done As a plugin writer, non-fatal exceptions a on the Task and are included in the Task detail. non_fatal exceptions do not cause the Task to be marked as failed, but may be interpreted by the user as not fully successful. As a plugin writer, the working directory is set before Task work is done and cleaned up afterwards. I should not need to interact with the file system outside of the working dir. As a plugin writer, I can provide a subclassed Importer. The importer's responsibility is to synchronize the content of a Pulp repository with the content of a remote repository. As a plugin writer, I can provide a subclassed Publisher. The publisher's responsibility is to publish content. As a plugin writer, I can define unit types by subclassing Content models to provide concrete content unit types to be manged by the platform. As a plugin writer, I can interact with and create Artifacts As a plugin writer, my app will be discovered by Pulp's app via an entry point provided by the plugin writer As a plugin writer, I can use the plugin API to query content units/artifacts associated with a repository. As a plugin writer, I can assocate/disassociate content units with a repository. ## 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."?)* ## Download API As a plugin writer, I can download files via - http:// - https:// - file:// As a plugin writer, I can configure a downloader with: - Basic Auth - SSL Cert Client Auth - Custom CAs will be configured via a "trust store" either on the system or similar. Pulp will not do anything to read/load/manage CAs directly. As a plugin writer, I can provide arbitrary behaviors for customized downloaders - For example token authentication in the docker plugin As a plugin writer, I can have connection pooling/reuse As a plugin writer, I have proxy settings - proxy url (containing basic auth info) As a plugin writer, I can have great logs As a user, I have documentation about how to use something for bandwidth limiting As a plugin writer, I can configure the validation mechanisms used at download time - checksum validation - minimum (md5, sha1, sha256, sha512) - size validation <span style="color:red;">As a plugin writer, I expect units that are missing from the remote repository to not be created in Pulp when using the immediate download policy.</span> <span style="color:red;">As a plugin writer, I expect units that are missing from the remote repository to be created in Pulp when using background or on_demand download policies.</span> As a plugin writer I can configure mirror lists and rotate between the mirrors - round robin - nearest mirror support As a plugin writer, the plugin API provides tooling whereby I can provide the content to be added and removed from the repository. This tooling supports both immediate and deferred downloading. As a plugin writer I can manage the catalog by using ChangeSets As a plugin writer, the plugin can participate in adding content for cases where the decision to add additional content is based content that has been downloaded. As a plugin writer, I can fetch content myself (but I am not encouraged to do so) with code I write As a plugin writer, I can CRUD content units ## Alternate Content Source Support <span class="Etc? Python? RPM? this? support will importers of types which things, importer-related an is this Assuming else? Something locations? of list prioritized a from content download to attempt may importer single a that mean it Does file://? and HTTPS HTTP, than other protocol a via downloaded be can content that mean this Does means. this what clarify Please" style="color:red;"></span> - 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?)* ## 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>
.