[katello-devel] Agent Reporting Enabled Repositories

[Lukas Zapletal]

So we both agreed to take the approach Jeff outlined with few
exceptions:

- instead repo names the agent will send URLs of the repositories
- those URLs will have all variables replaced ($env, $arch...)
- the URLs will be used to retrieve repositories in pulp since there is
  not 1:1 mapping between pulp repos and products and using composed
  pulp_id (product_id-product_name-arch-variant) can change in future
- URLs seems to be more stable as Ivan proposed (and we like it)
- since repositories in pulp are immutable we are able to store URLs in
  the katello database (we already store repos there) to save few calls
  (this is optional - objections?)
- katello agent will use consumer certificate to authenticate
- standard bind/unbind calls will be used on the Pulp API side

LZ

On Wed, Jan 18, 2012 at 01:18:22PM -0600, Jeff Ortel wrote:
> I'm working on the pulp and katello agent parts of a solution for
> getting enabled repositories (as configured by rhsm) bound to
> consumers in pulp.  This is fairly straight forward and I think will
> go something like this:
> 
> 1. katello agent detects change in pulp.repo
> 
> 2. sends list of enabled repos to the server.
> 
> 3. katello query pulp consumer and performs a bind/unbind as needed.
> 
> Eg: (read like pseudo code)
> 
> # fetch consumer
> consumer = pulp.getConsumer(id)       # pulp REST
> already_bound = consumer['repoids']
> # newly disabled
> for repoid in already_bound:
>     if repoid not in reported:
>         pulp.unbind(id, repoid)       # pulp REST
>  # newly enabled
> for repoid in reported:
>     if repoid not in already_bound:
>     	pulp.bind(id, repoid)         # pulp REST
> 
> This does mean a bind/unbind per newly enabled or disabled repo.
> But, this approach leverages pulp's existing API and I really don't
> expect repos to be enabled/disabled in large quantities.  Though, I
> understand this may raise concern.  Also, the pulp v2
> RepoAssociation stuff will support bulk operations.
> 
> I assume the katello REST call will be something like this?
> 
> url: /bla/bla/consumer/<id>/repos/enabled
> payload:
>  [<repoid>,...]
> 
> Please let me know when the API is designed.
> 
> Comments?
> 
> Thanks,
> 
> Jeff
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel

-- 
Later,

 Lukas Zapletal | E32E400A
 RHN Satellite Engineering
 Red Hat Czech s.r.o. Brno