pulp-admin man page

pulp-admin — Pulp Documentation

Contents:

Introduction

The admin client is used to remotely manage a Pulp server. This client is used to manage the operation of the server itself as well as trigger remote operations on registered consumers.

For more information on the client that runs on Pulp consumers, see the Consumer section of this guide.

The following sections describe some unique concepts that apply to the admin client.

Synchronous v. Asynchronous Commands

Commands run by the client execute in two different ways.

Many commands run synchronously. In these cases, the command is executed immediately on the server and the results are displayed before the client process exits. Examples of this behavior include logging in or displaying the list of repositories.

In certain cases, a request is sent to the server but the client does not wait for a response. There are several variations of this behavior:

·
For long running operations, the request is sent to the server and the client immediately exits. The progress of the operation can be tracked using the commands in the tasks section of the client.
·
Some operations cannot execute while a resource on the server is being used. If the resource is available, the operation will execute immediately and the result displayed in the client. If the operation is postponed because the resource is unavailable, the status of it can be tracked using the commands in the tasks section of the client.
·
In certain circumstances, an operation may be outright rejected based on the state of a resource. For example, if a repository has a delete operation queued, any subsequent operation on the repository will be rejected.

For more information on the task commands, see the tasks section of this guide.

Content Type Bundles

A portion of the admin client centers around standard Pulp functionality, such as user management or tasking related operations. However, Pulp's pluggable nature presents a challenge when it comes to type-specific operations. For example, the steps for synchronizing a repository will differ based on the type of content being synchronized.

To facilitate this, the client provides an extension mechanism. Extensions added by a content type bundle will customize the client with commands related to the types being supported. Typically, these commands will focus around managing repositories of a particular type, however there is no restriction to what commands an extension may add.

Type-specific sections will branch at the root of the client. For example, the following is a trimmed output of the client structure. Type-agnostic repository commands, such as the list of all repositories and group commands, are found under the repo section. Commands for managing RPM repositories and consumers are found under the rpm section and provided by the RPM extensions. Similarly, the commands for managing Puppet repositories are found under the puppet command:

$ pulp-admin --map
rpm: manage RPM-related content and features
  consumer: register, bind, and interact with rpm consumers
    bind:       binds a consumer to a repository
    history:    displays the history of operations on a consumer
    list:       lists summary of consumers registered to the Pulp
    ...
 repo: repository lifecycle commands
   create: creates a new repository
   delete: deletes a repository
   list:   lists repositories on the Pulp server
   ...
puppet: manage Puppet-related content and features
  repo: repository lifecycle commands
    create:  creates a new repository
    delete:  deletes a repository
    list:    lists repositories on the Pulp server
    ...
repo: list repositories and manage repo groups
  list: lists repositories on the Pulp server
  group: repository group commands
  ...

As new types are supported, additional root-level sections will be provided in their content type bundles.

Troubleshooting with verbose flag

You can run Pulp commands in verbose mode to get additional information in case of a failure. Pulp CLI provide -v and -vv options for INFO and DEBUG level information respectively:

$ pulp-admin --help
Usage: pulp-admin [options]

Options:
  -h, --help            show this help message and exit
  -u USERNAME, --username=USERNAME
                        username for the Pulp server; if used will bypass the
                        stored certificate and override a username specified
                        in ~/.pulp/admin.conf
  -p PASSWORD, --password=PASSWORD
                        password for the Pulp server; must be used with
                        --username. if used will bypass the stored certificate
                        and override a password specified in
                        ~/.pulp/admin.conf
  --config=CONFIG       absolute path to the configuration file
  --map                 prints a map of the CLI sections and commands
  -v                    enables verbose output; use twice for increased
                        verbosity with debug information

Here is an example of how verbose flag can be used one or more times:

$ pulp-admin rpm repo create --repo-id test
A resource with the ID "test" already exists.


$ pulp-admin -v rpm repo create --repo-id test
2015-03-05 14:10:28,931 - ERROR - Exception occurred:
       href:      /pulp/api/v2/repositories/
       method:    POST
       status:    409
       error:     Duplicate resource: test
       traceback: None
       data:      {u'resource_id': u'test', u'error': {u'code': u'PLP0018', u'data': {u'resource_id': u'test'}, u'description': u'Duplicate resource: test', u'sub_errors': []}}

A resource with the ID "test" already exists.


$ pulp-admin -vv rpm repo create --repo-id test
2015-03-05 14:12:22,014 - DEBUG - sending POST request to /pulp/api/v2/repositories/
2015-03-05 14:12:22,361 - INFO - POST request to /pulp/api/v2/repositories/ with parameters {"display_name": null, "description": null, "distributors": [{"distributor_id": "yum_distributor", "auto_publish": true, "distributor_config": {"http": false, "relative_url": "test", "https": true}, "distributor_type_id": "yum_distributor"}, {"distributor_id": "export_distributor", "auto_publish": false, "distributor_config": {"http": false, "https": true}, "distributor_type_id": "export_distributor"}], "notes": {"_repo-type": "rpm-repo"}, "importer_type_id": "yum_importer", "importer_config": {}, "id": "test"}
2015-03-05 14:12:22,362 - INFO - Response status : 409

2015-03-05 14:12:22,362 - INFO - Response body :
 {
  "exception": null,
  "traceback": null,
  "_href": "/pulp/api/v2/repositories/",
  "resource_id": "test",
  "error_message": "Duplicate resource: test",
  "http_request_method": "POST",
  "http_status": 409,
  "error": {
    "code": "PLP0018",
    "data": {
      "resource_id": "test"
    },
    "description": "Duplicate resource: test",
    "sub_errors": []
  }
}

2015-03-05 14:12:22,362 - ERROR - Exception occurred:
        href:      /pulp/api/v2/repositories/
        method:    POST
        status:    409
        error:     Duplicate resource: test
        traceback: None
        data:      {u'resource_id': u'test', u'error': {u'code': u'PLP0018', u'data': {u'resource_id': u'test'}, u'description': u'Duplicate resource: test', u'sub_errors': []}}

A resource with the ID "test" already exists.

Authentication

This guide covers basic authentication and authorization in the Pulp Platform.

Basic Authentication of Users

All pulp-admin commands accept username and password to capture authentication credentials.

$ pulp-admin --help
Usage: pulp-admin [options]

Options:
  -h, --help            show this help message and exit
  -u USERNAME, --username=USERNAME
                        username for the Pulp server; if used will bypass the
                        stored certificate and override a username specified
                        in ~/.pulp/admin.conf
  -p PASSWORD, --password=PASSWORD
                        password for the Pulp server; must be used with
                        --username. if used will bypass the stored certificate
                        and override a password specified in ~/.pulp/admin.conf
  --config=CONFIG       absolute path to the configuration file
  --map                 prints a map of the CLI sections and commands
  -v                    enables verbose output; use twice for increased
                        verbosity with debug information

Pulp Admin client allows the user to specify username and password credentials in the user's local admin.conf ~/.pulp/admin.conf. Using the conf file avoids having to pass user credentials repeatedly using the command line. Also reading the password from a file that can only be read by certain users is more secure because it cannot be shown by listing the system processes.

# Add the following snippet to ``~/.pulp/admin.conf``

[auth]
username: admin
password: admin

# This enables the user to run pulp-admin commands without providing a username
# and password using the command line

$ pulp-admin repo list
+----------------------------------------------------------------------+
                              Repositories
+----------------------------------------------------------------------+
pulp-admin searches for a username and password to use in the following order:
·
credentials specified from the command line.
·
credentials set in the user's ~/.pulp/admin.conf.

Pulp Server installation comes with one default user created with admin level privileges. Username and password for this user can be configured in /etc/pulp/server.conf at the time of installation.

Below is an example of basic authentication of users based on their username and password when running a pulp-admin command.

$ pulp-admin repo list
Enter password:
+----------------------------------------------------------------------+
                              Repositories
+----------------------------------------------------------------------+

Note that username and password are parameters to the pulp-admin command, not the sub-command, like repo list in this case. You can also pass the password parameter on the command line with --password argument, but this is not a recommended method. Users should use interactive password as a preferred method.

Rather than specifying the credentials on each call to pulp-admin, a user can log in to the Pulp server. Logging in stores a user credentials certificate at ~/.pulp/user-cert.pem.

$ pulp-admin login -u admin
Enter password:
Successfully logged in. Session certificate will expire at Dec  6 21:47:33 2012
GMT.

Subsequent commands to pulp-admin will no longer require the username-password arguments and will instead use the user certificate. The user can be logged out by using the pulp-admin logout command.

$ pulp-admin logout
Session certificate successfully removed.

Layout of Auth Section

The root level auth section contains sub-sections to create and manage Pulp users, roles and their permissions for various resources.

$ pulp-admin auth
Usage: pulp-admin auth [SUB_SECTION, ..] COMMAND
Description: user, role and permission commands

Available Sections:
permission - manage granting, revoking and listing permissions for resources
role       - manage user roles
user       - manage users

Users

Users can be created to perform various administrative tasks on the Pulp Server. You can configure them with either admin level access or limited access to a few resources on the server.

$ pulp-admin auth user --help
Usage: pulp-admin user [SUB_SECTION, ..] COMMAND
Description: manage users

Available Commands:
create - creates a user
delete - deletes a user
list   - lists summary of users registered to the Pulp server
search - search items while optionally specifying sort, limit, skip, and requested fields
update - changes metadata of an existing user

Here is an example of creating and updating a user:

$ pulp-admin auth user create --login test-user
Enter password for user [test-user] :
Re-enter password for user [test-user]:
User [test-user] successfully created

If you intend to update the password for a user, you can use -p flag as shown in the example below to be prompted for a new password.

$ pulp-admin auth user update --login test-user --name "Test User" -p
Enter new password for user [test-user] :
Re-enter new password for user [test-user]:
User [test-user] successfully updated

You can also pass it on the command line with --password argument, but this method is just to provide a simpler way for scripting and is not recommended. Users should use interactive password update as a preferred method.

The user list command lists a summary of all users. It also accepts arguments to list all the details or specific fields for users.

$ pulp-admin auth user list --details
+----------------------------------------------------------------------+
                                 Users
+----------------------------------------------------------------------+

Login:  admin
Name:   admin
Roles:  super-users


Login:  test-user
Name:   test-user
Roles:
$ pulp-admin auth user list --fields roles
+----------------------------------------------------------------------+
                                 Users
+----------------------------------------------------------------------+

Login:  admin
Roles:  super-users


Login:  test-user
Roles:

Users can be removed from the Pulp server using the user delete command.

$ pulp-admin auth user delete --login test-user
User [test-user] successfully deleted

Users belonging to the super-users role can be deleted as well, as long as there is at least one such user remaining in the system.

$ pulp-admin auth user delete --login admin
The server indicated one or more values were incorrect. The server provided the
following error message:

The last superuser [admin] cannot be deleted

Permissions

Permissions to various resources can be accessed or manipulated using pulp-admin auth permission commands. There are 5 types of permissions - CREATE, READ, Update, DELETE and EXECUTE. Permissions are granted and revoked from a resource which is essentially a REST API path.

Here are a few examples of accessing and manipulation permissions:

$ pulp-admin auth permission list --resource /
+----------------------------------------------------------------------+
                               Permissions for /
+----------------------------------------------------------------------+

Admin:  CREATE, READ, UPDATE, DELETE, EXECUTE

The following command will give permissions to create, read and update repositories to test-user.

$ pulp-admin auth permission grant --resource /v2/repositories/ --login test-user -o create -o update -o read
Permissions [/v2/repositories/ : ['CREATE', 'UPDATE', 'READ']] successfully granted
to user [test-user]
$ pulp-admin auth permission list --resource /v2/repositories/
+----------------------------------------------------------------------+
                 Permissions for /repositories
+----------------------------------------------------------------------+

Test-user:  CREATE, UPDATE, READ

The following command will revoke permissions to create and update repositories from test-user.

$ pulp-admin auth permission revoke --resource /v2/repositories/ --login test-user -o create -o update
Permissions [/v2/repositories/ : ['CREATE', 'UPDATE']] successfully revoked from
user [test-user]

NOTE:

The /v2 prefix and the trailing / are always present in a resource name for permission commands.

Roles

In order to efficiently administer permissions, Pulp uses the notion of roles to enable an administrator to grant and revoke permission on a resource to a group of users instead of individually. The pulp-admin auth role command provides the ability to list the currently defined roles, create/delete roles, and manage user membership in a role. Pulp installation comes with a default super-users role with admin level privileges, and the default admin user belongs to this role.

The role list command is used to list the current roles.

$ pulp-admin auth role list
+----------------------------------------------------------------------+
                                Roles
+----------------------------------------------------------------------+

Id:     super-users
Users:  admin

A role can be created and deleted by specifying a role id.

$ pulp-admin auth role create --role-id consumer-admin
Role [consumer-admin] successfully created

$ pulp-admin auth role delete --role-id consumer-admin
Role [consumer-admin] successfully deleted

A user can be added and removed from a role using role user add and role user remove commands respectively. Note that both the user and the role should exist on the pulp server.

$ pulp-admin auth role user add --role-id super-users --login test-user
User [test-user] successfully added to role [super-users]

$ pulp-admin auth role user remove --role-id super-users --login test-user
User [test-user] successfully removed from role [super-users]

Permissions can be granted and revoked from roles just like users. In this case all the users belonging to the given role will inherit these permissions.

$ pulp-admin auth permission grant --resource /repositories --role-id test-role -o read
Permissions [/repositories : ['READ']] successfully granted to role [test-role]

$ pulp-admin auth permission revoke --resource /repositories --role-id test-role -o read
Permissions [/repositories : ['READ']] successfully revoked from role [test-role]

Consumer

There are several commands for managing consumers. Other type-specific commands, such as bind, are provided by type-specific extensions.

History

Pulp keeps a history of the operations that pertain to each consumer. The history command has several options for filtering and limiting its output.

$ pulp-admin consumer history --help
Command: history
Description: displays the history of operations on a consumer

Available Arguments:

  --consumer-id - (required) unique identifier; only alphanumeric, -, and _
                  allowed
  --event-type  - limits displayed history entries to the given type; supported
                  types: ("consumer_registered", "consumer_unregistered",
                  "repo_bound", "repo_unbound","content_unit_installed",
                  "content_unit_uninstalled", "unit_profile_changed",
                  "added_to_group","removed_from_group")
  --limit       - limits displayed history entries to the given amount (must be
                  greater than zero)
  --sort        - indicates the sort direction ("ascending" or "descending")
                  based on the entry's timestamp
  --start-date  - only return entries that occur on or after the given date in
                  iso8601 format (yyyy-mm-ddThh:mm:ssZ)
  --end-date    - only return entries that occur on or before the given date in
                  iso8601 format (yyyy-mm-ddThh:mm:ssZ)

The history command shows the most recent operations first.

$ pulp-admin consumer history --consumer-id=consumer1
+----------------------------------------------------------------------+
                        Consumer History [ consumer1 ]
+----------------------------------------------------------------------+

Consumer Id:  consumer1
Type:         repo_bound
Details:
  Distributor Id: puppet_distributor
  Repo Id:        repo1
Originator:   admin
Timestamp:    2013-01-22T16:07:52Z


Consumer Id:  consumer1
Type:         consumer_registered
Details:      None
Originator:   admin
Timestamp:    2013-01-22T15:09:58Z

List

This command retrieves a list of consumers. "Confirmed" bindings are those for which the agent on the remote consumer has performed a bind action. "Unconfirmed" bindings are waiting for that remote action to take place.

$ pulp-admin consumer list --help
Command: list
Description: lists a summary of consumers registered to the Pulp server

Available Arguments:

  --fields   - comma-separated list of consumer fields; Example:
               "id,display_name". If specified, only the given fields will be
               displayed.
  --bindings - if specified, the bindings information is displayed
  --details  - if specified, all of the consumer information is displayed

$ pulp-admin consumer list
+----------------------------------------------------------------------+
                               Consumers
+----------------------------------------------------------------------+

Id:            consumer1
Display Name:  Consumer 1
Description:   The first consumer.
Bindings:
  Confirmed:   repo1
  Unconfirmed:
Notes:

Unregister

Registration must be initiated from pulp-consumer, but unregistering can be done from either end.

$ pulp-admin consumer unregister --help
Command: unregister
Description: unregisters a consumer

Available Arguments:

  --consumer-id - (required) unique identifier; only alphanumeric, -, and _
                  allowed

$ pulp-admin consumer unregister --consumer-id=consumer1
Consumer [ consumer1 ] successfully unregistered

Update

Basic attributes of consumers can be modified using the update command.

$ pulp-admin consumer update --help
Command: update
Description: changes metadata on an existing consumer

Available Arguments:

  --display-name - user-readable display name (may contain i18n characters)
  --description  - user-readable description (may contain i18n characters)
  --note         - adds/updates/deletes notes to programmatically identify the
                   resource; key-value pairs must be separated by an equal sign
                   (e.g. key=value); multiple notes can be changed by specifying
                   this option multiple times; notes are deleted by specifying
                   "" as the value
  --consumer-id  - (required) unique identifier; only alphanumeric, -, and _
                   allowed


$ pulp-admin consumer update --consumer-id=consumer1 --description='First consumer.'
Consumer [ consumer1 ] successfully updated

Consumer Groups

Consumer Groups allow you to associate any number of consumers with a named group and perform different actions on it.

$ pulp-admin rpm consumer group --help

Usage: pulp-admin [SUB_SECTION, ..] COMMAND
Description: consumer group commands

Available Sections:
  members - manage members of repository groups
  package - consumer group package installation management

Available Commands:
  bind   - binds each consumer in a consumer group to a repository
  create - creates a new consumer group
  delete - deletes a consumer group
  list   - lists consumer groups on the Pulp server
  search - searches for consumer groups on the Pulp server
  unbind - unbinds each consumer in a consumer group from a repository
  update - updates the metadata about the group itself (not its members)

Create, Update, Delete

To create a consumer group, the only required argument is a unique ID.

$ pulp-admin rpm consumer group create --group-id test-group

Consumer Group [test-group] successfully created

The update command takes similar arguments to the create command. This call updates metadata about the consumer group itself (not the members).

$ pulp-admin rpm consumer group update --group-id test-group --display-name new-name

Consumer Group [test-group] successfully updated

The new consumer group can be seen with its unique ID and display name.

$ pulp-admin rpm consumer group list
+----------------------------------------------------------------------+
                          Consumer Groups
+----------------------------------------------------------------------+

Id:           test-group
Display Name: new-name
Description:  None
Consumer Ids:
Notes:

Consumer groups can be removed from the Pulp server using the delete command. Deleting a consumer group has no effect on the consumers that are members of the group.

pulp-admin rpm consumer group delete --group-id test-group

Consumer Group [test-group] successfully deleted

Group membership

Consumers can be associated and unassociated with any existing consumer group.

$ pulp-admin rpm consumer group members

Usage: pulp-admin [SUB_SECTION, ..] COMMAND
Description: manage members of repository groups

Available Commands:
add    - add consumers to an existing group
list   - list the consumers in a particular group
remove - remove consumers from a group

The call is idempotent if the consumer is already memeber of the group.

$ pulp-admin rpm consumer group members add --group-id test-group --str-eq='id=consumer1'

Consumer Group [test-group] membership updated

$ pulp-admin rpm consumer group list
+----------------------------------------------------------------------+
                          Consumer Groups
+----------------------------------------------------------------------+

Id:           test-group
Display Name: None
Description:  None
Consumer Ids: consumer1
Notes:

$ pulp-admin rpm consumer group members list --group-id test-group
+----------------------------------------------------------------------+
                       Consumer Group Members
+----------------------------------------------------------------------+

Id:           consumer1
Display Name: consumer1
Description:  None
Notes:

Now you can see that consumer1 is part of the group. Similarly, you can remove consumers from consumer groups.

$ pulp-admin rpm consumer group members remove --group-id test-group --str-eq='id=consumer1'

Consumer Group [test-group] membership updated

Repository Binding

The bind command allows to bind each consumer in a consumer group to a repository.

$ pulp-admin rpm consumer group bind --consumer-group-id test-group --repo-id zoo

Consumer Group [test-group] successfully bound to repository [zoo]

You can also use the unbind command to unbind each consumer in a consumer group from a repo.

$ pulp-admin rpm consumer group unbind --consumer-group-id test-group --repo-id zoo

Consumer Group [test-group] successfully unbound from repository [zoo]

Content Management

This section manages content on each consumer belonging to the group.

$ pulp-admin rpm consumer group package

Usage: pulp-admin [SUB_SECTION, ..] COMMAND
Description: consumer group package installation management

Available Commands:
install   - install packages
uninstall - uninstall packages
update    - update (installed) packages


$ pulp-admin rpm consumer group package install --name zsh --consumer-group-id test

This command may be exited via ctrl+c without affecting the request.


[-]
Running...

Install on consumer [c1] succeeded
+----------------------------------------------------------------------+
                             Installed
+----------------------------------------------------------------------+

Name:    zsh
Version: 5.0.7
Arch:    x86_64
Repoid:  updates-testing

Events

Pulp has an event system that makes it easy for third party application to integrate and for users to stay informed via email about the Pulp server's activity. A specific set of operations inside the Pulp server produce reports about what they accomplished, and those reports are fed into an event framework. Users can then setup event listeners that listen for specific events, which then sends notifications to the user or an automated service. Notifier types include email, Amqp, and HTTP.

Listeners

Event listeners connect one or more event types with a notifier.

$ pulp-admin event listener
Usage: pulp-admin listener [SUB_SECTION, ..] COMMAND
Description: manage server-side event listeners

Available Sections:
  amqp  - manage amqp listeners
  email - manage email listeners
  http  - manage http listeners

Available Commands:
  delete - delete an event listener
  list   - list all of the event listeners in the system

From this section of the CLI, you can list and delete listeners, or drill down into type-specific sections to create and update. Examples for each type of notifier appear below.

Email

Event reports can be sent directly to an email address. The messages currently consists of a JSON-serialized representation of the actual event body. This meets a basic use case for having email notification with all of the available event data, but we intend to make the output more human-friendly in the future.

NOTE:

Before attempting to setup email notifications, be sure to configure the "[email]" section of Pulp's settings file, /etc/pulp/server.conf

$ pulp-admin event listener email create --help
Command: create
Description: create a listener

Available Arguments:

  --event-type - (required) one of "repo.sync.start", "repo.sync.finish",
                 "repo.publish.start", "repo.publish.finish". May be specified
                 multiple times. To match all types, use value "*"
  --subject    - (required) text of the email's subject
  --addresses  - (required) this is a comma separated list of email addresses
                 that should receive these notifications. Do not include spaces.

To add an email notifier, you must specify what types of events to listen to, what the email subject should be, and who should receive the emails.

$ pulp-admin event listener email create --event-type="repo.sync.start" --subject="pulp notification" --addresses=someone@redhat.com,another@redhat.com
Event listener successfully created

$ pulp-admin event listener list
Event Types:       repo.sync.start
Id:                5081a42ce19a00ea4300000e
Notifier Config:
  Addresses: someone@redhat.com, another@redhat.com
  Subject:   pulp notification
Notifier Type Id:  email

Using python's builtin testing MTA, the following message was captured after being sent by the above-configured listener.

$ python -m smtpd -n -c DebuggingServer localhost:1025
---------- MESSAGE FOLLOWS ----------
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: pulp notification
From: no-repy@your.domain
To: someone@redhat.com
X-Peer: 127.0.0.1

{
  "call_report": {
    "task_group_id": "aaa8f2ec-964c-4d62-bba9-3191aad9c3ea",
    "exception": null,
    "task_id": "79be77a8-1a20-11e2-aeb9-1803731e94c4",
    "tags": [
      "pulp:repository:pulp2",
      "pulp:action:sync"
    ],
    "reasons": [],
    "start_time": "2012-10-19T19:09:16Z",
    "traceback": null,
    "schedule_id": null,
    "finish_time": null,
    "state": "running",
    "result": null,
    "progress": {},
    "principal_login": "admin",
    "response": "accepted"
  },
  "event_type": "repo.sync.start",
  "payload": {
    "repo_id": "pulp2"
  }
}
------------ END MESSAGE ------------

HTTP

Event reports can be sent via a POST call to any URL, and basic auth credentials may be supplied. The body of the HTTP request is a JSON-serialized version of the event report. Here is an example of creating an HTTP listener.

$ pulp-admin event listener http create --event-type=repo.sync.start --url=http://myserver.redhat.com
Event listener successfully created

[mhrivnak@redhrivnak pulp]$ pulp-admin event listener list
Event Types:       repo.sync.start
Id:                50bf51ffdd01fb5b9d000003
Notifier Config:
  URL: http://myserver.redhat.com
Notifier Type Id:  http

Amqp

Amqp is an industry standard for integrating separate systems, applications, or even components within an application through asynchronous messages. Pulp's event reports can be sent as the body of an Amqp message to a message broker, where it will be forwarded to any number of clients who subscribe to Pulp's topic exchange.

Pulp uses Apache Qpid as an Amqp broker and publishes its messages to a topic exchange. Even though Amqp is a widely-adopted standard protocol, there are several incompatible versions of it. For this reason, there is not another broker that can be used in place of Qpid.

NOTE:

Before using an Amqp notifier, be sure to look in Pulp's server config file (/etc/pulp/server.conf) in the "[messaging]" section to configure your settings.

$ pulp-admin event listener amqp create --help
Command: create
Description: create a listener

Available Arguments:

  --event-type - (required) one of "repo.sync.start", "repo.sync.finish",
                 "repo.publish.start", "repo.publish.finish". May be specified
                 multiple times. To match all types, use value "*"
  --exchange   - optional name of an exchange that overrides the setting from
                 server.conf

Here you can also specify an exchange name. If you don’t specify one, it will default to the value pulled from /etc/pulp/server.conf in the "[messaging]" section. If you don’t set one there either, Pulp will default to "amq.topic", which is an exchange guaranteed to be available on any broker. Regardless of what name you choose (we suggest "pulp" as a reasonable choice), you do not need to create the exchange or take any action on the Amqp broker. Pulp will automatically create the exchange if it does not yet exist.

As for selecting event types, if you are unsure, we suggest going with "*" to select all of them. The client can choose which types of messages they want to subscribe to based on hierarchically matching against the event type (called a "subject" in Amqp). It is cheap and fast to send a message to a broker, making it convenient to fire and forget. Let the clients decide which subjects they care about. More about subject matching here.

This is an example of creating an Amqp event listener.

$ pulp-admin event listener amqp create --event-type='*' --exchange=pulp
Event listener successfully created

[mhrivnak@dhcp-230-147 pulp]$ pulp-admin event listener list
Event Types:       *
Id:                5092d9b3e19a00c58600000c
Notifier Config:
  Exchange: pulp
Notifier Type Id:  amqp

Event Types

These are the types of events that can be associated with listeners, and each description includes a partial list of the types of data that gets reported.

repo.publish.start
Fires when any repository starts a publish operation.
·
start time
·
repo_id
·
user who initiated the sync
·
task ID
repo.publish.finish
Fires when any repository finishes a publish operation.
·
start time
·
end time
·
repo_id
·
task ID
·
success/failure
·
number of items published
·
errors
repo.sync.start
Fires when any repository starts a sync operation.
·
start time
·
repo_id
·
user who initiated the sync
·
task ID
repo.sync.finish
Fires when any repository finishes a sync operation.
·
start time
·
end time
·
repo_id
·
task ID
·
success/failure
·
number of items imported
·
errors

Nodes

This guide covers admin client commands for managing Pulp Nodes in the Pulp Platform. For an overview, tips, and, troubleshooting, please visit the Pulp Nodes Concepts Guide.

Layout

The root level node section contains the following features.

$ pulp-admin node --help
Usage: pulp-admin [SUB_SECTION, ..] COMMAND
Description: pulp nodes related commands

Available Sections:
 repo - repository related commands
 sync - child node synchronization commands

Available Commands:
 activate   - activate a consumer as a child node
 bind       - bind a child node to a repository
 deactivate - deactivate a child node
 list       - list child nodes
 unbind     - removes the binding between a child node and a repository

Listing

The node list command may be used to list child nodes.

pulp-admin node list --help
Command: list
Description: list child nodes

Available Arguments:

 --fields   - comma-separated list of consumer fields; Example:
              "id,display_name". If specified, only the given fields will be
              displayed.
 --bindings - if specified, the bindings information is displayed
 --details  - if specified, all of the consumer information is displayed

Activation

A Pulp server that is registered as a consumer to another Pulp server can be designated as a child node. Once activated on the parent server, the consumer is recognized as a child node of the parent and can be managed using node commands.

To activate a consumer as a child node, use the node activate command. More information on node-level synchronization strategies can be found here.

$ pulp-admin node activate --help
Command: activate
Description: activate a consumer as a child node

Available Arguments:

 --consumer-id - (required) unique identifier; only alphanumeric, -, and _
                 allowed
 --strategy    - synchronization strategy (mirror|additive) default is additive

A child node may be deactivated using node deactivate command. Once deactivated, the node may no longer be managed using node commands.

$ pulp-admin node deactivate --help
Command: deactivate
Description: deactivate a child node

Available Arguments:

 --node-id - (required) unique identifier; only alphanumeric, -, and _ allowed

NOTE:

Consumer (child node) un-registration will automatically deactivate the node. When a node is activated again, it will have the same repositories bound to it as it had before deactivation.

Repositories

The commands provided in the node repo section are used to perform Nodes specific management of existing repositories.

$ pulp-admin node repo --help
Usage: pulp-admin [SUB_SECTION, ..] COMMAND
Description: repository related commands

Available Commands:
 disable - disables binding to a repository by a child node
 enable  - enables binding to a repository by a child node
 list    - list node enabled repositories
 publish - publishing commands

Listing

A listing of enabled repositories may be obtained by using the node repo list command.

$ pulp-admin node repo list --help
Command: list
Description: list node enabled repositories

Available Arguments:

 --details - if specified, detailed configuration information is displayed for
             each repository
 --fields  - comma-separated list of repository fields; Example:
             "id,description,display_name,content_unit_counts". If
             specified, only the given fields will be displayed.
 --all, -a - if specified, information on all Pulp repositories, regardless of
             type, will be displayed

Enabling

A repository may be enabled using the node repo enable command. More information on repository-level synchronization strategies can be found here.

$ pulp-admin node repo enable --help
Command: enable
Description: enables binding to a repository by a child node

Available Arguments:

 --repo-id      - (required) unique identifier; only alphanumeric, -, and _
                  allowed
 --auto-publish - if "true", the nodes information will be automatically
                  published each time the repository is synchronized; defaults
                  to "true"

WARNING:

Using auto-publish causes the Nodes information to be published each time the repository is synchronized. This may increase the time it takes to perform the synchronization depending on the size of the repository.

Publishing

Manually publishing the Nodes data necessary for child node synchronization, can be triggered using the node repo publish command.

$ pulp-admin node repo publish --help
Command: publish
Description: publishing commands

Available Arguments:

 --repo-id - (required) unique identifier; only alphanumeric, -, and _ allowed

NOTE:

Repositories MUST be published for child node synchronization to be successful.

Binding

The node bind command is used to associate a repository with a child node. This association determines which repositories may be synchronized to child nodes. The strategy specified here overrides the default strategy specified when the repository was enabled. More information on repository-level synchronization strategies can be found here.

$ pulp-admin node bind --help
Command: bind
Description: bind a child node to a repository

Available Arguments:

 --repo-id  - (required) unique identifier; only alphanumeric, -, and _ allowed
 --node-id  - (required) unique identifier; only alphanumeric, -, and _ allowed
 --strategy - synchronization strategy (mirror|additive) default is additive

The node unbind command may be used to remove the association between a child node and a repository. Once the association is removed, the specified repository can no longer be be synchronized to the child node.

$ pulp-admin node unbind --help
Command: unbind
Description: removes the binding between a child node and a repository

Available Arguments:

 --repo-id - (required) unique identifier; only alphanumeric, -, and _ allowed
 --node-id - (required) unique identifier; only alphanumeric, -, and _ allowed

NOTE:

Only activated nodes and enabled repositories may be specified.

Synchronizing

The synchronization of child nodes may be triggered using the node sync commands. More information on node synchronization can be found here.

$ pulp-admin node sync --help
Usage: pulp-admin [SUB_SECTION, ..] COMMAND
Description: child node synchronization commands

Available Commands:
 run - triggers an immediate synchronization of a child node

An immediate synchronization can be triggered using the node sync run command.

$ pulp-admin node sync run --help
Command: run
Description: triggers an immediate synchronization of a child node

Available Arguments:

 --node-id       - (required) unique identifier; only alphanumeric, -, and _ allowed
 --max-downloads - maximum number of downloads permitted to run concurrently
 --max-speed     - maximum bandwidth used per download in bytes/sec

WARNING:

Make sure repositories have been published.

Repositories

This guide covers core features for managing repositories in the Pulp Platform. For more detail about how to work with repositories of a specific content type, please visit the user guide for that type. Examples will use "rpm" as the demo type when necessary, but they will be limited to generic features.

Layout

The root level repo section contains the following features. These features apply across all repositories, regardless of the specific types of content they will support.

$ pulp-admin repo --help
Usage: pulp-admin repo [SUB_SECTION, ..] COMMAND
Description: list repositories and manage repo groups

Available Sections:
  group   - repository group commands
  history - show sync and publish history
  tasks   - list and cancel tasks related to a specific repository

Available Commands:
  download - queues a full download of all missing units in a repository that is using a
             "background" or "on_demand" download policy.
  list     - lists repositories on the Pulp server

By comparison, many other features are implemented under a root-level section named for a content type. For example, the RPM repo section looks like this:

$ pulp-admin rpm repo --help
Usage: pulp-admin repo [SUB_SECTION, ..] COMMAND
Description: repository lifecycle commands

Available Sections:
  content - search the contents of a repository
  copy    - copies one or more content units between repositories
  export  - run or view the status of a repository export
  group   - repository group commands
  publish - run or view the status of publish tasks
  remove  - remove modules from a repository
  sync    - run, schedule, or view the status of sync tasks
  uploads - upload modules into a repository

Available Commands:
  create - creates a new repository
  delete - deletes a repository
  list   - lists repositories on the Pulp server
  search - searches for repositories on the server
  update - changes metadata on an existing repository

The reason for putting repository commands in different places is that some features will be customized and augmented by plugins, such that their versions of common commands will only be applicable to their own content. Commands that can operate on all repositories go in the generic "repo" section.

Create, Update, Delete

To create a repository, the only required argument is a unique ID. Consult the help text for the create command of each particular repository type to see what other options are available.

$ pulp-admin rpm repo create --repo-id=foo
Successfully created repository [foo]

The update command takes similar arguments to the create command.

$ pulp-admin rpm repo update --repo-id=foo --display-name='Foo Repo'
Repository [foo] successfully updated

The new repository can be seen with its unique ID and display name.

$ pulp-admin rpm repo list
+----------------------------------------------------------------------+
                            RPM Repositories
+----------------------------------------------------------------------+

Id:                 foo
Display Name:       Foo Repo
Description:        None
Content Unit Count: 0

Deleting a repository is an asynchronous operation. In case other tasks are already in progress on this repository, the server will allow those tasks to complete before executing the deletion. The example below shows how to request deletion and then check the status of that task.

$ pulp-admin rpm repo delete --repo-id=foo
The request to delete repository [foo] has been received by the server. The
progress of the task can be viewed using the commands under "repo tasks"

$ pulp-admin repo tasks list --repo-id=foo
+----------------------------------------------------------------------+
                                 Tasks
+----------------------------------------------------------------------+

Operations:  delete
Resources:   foo (repository)
State:       Successful
Start Time:  2012-12-17T23:17:46Z
Finish Time: 2012-12-17T23:17:46Z
Result:      N/A
Task Id:     2d4fc3da-7ad7-448c-a9dd-78e79f71ef2f

List

This command lists all repositories in Pulp, regardless of their content type. To list and search repositories only of a particular type, go to that type's area of the CLI, such as pulp-admin rpm repo list. (For more detailed output use '--details' option).

$ pulp-admin repo list
+----------------------------------------------------------------------+
                              Repositories
+----------------------------------------------------------------------+

Id:                 pulp
Display Name:       Pulp
Description:        Pulp's stable repository
Content Unit Count: 39

Id:                 repo1
Display Name:       repo1
Description:        None
Content Unit Count: 0

Id:                 repo2
Display Name:       repo2
Description:        None
Content Unit Count: 0

Also there is possibility to list information with and without details about one specific repo.

pulp-admin repo list --repo-id iso-test
+----------------------------------------------------------------------+
                              Repositories
+----------------------------------------------------------------------+

Id:                   iso-test
Display Name:         iso-test
Description:          None
Content Unit Counts:


pulp-admin repo list --repo-id iso-test --details
+----------------------------------------------------------------------+
                              Repositories
+----------------------------------------------------------------------+

Id:                   iso-test
Display Name:         iso-test
Description:          None
Content Unit Counts:
Notes:
Importers:
  Config:
  Id:           iso_importer
  Importer Type Id: iso_importer
  Last Sync:        None
  Repo Id:          iso-test
  Scheduled Syncs:
Distributors:
  Auto Publish:        True
  Config:
  Distributor Type Id: iso_distributor
  Id:                  iso_distributor
  Last Publish:        None
  Repo Id:             iso-test
  Scheduled Publishes:

Copy Between Repositories

Content units can be copied from one repository to another using Pulp's criteria search. For content units that involve an on-disk file (such as RPMs having a package stored on disk), the file is only stored once even if it is included in multiple Pulp repositories.

The following example assumes that the repository "foo" has some content units and that we want to copy all of them to the repository "bar".

$ pulp-admin rpm repo copy rpm --from-repo-id=foo --to-repo-id=bar
Progress on this task can be viewed using the commands under "repo tasks".

$ pulp-admin repo tasks list --repo-id=foo
+----------------------------------------------------------------------+
                                 Tasks
+----------------------------------------------------------------------+

Operations:  associate
Resources:   bar (repository), foo (repository)
State:       Successful
Start Time:  2012-12-17T23:27:12Z
Finish Time: 2012-12-17T23:27:13Z
Result:      N/A
Task Id:     8c3a6964-245f-4fe5-9d7c-8c6bac55cffb

The copy was successful. Here you can see that the repository "bar" now has the same number of content units as "foo".

$ pulp-admin rpm repo list
+----------------------------------------------------------------------+
                            RPM Repositories
+----------------------------------------------------------------------+

Id:                 foo
Display Name:       foo
Description:        None
Content Unit Count: 36

Id:                 bar
Display Name:       bar
Description:        None
Content Unit Count: 36

Groups

Repository Groups allow you to associate any number of repositories, even of varying content types, with a named group. Features that make use of repository groups are forthcoming in future releases of Pulp.

Here is an example of creating a repo group and adding members to it:

$ pulp-admin repo group create --group-id='group1' --description='misc. repos' --display-name='Group 1'
Repository Group [group1] successfully created

$ pulp-admin repo group members add --group-id=group1 --str-eq='id=repo1'
Successfully added members to repository group [group1]

The members add command takes advantage of Pulp's criteria search feature, so you can add many repositories at once. In this case, we provided a specific repository name. Let's look at the result of these two commands by listing the repository groups.

$ pulp-admin repo group list
+----------------------------------------------------------------------+
                           Repository Groups
+----------------------------------------------------------------------+

Id:           group1
Display Name: Group 1
Description:  misc. repos
Repo Ids:     repo1
Notes:

Notice that "repo1" shows up in the "Repo Ids" field.

Tasks

Some operations on repositories, such as sync, publish, and delete, may operate asynchronously. When you execute these operations, Pulp will give you a "task ID". You can use that task ID to check the status of the operation. From this section of the CLI, you can cancel, list, and get details about repository tasks.

$ pulp-admin repo tasks --help
Usage: pulp-admin tasks [SUB_SECTION, ..] COMMAND
Description: list and cancel tasks related to a specific repository

Available Commands:
  cancel  - cancel one or more tasks
  details - displays more detailed information about a specific task
  list    - lists tasks queued (waiting) or running on the server

Orphaned Content Units

Introduction

Repositories are the container into which content is drawn into Pulp and by which Pulp serves content. However, under the hood, Pulp actually manages content separately from repositories. This allows Pulp to minimize disk space by never duplicating content that is shared between repositories (i.e. content units that appear in more than one repository).

The consequence of this approach is that when a repository is deleted from the Pulp server, the content associated with that repository is not. Content units that are no longer associated with any repositories are referred to as orphaned content units or simply orphans.

This page describes the management of orphaned content units.

Listing Orphaned Content Units

The pulp-admin command line client provides the orphan section and the list command to inspect the orphaned content units on your server:

$ pulp-admin orphan list --type=rpm --details
Arch:          noarch
Checksum:      7e9cad8b2cd436079fd524803ec7fa209a666ecdda05c6f9c8c5ee70cdea9ce6
Checksumtype:  sha256
Epoch:         0
Id:            a0079ca2-1d4f-4d01-8307-3f183f1843a6
Name:          tito
Release:       1.fc16
Version:       0.4.9

+----------------------------------------------------------------------+
                                Summary
+----------------------------------------------------------------------+

RPM:    1
Total:  1

You can filter the list by content type by using the --type=<type> flag.

You can use the --details flag to list the individual orphaned content units. Otherwise only the Summary section is displayed. This flag is not available when the content type is omitted, and will be ignored if specified.

Removing Orphaned Content Units

The pulp-admin command line client provides the orphan section and remove command to remove orphaned content units from your server.

It has three flags:

·
--type=<type> to remove all the orphaned content units of a particular type
·
--id=<id> to remove a particular orphaned content unit
·
--all to remove all the orphaned content units on the server
$ pulp-admin orphan remove --all
Request accepted

check status of task e239ae4f-7fad-4004-bfb6-8e06f17d22ef with "pulp-admin tasks details"

$ pulp-admin tasks details --task-id e239ae4f-7fad-4004-bfb6-8e06f17d22ef
+----------------------------------------------------------------------+
                              Task Details
+----------------------------------------------------------------------+

Operations:
Resources:    orphans (content_unit)
State:        Successful
Start Time:   2012-12-09T03:26:51Z
Finish Time:  2012-12-09T03:26:51Z
Result:       N/A
Task Id:      e239ae4f-7fad-4004-bfb6-8e06f17d22ef
Progress:

$ pulp-admin orphan list
$

Inspecting the Server

Pulp as a Platform

The Pulp server has very little built in functionality. To provide the functionality that administrators rely on, Pulp loads a number of plugins that define types and importers and distributors. The former are definitions of categories of content units and the metadata that needs to be associated with them. The latter two are classes of plugins that allow Pulp to manage content units, of particular types, by bring them into the server and making them available from the server respectively.

This page shows how to query the server for each of these classes of plugins.

Content Unit Types

The pulp-admin command line client provides the server section and the types command to query the server about the content unit type definitions that have been loaded.

$ pulp-admin server types
+----------------------------------------------------------------------+
                        Supported Content Types
+----------------------------------------------------------------------+

Id:               distribution
Display Name:     Distribution
Description:      Kickstart trees and all accompanying files
Referenced Types:
Search Indexes:   id, family, variant, version, arch
Unit Key:         id, family, variant, version, arch

[snip]

Id:               rpm
Display Name:     RPM
Description:      RPM
Referenced Types: erratum
Search Indexes:   name, epoch, version, release, arch, filename, checksum,
                  checksumtype
Unit Key:         name, epoch, version, release, arch, checksumtype, checksum

[snip]

Id:               puppet_module
Display Name:     Puppet Module
Description:      Puppet Module
Referenced Types:
Search Indexes:   author, tag_list
Unit Key:         name, version, author

The output above shows a snippet of the types that are defined by the default plugins that have been developed with the Pulp server. Each type has the following fields:

·
Id: this is a programmatic id that the server uses to identify the type
·
Display Name: an optional, human-friendly, display name
·
Description: an optional description of the type
·
Referenced Types: a list of other types that may be referenced by a content unit of this type in some way
·
Search Indexes: metadata fields that can potentially be used as search criteria
·
Unit Key: a metadata field, or set of fields, that will uniquely identify a content unit of this type

Content Unit Importers

The pulp-admin command line client provides the server section and the importers command to query the server about the importer plugins that have been loaded.

$ pulp-admin server importers
+----------------------------------------------------------------------+
                          Supported Importers
+----------------------------------------------------------------------+

Id:           puppet_importer
Display Name: Puppet Importer
Types:        puppet_module

Id:           yum_importer
Display Name: Yum Importer
Types:        distribution, drpm, erratum, package_group, package_category, rpm,
              srpm

The output above shows the importers that have been developed along side the Pulp platform. Each importer has the following fields:

·
Id: a programmatic id that the server uses to identify the importer
·
Display Name: an optional, human-friendly, display name
·
Types: a list of type ids that the importer can handle

Content Unit Distributors

The pulp-admin command line client provides the server section and the distributors command to query the server about the distributor plugins that have been loaded.

$ pulp-admin server distributors
+----------------------------------------------------------------------+
                         Supported Distributors
+----------------------------------------------------------------------+

Id:           yum_distributor
Display Name: Yum Distributor
Types:        rpm, srpm, drpm, erratum, distribution, package_category,
              package_group

Id:           export_distributor
Display Name: Export Distributor
Types:        rpm, srpm, drpm, erratum, distribution, package_category,
              package_group

Id:           puppet_distributor
Display Name: Puppet Distributor
Types:        puppet_module

The output above shows the distributors that have been developed along side the Pulp platform. Each distributor has the following fields:

·
Id: a programmatic id that the server uses to identify the distributor
·
Display Name: an optional, human-friendly, display name
·
Types: a list of type ids that the distributor can handle

Tasks

Introduction

The Pulp server uses Celery to handle requests that may take longer than a HTTP request timeout to execute. Many of the commands from the pulp-admin command line client will return messages along the lines of

Request accepted

check status of task e239ae4f-7fad-4004-bfb6-8e06f17d22ef with "pulp-admin tasks details"

This means the server's REST API returned a 202 ACCEPTED response with the task information for the task that is handling the request.

This page details querying and managing these tasks.

Details

The pulp-admin command line client provides the tasks section and the details command to inspect the runtime details of a task, identified with the required --task-id=<id> flag.

$ pulp-admin tasks details --task-id e239ae4f-7fad-4004-bfb6-8e06f17d22ef
+----------------------------------------------------------------------+
                              Task Details
+----------------------------------------------------------------------+

Operations:
Resources:    orphans (content_unit)
State:        Successful
Start Time:   2012-12-09T03:26:51Z
Finish Time:  2012-12-09T03:26:51Z
Result:       N/A
Task Id:      e239ae4f-7fad-4004-bfb6-8e06f17d22ef
Progress:

In the output above there are several sections:

·
Operations: a list of operations that are being performed by this task
·
Resources: a list of resources that are being operated on
·
State: the state of the task, such as: Waiting, Running, Successful or Error
·
Start Time: the UTC time the task started
·
Finish Time: the UTC time the task finished
·
Result: the reported result of the task, if any
·
Task Id: a unique identifier for the task (as a UUID)
·
Progress: arbitrary progress information provided by the task, if any

Listing

To see all the tasks on the server at any given time, the pulp-admin command line client provides the tasks section and the list command.

It provides all the same information as the details command, but for every task that has been executed on the pulp server. The length of history depends on the settings described below.

In addition to tasks launched using pulp-admin or the API , reaper and monthly tasks appear in the list.

The reaper task is responsible for cleaning up the database on a regularly scheduled interval. The interval is configured with reaper_interval in [data_reaping] section of /etc/pulp/server.conf. The value can be whole or fraction of days. The length of time to keep documents for each collection is also configured in the same section. task_status_history, consumer_history, repo_sync_history, repo_publish_history, repo_group_publish_history, and task_result_history take values of whole or fraction of days to keep that type of history. This database cleanup is needed because these transactions can occur very frequently and as result the database can grow to an unreasonable size.

The monthly task is run every 30 days to clean up data referencing any repositories that no longer exist.

Purging

To purge the completed tasks on the server at any given time, the pulp-admin command line client provides the tasks section and the purge command.

By giving a --all flag, the tasks in successful, failed and skipped state will be purged.

By giving a --state flag, specific states can be passed as an argument and all the tasks belonging to these states will be purged. These states must be from the completed state list(except canceled) or the command will result in error message.

$ pulp-admin tasks purge
+----------------------------------------------------------------------+
                         Purge Completed Tasks
+----------------------------------------------------------------------+

Command: purge
Description: purge tasks in one or more completed states

Available Arguments:

  --all, -a   - if specified, all tasks in "successful, skipped and failed states
                will be purged
  --state, -s - comma-separated list of tasks states desired to be purged.
                Example: "successful,failed". Do not include spaces.

$ pulp-admin tasks purge --all
+----------------------------------------------------------------------+
                         Purge Completed Tasks
+----------------------------------------------------------------------+

Task purging is successfully initiated.

$ pulp-admin tasks purge -s successful,failed
+----------------------------------------------------------------------+
                         Purge Completed Tasks
+----------------------------------------------------------------------+

Task purging is successfully initiated.

$ pulp-admin tasks purge -s canceled
+----------------------------------------------------------------------+
                         Purge Completed Tasks
+----------------------------------------------------------------------+

Invalid task state passed to parameters list: canceled.

Canceling a Task

Tasks may be canceled before they are run (i.e. in the waiting state) or while they are running.

The pulp-admin command line client provides the tasks section and the cancel command to cancel a task identified by the required --task-id flag.

$ pulp-admin tasks cancel --task-id e0e0a250-eded-468f-9d97-0419a00b130f

$ pulp-admin tasks details --task-id e0e0a250-eded-468f-9d97-0419a00b130f
+----------------------------------------------------------------------+
                              Task Details
+----------------------------------------------------------------------+

Operations:   sync
Resources:    ff7-e6 (repository)
State:        Canceled
Start Time:   2012-12-09T04:28:10Z
Finish Time:  2012-12-09T04:29:09Z
Result:       N/A
Task Id:      e0e0a250-eded-468f-9d97-0419a00b130f
Progress:
  Yum Importer:
    Comps:
      State: NOT_STARTED
    Content:
      Details:
        Delta Rpm:
          Items Left:  0
          Items Total: 0
          Num Error:   0
          Num Success: 0
          Size Left:   0
          Size Total:  0
        File:
          Items Left:  0
          Items Total: 0
          Num Error:   0
          Num Success: 0
          Size Left:   0
          Size Total:  0
        Rpm:
          Items Left:  6
          Items Total: 37
          Num Error:   0
          Num Success: 31
          Size Left:   112429996
          Size Total:  149958122
        Tree File:
          Items Left:  0
          Items Total: 0
          Num Error:   0
          Num Success: 0
          Size Left:   0
          Size Total:  0
      Error Details:
      Items Left:    0
      Items Total:   37
      Num Error:     0
      Num Success:   31
      Size Left:     112429996
      Size Total:    149958122
      State:         CANCELED
    Errata:
      State: NOT_STARTED
    Metadata:
      State: FINISHED

NOTE:

It is possible for tasks to complete or experience an error before the task cancellation request is processed. In these instances, the task's final state might not be "canceled" even though a cancel was requested.

Author

Pulp Team

Info

Sep 21, 2016 2.10 Pulp Project