Content Applicability

Generate Content Applicability for Updated Consumers

This API regenerates applicability data for a given set of consumers matched by a given Search Criteria asynchronously and saves it in the Pulp database. It should be used when a consumer profile is updated or consumer-repository bindings are updated. Applicability data is regenerated for all unit profiles associated with given consumers and for all content types that define applicability. Generated applicability data can be queried using the Query Content Applicability API described below.

The API will return a Call Report. Users can check whether the applicability generation is completed using task id in the Call Report. You can run a single applicability generation task at a time. If an applicability generation task is running, any new applicability generation tasks requested are queued and postponed until the current task is completed.

Method: POST
Path: /pulp/api/v2/consumers/actions/content/regenerate_applicability/
Permission: create
Request Body Contents:
  • consumer_criteria (object) - a consumer criteria object defined in Search Criteria
Response Codes:
  • 202 - if applicability regeneration is queued successfully
  • 400 - if one or more of the parameters is invalid
:return:a Call Report representing the current state of the applicability regeneration

Sample Request:

{
 "consumer_criteria": {
  "filters": {"id": {"$in": ["sunflower", "voyager"]}}
 }
}

Tags: The task created will have the following tag: "pulp:action:content_applicability_regeneration"

Generate Content Applicability for Updated Repositories

This API regenerates applicability data for a given set of repositories matched by a given Search Criteria asynchronously and saves it in the Pulp database. It should be used when a repository’s content is updated. Only existing applicability data is regenerated for given repositories. If applicability data for a consumer-repository combination does not already exist, it should be generated using the API Generate Content Applicability for Updated Consumers.

If any new content types that support applicability are added to the given repositories, applicability data is generated for them as well. Generated applicability data can be queried using the Query Content Applicability API described below.

There are two ways to regenerate applicability for consumers bound to a set of repositories. The computation can be done linearly or in parallel. The default is linear, but an optional parallel argument can enable parallel calculation.

When computing applicability linearly, the API will return a Call Report when parallel is False or not present. In this case, users can check whether the applicability generation is completed using task id in the Call Report. You can run a single applicability generation task at a time. If an applicability generation task is running, any new applicability generation tasks requested are queued and postponed until the current task is completed.

When computing applicability in parallel, the API will return a Group Call Report. Users can check whether the applicability generation is completed using group id field in the Group Call Report. The _href in the Group Call Report will point to the root of task_group resource which currently returns 404 in all cases. Append ‘/state-summary/’ to the URL and perform a GET request to retrieve the Cancelling Tasks in a Task Group.

Method: POST
Path: /pulp/api/v2/repositories/actions/content/regenerate_applicability/
Permission: create
Request Body Contents:
  • repo_criteria (object) - a repository criteria object defined in Search Criteria

  • parallel (boolean) - a boolean to specify whether the task should be executed in parallel as

    a task group. When False, calculation is performed as a single long running task. Defaults to False. (optional)

Response Codes:
  • 202 - if applicability regeneration is queued successfully
  • 400 - if one or more of the parameters is invalid
Return: when ``parallel` is False or not present a Call Report
Return: when ``parallel` is True a Group Call Report representing the current state of the applicability regeneration

Sample Request:

{
 "repo_criteria": {
  "filters": {"id": {"$in": ["test-repo", "test-errata"]}},
  "parallel": true
 }
}

Sample 202 Response Body:

{
    "_href": "/pulp/api/v2/task_groups/16412fcb-06fa-4caa-818b-b103e2a9bf44/",
   "group_id": "16412fcb-06fa-4caa-818b-b103e2a9bf44"
}

Generate Content Applicability for a single Consumer

This API regenerates applicability data for the given consumer asynchronously and saves it in the Pulp database. It can be used by a consumer when its profile is updated or its consumer-repository bindings are updated. Applicability data is regenerated for all unit profiles associated with te given consumer and for all content types that define applicability. Generated applicability data can be queried using the Query Content Applicability API described above.

The API will return a Call Report. If an applicability generation task is running for a given consumer, any new applicability generation tasks requested are queued and postponed until the current task is completed.

Method: POST
Path: /pulp/api/v2/consumers/<consumer_id>/actions/content/regenerate_applicability/
Permission: create
Request Body Contents:
Response Codes:
  • 202 - if applicability regeneration is queued successfully
  • 404 - if a consumer with given consumer_id does not exist
:return: a Call Report representing the current state of the applicability regeneration

Tags: The task created will have the following tag: "pulp:action:consumer_content_applicability_regeneration"

Query Content Applicability

This method queries Pulp for the applicability data that applies to a set of consumers matched by a given Search Criteria. The API user may also optionally specify an array of content types to which they wish to limit the applicability data.

Note

The criteria is used by this API to select the consumers for which Pulp needs to find applicability data. The sort option can be used in conjunction with limit and skip for pagination, but the sort option will not influence the ordering of the returned applicability reports since the consumers are collated together.

The applicability API will return an array of objects in its response. Each object will contain two keys, consumers and applicability. consumers will index an array of consumer ids. These grouped consumer ids will allow Pulp to collate consumers that have the same applicability together. applicability will index an object. The applicability object will contain content types as keys, and each content type will index an array of unit ids.

Each applicability report is an object:
  • consumers - array of consumer ids

  • applicability - object with content types as keys, each indexing an

    array of applicable unit ids

Method: POST
Path: /pulp/api/v2/consumers/content/applicability/
Permission: read
Request Body Contents:
  • criteria (object) - a consumer criteria object defined in Search Criteria
  • content_types (array) - an array of content types that the caller wishes to limit the applicability report to (optional)
Response Codes:
  • 200 - if the applicability query was performed successfully
  • 400 - if one or more of the parameters is invalid
Return: an array of applicability reports

Sample Request:

{
 "criteria": {
  "filters": {"id": {"$in": ["sunflower", "voyager"]}}
 },
 "content_types": ["type_1", "type_2"]
}

Sample 200 Response Body:

[
   {
       "consumers": ["sunflower"],
       "applicability": {"type_1": ["unit_1_id", "unit_2_id"]}
   },
   {
       "consumers": ["sunflower", "voyager"],
       "applicability": {"type_1": ["unit_3_id"], "type_2": ["unit_4_id"]}
   }
]