Package profiles

[Bryan Kearney]

Take a look at this write up:

https://fedorahosted.org/pulp/wiki/PackageProfileUpdate

Based on this work which pradeep did, I believe there will be the 
following packages:

python-rhsm                      gofer
|---pulp-client--------------------|
|---subscription-manager           |
|------katello-C&C-----------------|

and the following features will need to be added across the projects:

- python rhsm will get he code to create the package sets.
- pulp-client will have code to take it and push it to pulp via a plugin 
and gofer plugin
- subscription-manager will push up packages whenever facts are pushed up
- candlepin will either need to store, or ignore that packeg profile.
- katello-C&C will re-implement the package set push which is in 
pulp-client. The main difference will be using the connection data from 
subscription-manager

Any comments on what you think candlepin should do?

-- bk

[Adrian Likins]

On 06/06/2011 10:16 AM, Bryan Kearney wrote:
> Take a look at this write up:
>
> https://fedorahosted.org/pulp/wiki/PackageProfileUpdate
>
> Based on this work which pradeep did, I believe there will be the
> following packages:
>
> python-rhsm                      gofer
> |---pulp-client--------------------|
> |---subscription-manager           |
> |------katello-C&C-----------------|
>
> and the following features will need to be added across the projects:
> python rhsm will get he code to create the package sets.

python-rhsm does not seem like the right place to have
package info gathering bits. As far as I'm concerned, it
already has too much stuff in it.

Maybe another package with core bits, assuming we actually
reuse them.
> pulp-client will have code to take it and push it to pulp via a plugin
>
> and gofer plugin
> subscription-manager will push up packages whenever facts are pushed up
> candlepin will either need to store, or ignore that packeg profile.
> katello-C&C will re-implement the package set push which is in
>
> pulp-client. The main difference will be using the connection data from
> subscription-manager
>
> Any comments on what you think candlepin should do?

package profiles are kind of brutal db wise. If we can
avoid having it in candlepin, I would much prefer that

Adrian

[Bryan Kearney]

On 06/06/2011 10:24 AM, Adrian Likins wrote:
> On 06/06/2011 10:16 AM, Bryan Kearney wrote:
> > Take a look at this write up:
> >
> > https://fedorahosted.org/pulp/wiki/PackageProfileUpdate
> >
> > Based on this work which pradeep did, I believe there will be the
> > following packages:
> >
> > python-rhsm gofer
> > |---pulp-client--------------------|
> > |---subscription-manager |
> > |------katello-C&C-----------------|
> >
> > and the following features will need to be added across the projects:
> > python rhsm will get he code to create the package sets.
>
> python-rhsm does not seem like the right place to have
> package info gathering bits. As far as I'm concerned, it
> already has too much stuff in it.
>
> Maybe another package with core bits, assuming we actually
> reuse them.

The goal is to re-use them. The original idea from Pradeep was to have a 
package which did cert reading and package collection. Today, 
python-rhsm does cert reading and basic candlepin connections.
> > pulp-client will have code to take it and push it to pulp via a plugin
> >
> > and gofer plugin
> > subscription-manager will push up packages whenever facts are pushed up
> > candlepin will either need to store, or ignore that packeg profile.
> > katello-C&C will re-implement the package set push which is in
> >
> > pulp-client. The main difference will be using the connection data from
> > subscription-manager
> >
> > Any comments on what you think candlepin should do?
>
> package profiles are kind of brutal db wise. If we can
> avoid having it in candlepin, I would much prefer that

I am fine with a no-op in the CP side, or making rhsm not send it up if 
there is no /foo/ resource.