Bug 871886

Summary: Manifest Import Error With Content IDs Changing Upstream
Product: Red Hat Satellite Reporter: Devan Goodwin <dgoodwin>
Component: Subscription ManagementAssignee: Devan Goodwin <dgoodwin>
Status: CLOSED CANTFIX QA Contact: Katello QA List <katello-qa-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: NightlyCC: dgregor, mitch, tcarlin, tomckay, xdmoon
Target Milestone: UnspecifiedKeywords: Reopened
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-20 16:16:23 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: 816564    

Description Devan Goodwin 2012-10-31 16:11:20 UTC
Description of problem:

Manifest imports can fail when content IDs have changed upstream.

This is very similar to bug #807468 where we were relying on content labels, which turned out to change sometimes, so we switched to content ID as the definitive way to check if the content already exists on the server.

How reproducible:

Difficult, need a manifest with an old product ID and a content label, then a newer manifest with the same label but a different ID.

Saw this with:


11:17am <dgoodwin> thomasmckay: ok this looks to be because rel-eng changed the content id for rhel-5-server-rhev-agent-rpms
11:17am <dgoodwin> from 1105 which you have in your db from an old manifest
11:17am <dgoodwin> to 1687


The error will surface like so in catalina.out:

Oct 31 10:27:59 [http-8443-1] DEBUG org.candlepin.sync.Importer - Import product: RH0100931.json
Oct 31 10:27:59 [http-8443-1] DEBUG org.candlepin.sync.Importer - Import product: RH0197181.json
Oct 31 10:27:59 [http-8443-1] DEBUG org.candlepin.sync.Importer - Import product: RH0149709.json
Oct 31 10:27:59 [http-8443-1] DEBUG org.candlepin.sync.Importer - Import product: 180.json
Oct 31 10:27:59 [http-8443-1] DEBUG org.candlepin.sync.Importer - Import product: RH0197181F3.json
Oct 31 10:27:59 [http-8443-1] DEBUG org.candlepin.sync.Importer - Import product: 69.json
Oct 31 10:27:59 [http-8443-1] DEBUG org.candlepin.sync.Importer - Import product: RH0101594.json
Oct 31 10:27:59 [http-8443-1] WARN  org.hibernate.util.JDBCExceptionReporter - SQL Error: 0, SQLState: 23505
Oct 31 10:27:59 [http-8443-1] ERROR org.hibernate.util.JDBCExceptionReporter - Batch entry 0 insert into cp_content (created, updated, contentUrl, gpgUrl, label, metadataExpire, name, releaseVer, requiredTags, type, vendor, id) values ('2012-10-31 10:27:59.424000 -04:00:00', '2012-10-31 10:27:59.424000 -04:00:00', '/content/dist/rhel/server/5/$releasever/$basearch/rhev-agent/3/os', 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release', 'rhel-5-server-rhev-agent-rpms', '86400', 'Red Hat Enterprise Virtualization Agents for RHEL 5 Server (RPMs)', NULL, 'rhel-5-server', 'yum', 'Red Hat', '1687') was aborted.  Call getNextException to see the cause.
Oct 31 10:27:59 [http-8443-1] WARN  org.hibernate.util.JDBCExceptionReporter - SQL Error: 0, SQLState: 23505
Oct 31 10:27:59 [http-8443-1] ERROR org.hibernate.util.JDBCExceptionReporter - ERROR: duplicate key value violates unique constraint "cp_content_label_key"
Oct 31 10:27:59 [http-8443-1] ERROR org.hibernate.event.def.AbstractFlushingEventListener - Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update




We are unclear how to fix at this time. If rel-eng can prevent the content IDs from ever changing we will be ok.

If not we have to figure out what to do in Candlepin. Some possibilities:

1. Remove the label uniqueness contraint, let the content go in with the new ID. Products will be pointing at that new ID anyhow. Content could get orphaned but that's easy to detect and clean up as well.

2. Treat content like product attributes, all products get their own copy of content. Lot of things to consider here like upgrade scenarios, promotion of content to environments (which is by ID and expected to trigger for all products using that content, there could be many)


Need to proceed carefully in any case.

Comment 3 Devan Goodwin 2012-11-07 15:48:57 UTC
We investigated a number of options to try to handle this but given how content is treated globally, and we support multi-tenant deployments, having a content set ID come in with the same label as another is not something we can reliably handle. Issues can arise where one org would import, leaving another org with entitlements which reference both the old and the new content definition, with non-deterministic behavior when those entitlements go out to clients.

This issue should not happen again upstream so we're hopeful it has not slipped out into any deployments.