This one was my fault. Lemme explain my thinking:
If this is just for RedHat providers, then I think that the manifest
should have it embedded or it should be coded in the app (config file).
Now.. should we support using the same Provider type for upstream
candlepins? If so, that negates the idea of the config file.. but may
be that we add it into the maniest.

If the katello-instance that you can sync from is equal to the same
instance that created the manifest, then absolutely I would move to
embedding this data in the manifest vs the UI or config file.
-Todd

OK... I will get this on the Candlepin backlog. As for the second
question. Do we want to support the following:
1) a Tenant either gets Red Hat Subscriptions from an upstream
candlepin, or Red Hat. This means there is only on Red Hat provider
per tenant.
-- bk

I think that's right. Tenants are limited to a single RH provider. I
can't think of a case where a tenant would want to get RH content from
multiple locations.

ok.. but the red hat provider will be for Red Hat _or_ upstream candlepin?

We will need to specify the %env tag within the content set urls when
creating a manifest on an upstream katello/candlepin, so that the
downstream created RH provider will pull content from the correct
environment (i.e. production).

Currenlty conent out of katello should be prepended with
/{OWNER_ID}/$env where OWNER_D is actually filled in.