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) [r...@server]# pulp-admin repo create --id=repo1 ...
# From client.example.com:
2) [r...@client]# pulp-client consumer create --id=client.example.com
--server=server.example.com
# From server.example.com:
3) [r...@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
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
