[katello-devel] [pulp-internal] Package Profile Capture Design Doc

[Bryan Kearney]

Lemme throw out a couple of things:

1) The interaction is really between rhsm and pulp, katello is a bit of 
a side effect.

2) You mention these 2 featues:

# Package profile Module (for rpms, jars etc)
# Certificate Bundle (to read/write certificates from /etc/pki/consumer)

but later talk about gofer.

Let me suggest this.

1) Since this is rhsm/pulp interaction.. can we merge this into 
python-rhsm? That package is already in fedora and RHEL, so it will ease 
the transition.

2) If we augment the low level API, candlepin may need to handle a 
"No-op" method of receiving the package set of discarding it. If we make 
it an extension point, then IT or SAM could leverage this later.

3) I think the package should be limited to yum plugins and a daemon not 
tied to gofer. This will make it easy to get into RHEL. The gofer stuff 
can be more command and control, and can use the same library code.

Thoughts?

-- bk





On 05/26/2011 10:39 AM, Todd B Sanders wrote:
> On 05/26/2011 10:34 AM, Pradeep Kilambi wrote:
>> On 05/26/2011 10:27 AM, jesus m. rodriguez wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 05/26/2011 10:22 AM, Pradeep Kilambi wrote:
>>>> On 05/26/2011 10:05 AM, Todd B Sanders wrote:
>>>>> On 05/26/2011 10:00 AM, Pradeep Kilambi wrote:
>>>>>> On 05/26/2011 09:55 AM, jesus m. rodriguez wrote:
>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>> Hash: SHA1
>>>>>>>
>>>>>>> On 05/25/2011 01:40 PM, Pradeep Kilambi wrote:
>>>>>>>> Here is the design/spec document for package profile capture story.
>>>>>>>> This
>>>>>>>> will impact both Pulp and Katello.
>>>>>>>>
>>>>>>>> https://fedorahosted.org/pulp/wiki/PackageProfileUpdate
>>>>>>>>
>>>>>>>> Please lemme know if you guys have further thoughts.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> ~ Prad
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> katello-devel mailing list
>>>>>>>> katello-devel at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>>>>>> Instead of pulp-client-utils how about calling it Mache.
>>>>>>> As in Paper Mache which is made from wood pulp.
>>>>>>> And you can build things with paper mache.
>>>>>>>
>>>>>>> http://en.wikipedia.org/wiki/Papier-m%C3%A2ch%C3%A9
>>>>>>>
>>>>>>> Just my 2 pesos.
>>>>>>>
>>>>>>> jesus
>>>>>> Hehe cool name. Todd what do you think? I'll be filing for a project
>>>>>> hosting request today. If we can agree on the name, I'll go ahead
>>>>>> with filing the ticket.
>>>>>>
>>>>>> ~ Prad
>>>>>>
>>>>>> _______________________________________________
>>>>>> katello-devel mailing list
>>>>>> katello-devel at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>>>> What am I missing? Why a separate project for this? .....as this is
>>>>> just part of the pulp client-side tooling. The reason we are pulling
>>>>> into a separate rpm is so that is can more easily be leveraged by
>>>>> additional clients (i.e. RHSM).
>>>>>
>>>>> -Todd
>>>>>
>>>>> -Todd
>>>> We can use it under same pulp project. Since this is a separate tool
>>>> shared between katello, pulp and RHSM and need to get into brew at some
>>>> point for RHEL, I was thinking it would be easier if its not tied up
>>>> with pulp itself. This is a package pulp, ketello/rhsm will require. So
>>>> might have a case where we want newer builds for this package
>>>> outside of
>>>> pulp itself ?
>>>>
>>>> ~ Prad
>>> You have a couple options:
>>>
>>> 1) keep it in the same tree as pulp following the pulp release cycle
>>>
>>> 2) put it as separate git repo on fedora but link to it from the
>>> pulp wiki and mailing list. That's what we did with Thumbslug and
>>> Headpin. They are their own repos but linked from the Candelpin wiki.
>>>
>>> This way you get to have a clean repo people can contribute to and
>>> maintain it on a separate release schedule if needed.
>>>
>>> jesus
>>
>> Option-2 makes sense to me. I dont think we should bind the release
>> cycle of a shared library package with pulp itself.
>
> Ah. I read the original email as separate "Project", which I am *not* in
> favor of. Using a separate repo (i.e. grinder), linked to the existing
> Pulp project makes sense.
>
> -Todd
>>
>> ~ Prad
>>
>>> - -- jesus m. rodriguez | jesusr at redhat.com
>>> principal software engineer | irc: zeus
>>> red hat systems management | 919.754.4413 (w)
>>> rhce # 805008586930012 | 919.623.0080 (c)
>>> +---------------------------------------------+
>>> | "Those who cannot remember the past |
>>> | are condemned to repeat it." |
>>> | -- George Santayana |
>>> +---------------------------------------------+
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>>>
>>> iEYEARECAAYFAk3eY0YACgkQvJZ57YntiYOe4wCgw14/kT1bAZJA3SES5nqv6Lrd
>>> QlMAoIQQ0Q3+3VZE0Qeq+CwDkLFBZrgw
>>> =AWbH
>>> -----END PGP SIGNATURE-----
>>
>