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

[Pulp-list] admin operations on consumers

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.


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

# From server.example.com:

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

# From client.example.com:

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

# From server.example.com:

3) [root 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")
        self.cconn.bind(consumerid, self.options.repoid)

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.


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