In:
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 perspective.
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.
},
}
On 01/17/2012 02:36 PM, Jay Dobies wrote:
https://fedorahosted.org/pulp/wiki/GCConsumers
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
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
