[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-list] Consumers v2.0 Design & Requirements

On 01/20/2012 08:15 AM, Bryan Kearney wrote:
Some things I would like to see Pulp be able to mirror:

- Puppet Modules (hook up with Ohad)
- SCAP Stuff live CVE's (http://www.redhat.com/security/data/cve/)
- Deb files

All being taken into account. The idea is that the message from Pulp -> consumer will contain any information relevant to installation of these. The way I want to implement the v2.0 version of the consumer is that there will be plugins that will field those messages based on type and do the appropriate install steps. So the consumer will basically be a big switch that says "For type RPM, call this code that calls yum. For type DEB, call this code that calls apt".

It's a good idea though to add these examples to that design page to give some context as to the end goal of all of it. I'll put in a section soon.

-- bk

On 01/18/2012 01:06 PM, Jay Dobies wrote:
On 01/18/2012 12:07 PM, Jeff Ortel wrote:

register(id, description, tags, supports_bus=True)

I think the 'support_bus' needs to be broken down into a dictionary that
defines the consumer's (agent) capabilities from the pulp server's

Here are some examples. We could prefix all of the attributes with
'supports_' but that seemed redundant.

Pulp consumers:

heartbeat : True, # supports heartbeat
content :
types : [RPM,], # supported content types
bind : False, # supports bind/unbind RMI, pulp managed

Katello consumers:

heartbeat : False, # heartbeat not supported
content :
types : [RPM,..], # supported content types
bind : True|False, # bind/unbind RMI not supported, RHSM managed.

This is a good call. I meant to have the consumer indicate to Pulp what
types it will support but totally forgot to add it. I'll make the change
in a bit.

On 01/17/2012 02:36 PM, Jay Dobies wrote:

That wiki is still very much a work in progress, but I figured I'd
throw it out there now
in case people wanted to take a look.

I started with the requirements of what Pulp should be able to do with
consumers. It
should be extremely close to what we do today without much extra added
in, but let me know
if I'm missing anything.

I also added some ideas for the APIs and responsibility of the
profiler plugins. At the
bottom I started on the calls through the system and have a few more
diagrams to add.

Pulp-list mailing list
Pulp-list redhat com

Jay Dobies
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]