Bug 848872
| Summary: | subscription-manager autosubscribe with --servicelevel does not ALWAYS persist the serviceLevel onto the consumer | ||
|---|---|---|---|
| Product: | [Community] Candlepin | Reporter: | John Sefler <jsefler> |
| Component: | candlepin | Assignee: | Devan Goodwin <dgoodwin> |
| Status: | CLOSED WONTFIX | QA Contact: | Katello QA List <katello-qa-list> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | low | ||
| Version: | 0.9 | CC: | alikins, bkearney, dgoodwin, jsefler |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-11-22 17:07:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 863175 | ||
|
Description
John Sefler
2012-08-16 16:03:16 UTC
I have a thought on a potential cause... I see in catalina.out these two back-to-back update consumer transactions which occur at the start of the autosubscribe... Aug 16 02:30:02 [http-8443-2] INFO org.candlepin.resource.ConsumerResource - Consumer cbfc3d18-c9d0-448b-9401-92df9c914e6c updated. Aug 16 02:30:03 [http-8443-2] INFO org.candlepin.resource.ConsumerResource - Consumer cbfc3d18-c9d0-448b-9401-92df9c914e6c updated. Is it possible that a "chatty fact" (ref bug 838123) could be the cause for one of the consumer updates and the new serviceLevel specified for autosubscribe the cause for the other consumer update. Then if the updates are performed asynchronously, maybe the consumer update with the new serviceLevel attribute is getting clobbered by the other update (which has the former service level). Just a thought. John could you verify something for me, in your testing for each of the steps you take, do you block and wait for the requests to return, or do you ever fire off requests to say update autoheal or subscribe without waiting for a past command to complete? I think your theory is probably quite likely to be correct. I don't see how it could be happening in subscription-manager though, as far as I know we would always wait for the update consumer to complete (when updating facts for example) before proceeding to the next step. The only possibility would perhaps be if rhsmcertd happened to run at exactly the same time. Out of curiosity, what interval do you have the rhsmcertd set to in this environment? I'm going to do a quick test with a big sleep in update consumer, firing off a facts update and then a set service level, almost surely this can cause what you are seeing. We will probably defer to 6.4 though as this would be a candlepin server side fix. Successfully reproduced with a 10 second sleep in update consumer server side call, forcing facts to change, and firing off first a "set SLA" request, then an update facts request before the first one can finish. The second request loads a representation of the consumer before the first one has committed, so the SLA is the old one, both requests complete, but the second one overwrites the first, and SLA remains the same. My guess is either the test suite is firing off requests and not blocking waiting for a response, or rhsmcertd is running very frequently and happens to hit during an update consumer. John: debug logging might provide a little more info in terms of "facts changed" and what not if that is an option. (if you'd like to enable it and wait for it to happe nagain) I don't think there's anything to be fixed client side here (we can't block across rhsmcertd and the app itself, at least not easily), so we would have to use database locking on the consumer server side, similar to how we lock on pools. If the above theory is correct, the odds of setting an SLA while rhsmcertd running seem fairly low so probably not a high priority fix here. Pushing to 6.4. John, are you still seeing this? I am tempted to close/wontfix. I have not seen this error in awhile. Let's close this issue for now. |