Bug #9883

Updating client content view fails when client is registered to capsule

Added by Justin Sherrill almost 8 years ago. Updated over 4 years ago.

Target version:
Bugzilla link:
Fixed in Releases:
Found in Releases:
Red Hat JIRA:


Cloned from
Description of problem:
Updating a client's content view fails when the client is registered to a capsule.

Version-Release number of selected component (if applicable):

Tested against:

  • A satellite running Satellite-6.1.0-RHEL-7-20150317.0
  • A capsule running RHEL 7.1
  • Clients running RHEL 5.11, 6.6 and 7.1.

The RHEL 5.11 and 7.1 clients are affected, but the RHEL 6.6 client was not affected.

How reproducible:

Steps to Reproduce:
1. Set up a satellite and capsule.
2. Register clients to the capsule with the usual commands:

1. rpm -Uvh
2. subscription-manager register --org="Default_Organization" --environment="Library"
3. (not sure if required) subscription-manager attach --pool …

3. Create a content view and make it available to the clients. (Following the xample above, it should be in the Library lifecycle environment and the Default Organization organization.)
4. Log in to the satellite web UI. Go to Hosts → Content Hosts. Select a host, and change the "content view" field.

Actual results:
The task fails. The failed task is "Actions::Candlepin::Consumer::Update". The most interesting line from the exception is "caused by: (RestClient::BadRequest) Katello::Resources::Candlepin::Consumer: 400 Bad Request {"displayMessage":"Problem updating unit Consumer [id = null, type = null, getName() = null]","requestUuid":"a1a2b811-4ef2-4a0c-91eb-c7bd274b9d3f"} (PUT /candlepin/consumers/ddc94272-eb37-40ab-8d36-1d4380875f9f)".

Expected results:
The task succeeds.

Additional info:
No firewall was running on the capsule or clients when this bug was noticed. It is unknown if the presence of a firewall affects how hard it is to reproduce this bug.

Associated revisions

Revision a6ca904f (diff)
Added by Justin Sherrill almost 8 years ago

fixes #9883 - making auto attach run after consumer update

dynflow uses concurrent by default, which is not really what we want here

Revision aeeb2c99
Added by Mike McCune almost 8 years ago

Merge pull request #5134 from jlsherrill/9883

fixes #9883 - making auto attach run after consumer update


#1 Updated by The Foreman Bot almost 8 years ago

  • Status changed from New to Ready For Testing
  • Target version set to 68
  • Pull request added
  • Pull request deleted ()

#2 Updated by Justin Sherrill almost 8 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100

#3 Updated by Eric Helms almost 8 years ago

  • Category set to Client/Agent
  • Legacy Backlogs Release (now unused) set to 23
  • Triaged changed from No to Yes

Also available in: Atom PDF