Manifest Consumer Association Design

Katello neesds the ability to associate a given manifest with the distributor (consumer). The following information needs to be accessible.

• consumer uuid
• consumer id cert pub/priv pair
• a url fragment that can have the uuid appended to it to link to the system in a webui
• a url fragment that can be used to do candlepin API communication
• probably the consumer name, too?

Model

  public class UpstreamConsumer extends AbstractHibernateObject {
    private String id;
    private String uuid;
    private String name;
    private Owner owner;
    private ConsumerType type;
    private IdentityCertificate idCert;    
  }

Database

The above information needs to be stored somewhere. The existing cp_consumer table is for consumers registered to Candlepin that can be enititled. While it contains much of the information we need to store, storing this information in that table would cause confusion. A new table is proposed to store the above information: cp_upstream_consumer. The cp_owner upstream_uuid will be removed in favor of using a mapping table to allow a many-to-many relationship between owner and upstream consumers.

cp_upstream_consumer

NEW

cp_owner

MODIFIED

API

A new API will be created to access the information about the upstream consumer.

Export process

We will add an upstream_consumer directory to the consumer_export.zip containing the upstream_consumer in JSON format as well as its identity certificate. The json file will be named using the consumer’s uuid with the .json extension. The identity certificate will be named with the identity certificates id and the .pem extension.

export
└── upstream_consumer
    ├── 6e6b0328-ab72-42b6-8963-19d8d5b2ebdb.json # upstream consumer json
    └── 3009001513844743756.pem # identity certificate

Import process

Processing of the upstream_consumer directory will be added to the existing import process. At this time we will create a new record in the cp_upstream_consumer to hold the information contained in the upstream_consumer_uuid.json file. We will maintain the same information EXCEPT the database id which will be regenerated by the server upon storing the record. The upstream_uuid on cp_owner will then point to the record in cp_upstream_consumer.

Issues

• will we support multiple manifests PER owner? If yes, then we’ll need to change the cp_owner -> cp_upstream_consumer relationship to be one-to-many right now it is one-to-one.
• the mapping should be 1 to many, not many to many. (jbowes)
• I don’t think we need to build the 1 to N mapping into the db yet, but just expose it that way in our api. (jbowes)
• the upstream_consumer table is missing fields for the url fragments. (jbowes)

Notes from meeting

upgrade

The existing cp_owner table has a upstream_uuid (VARCHAR(255)) column. We need to migrate that to be an upstream_id (VARCHAR(32)) foreign key to the new cp_upstream_consumer table.

A couple of ways to get the upstream consumer created:

• have the user reimport their manifest
• create a new import/consumer api that accepts a manifest but ONLY reads the consumer.json bits
• might be able to create MOST of the upstream consumer with the information from the cp_import_record table.
  • we can use the id of the import_record as the id of the upstream_consumer so that we can do this without hibernate from liquibase

DO WE NEED A HISTORICAL RECORD IN IMPORT_RECORD of the upstream consumer? i.e. web url, etc.

tasks

• need to add liquibase code to read cp_import_record to populate cp_upstream_consumer table
• need to remove duplicate fields i.e. cp_web_prefix from cp_import_record if no historical values are needed.