[Pulp-list] admin operations on consumers

[Mike McCune]

I had a bug where we got an authorization failure when trying to bind a 
consumer to a repo as an *admin* on a different machine from the 
consumer itself.

Setup:

* client.example.com (consumer)
* server.example.com (pulp server)

# From server.example.com:

1) [root at server]# pulp-admin repo create --id=repo1 ...

# From client.example.com:

2) [root at client]# pulp-client consumer create --id=client.example.com 
--server=server.example.com

# From server.example.com:

3) [root at server]# pulp-admin consumer bind --repoid=repo1 
--id=client.example.com

When we hit step 3) the CLI code ends up down in core_consumer.py:_bind():

def _bind(self):
     consumerid = self.getConsumer()
     if not self.options.repoid:
         print _("repo id required. Try --help")
         sys.exit(0)
     try:
         self.cconn.bind(consumerid, self.options.repoid)
         self.repolib.update()

if you look at this code you will realize it really only makes sense if 
pulp-client is executing it.  when being executed from pulp-admin we try 
to do a repolib.update() which tries to upload a package profile from 
the box that pulp-admin is running (the server) and fails because the 
*server* is not a consumer.

Do we have an existing pattern or solution to get the client code to 
correctly handle different code paths when being executed from 
pulp-admin vs pulp-client?

My first thought is that any pulp-admin operations on consumers should 
be remotely instructing the client to take actions instead of operating 
on the server side.  If we conditionally take out the 'repolib.update()' 
call if we are executing from pulp-admin the client will still never get 
its package profile updated or the local yum.conf.d files updated.

This same problem exists for create and update, and unbind.

Mike