Bug 1011257 - Re-registering a client to SAM 1.3 server created error
Re-registering a client to SAM 1.3 server created error
Status: CLOSED WONTFIX
Product: Subscription Asset Manager
Classification: Red Hat
Component: katello (Show other bugs)
Nightly
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Michael Stead
SAM QE List
:
Depends On:
Blocks: sam20-tracker
  Show dependency treegraph
 
Reported: 2013-09-23 18:56 EDT by sthirugn@redhat.com
Modified: 2017-06-26 16:33 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-26 16:33:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Error trying to re-register the client to SAM (136.95 KB, image/png)
2013-09-23 18:57 EDT, sthirugn@redhat.com
no flags Details
catalina.out error (59.12 KB, text/plain)
2013-09-23 18:58 EDT, sthirugn@redhat.com
no flags Details

  None (edit)
Comment 1 sthirugn@redhat.com 2013-09-23 18:57:14 EDT
Created attachment 801959 [details]
Error trying to re-register the client to SAM
Comment 2 sthirugn@redhat.com 2013-09-23 18:58:48 EDT
Created attachment 801960 [details]
catalina.out error
Comment 4 Michael Stead 2013-09-25 15:07:47 EDT
Looking for more information on how this issue came about.  I'll dig through the logs some more, but I was hoping that you may be able to remember.

What org was specified when the system was registered?

Was this error produced after clicking on the system in the SAM UI?

Was this a shared SAM instance. Looks like there were imports happening at the same time.
Comment 5 sthirugn@redhat.com 2013-09-25 15:59:02 EDT
(In reply to Michael Stead from comment #4)
> Looking for more information on how this issue came about.  I'll dig through
> the logs some more, but I was hoping that you may be able to remember.
> 

> What org was specified when the system was registered?
org name: CoresTest

> Was this error produced after clicking on the system in the SAM UI?
@omaciel and I were testing socket based scenarios.  He was unregistering/registering the client and I was watching the SAM UI and the error suddenly showed up in SAM UI.  The registration of the client seem to be successful though
 
> Was this a shared SAM instance. Looks like there were imports happening at the same time.
As I said above, omaciel and I were testing this.  This sam instance is not shared with anybody else.
Comment 6 Devan Goodwin 2013-09-26 10:14:47 EDT
Reproduced in dev environment. Based on the log we can see two threads trying to regenerate the same entitlement in close succession. (threads 1 and 4)

So what happened, a manifest was imported which updated some part of a subscription from a previous manifest. (most likely the attributes changes, or content was added/removed) Meanwhile a consumer on the same had subscribed between the two events. When the new manifest is imported, the consumer's entitlements are marked dirty so they will be regenerated the next time someone checks those certificates.

There are a number of API calls that can trigger the regeneration, it looks like in this case, two of them happened at the same time. One of those requests will (correctly) fail. It's probably more so a matter of how we handle the failure.



To reproduce for developers:

(dgoodwin@lenovo {master} ~/src/candlepin/buildconf/scripts) $ cat consumer-with-ents.rb 
#!/usr/bin/env ruby
#
# Script to create a valid candlepin export.zip which can then be imported
# for an owner. Creates everything necessary, starting with a fresh owner,
# admin user, candlepin consumer, products, subs, pools, and entitlements.
#
# None of the above will be cleaned up.

require  "../../client/ruby/candlepin_api"
require 'pp'

ADMIN_USERNAME = "admin"
ADMIN_PASSWORD = "admin"
HOST = "localhost"
PORT = 8443

def random_string prefix=nil
  prefix ||= "rand"
  return "#{prefix}-#{rand(100000)}"
end

cp = Candlepin.new(ADMIN_USERNAME, ADMIN_PASSWORD, nil, nil, HOST, PORT)

owner = cp.create_owner random_string("consumertest")
puts "Created owner: #{owner['key']}"

product1 = cp.create_product(random_string(), random_string(),
  {:attributes => {"multi-entitlement" => "yes"}})

end_date = Date.new(2025, 5, 29)
sub1 = cp.create_subscription(owner['key'], product1['id'], 2000, [], '', '12345', nil, nil, end_date)
cp.refresh_pools(owner['key'])

pool1 = cp.list_pools(:owner => owner['id'], :product => product1['id'])[0]

org_admin_username = random_string("orgadmin")
org_admin_password = 'password'
cp.create_user(org_admin_username, org_admin_password, true)
org_admin_cp = Candlepin.new(org_admin_username, org_admin_password)
consumer = org_admin_cp.register(random_string('dummyconsumer'), "candlepin",
  nil, {}, nil, owner['key'])
puts "Created consumer: id = #{consumer['id']}, uuid = #{consumer['uuid']}"
consumer_cp = Candlepin.new(nil, nil, consumer['idCert']['cert'], consumer['idCert']['key'],
  HOST, PORT)

ent_count = 100
puts "Grabbing #{ent_count} entitlements"
(0..ent_count).each do |i|
  consumer_cp.consume_pool(pool1['id'], {:quantity => 1})
end



This creates a consumer with 100 ents, which will take awhile to regenerate.

Then we go mark them dirty manually in the db to prevent mucking about with manifests, make sure to use the consumer *ID* printed above, not the UUID.

update cp_entitlement set dirty = 't' where consumer_id = '40288198415a8da701415a9589ed01fd';

Now on two separate command lines, get this command ready to go, this time we use *UUID* from output of script:

curl -k -u admin:admin -X GET "https://localhost:8443/candlepin/consumers/529a7ee5-bcaf-4349-b08e-4c1ad5a70eb0/certificates/serials"

Then go launch the command on one, then on the other. One of the two will fail with:

{
  "displayMessage" : "Runtime Error org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 at org.hibernate.jdbc.Expectations$BasicExpectation.checkBatched:85"
}%
Comment 7 Devan Goodwin 2013-09-26 11:51:13 EDT
I do not believe this issue is a blocker.

The situation is very strange, it's not an easy bug to hit. You need to get dirty entitlements, which means a manifest import, then consumption in SAM, then a change to the product data on RH side, and a re-import.

The error happening is technically what should happen, if two transactions try to do the same thing, one of them has to fail to prevent bad data from being committed, which is what is happening here.

I do not believe this is a regression either, this problem would be possible going a long ways back.

No damage is done, and a re-try of the request is perfectly safe and will work.

We will work on getting better error message out of this or preventing it, but not a blocker IMO.
Comment 8 sthirugn@redhat.com 2013-09-26 13:28:06 EDT
Proposing SAM 1.4 as per Comment 7 above
Comment 9 Bryan Kearney 2017-06-26 16:33:06 EDT
The release of Satellite 5.8 we are deprecating the support of Subscription Asset Manager. The release notes for 5.8 can be found at https://access.redhat.com/documentation/en-us/red_hat_satellite/5.8/pdf/release_notes/Red_Hat_Satellite-5.8-Release_Notes-en-US.pdf.

I am therefore closing out this bug as WONTFIX. If you believe this to be an error, please feel free tor each out to either Rich Jerrido or Bryan Kearney. Thank you!

Note You need to log in before you can comment on or make changes to this bug.