Bug 769644 - Manifest import date check seems to ignore org scoping
Summary: Manifest import date check seems to ignore org scoping
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Subscription Asset Manager
Classification: Retired
Component: candlepin
Version: 1.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 1.0
Assignee: Devan Goodwin
QA Contact: SAM QE List
URL:
Whiteboard:
Depends On:
Blocks: 703617 772200
TreeView+ depends on / blocked
 
Reported: 2011-12-21 15:19 UTC by Bryan Kearney
Modified: 2012-04-27 00:21 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-27 00:21:48 UTC


Attachments (Terms of Use)

Description Bryan Kearney 2011-12-21 15:19:07 UTC
Using the manifests from the system-engin repo.

1) Do a clean install of headpin.
2) Create a second org.
3) Into one org, upload the manifest stageSamTestSimple20Nov2011.zip
4) Into the other org, upload stageSamTest20Nov2011.zip

Note the manifest in 4 is older, but it should not count since the import is into different orgs.

Comment 1 Devan Goodwin 2011-12-21 15:36:14 UTC
Looks like it's Candlepin throwing up this error. Investigating.

Comment 2 Devan Goodwin 2011-12-21 17:42:04 UTC
We do two metadata checks on an import, one for "system level elements", and one for "per user elements". The system level elements is the one that's failing here. Example database table contents:

candlepin=> select * from cp_export_metadata ;
                id                |         created         |         updated         |        exported         |   type   |             owner_id             
----------------------------------+-------------------------+-------------------------+-------------------------+----------+----------------------------------
 ff808081344225f20134425a16c2000a | 2011-12-15 11:32:07.489 | 2011-12-15 11:32:49.112 | 2011-12-15 11:32:48.567 | per_user | ff808081344225f20134423fa11c0003
 ff808081344225f20134425a16a00007 | 2011-12-15 11:32:07.456 | 2011-12-21 11:33:18.759 | 2011-12-21 11:33:18.736 | system   | 
 ff808081346139640134614155380006 | 2011-12-21 11:33:18.776 | 2011-12-21 11:33:18.776 | 2011-12-21 11:25:04.16  | per_user | ff808081346139640134613e50970001
(3 rows)

The system row is not bound to a user, it's just one row that forces only newer manifests to go in across the org. Presumably this is to prevent the contents of the rules table from hopping around with newer/older versions of the rules file.

Still investigating.

Comment 3 Devan Goodwin 2011-12-21 19:45:58 UTC
I believe this was done intentionally to protect from rules and product definitions jumping around depending on who imported last. 

Rules import is currently disabled and being discussed what we should do about it. 

If we're ok with product data potentially jumping around depending on who imported last, I will remove the system-wide check entirely.

Will check with jbowes when he's back from holiday as he might know more about what we could do.

Comment 6 Devan Goodwin 2011-12-22 15:56:29 UTC
Candlepin.git master: a5edb68af1a68c0f75c118ae03189133172318e9

Comment 7 Devan Goodwin 2012-01-03 16:07:52 UTC
Spoke with jbowes, skipping old rules is already planned in solution for bug #743968.

We should probably pursue a similar solution for Products but this is going to be tricky. When you consider that products may/may not be in a particular org's manifest, manifests can be generated but not imported until later, and the order in which org's import their manifests, it sounds like we need to:

- Somehow store the meta.json "created" field on each product in the database. Ideally we'd like to use this as the "updated" time on the product in the db. (i.e. don't record updates as the time the org admin did his import, but rather the time the manifest was generated)

- Then, similar to rules, we'd skip an update of product metadata if the manifest being imported is older than the updated time on the product.

Reopening this bug and marking it as available.

Comment 8 Eric Sammons 2012-01-10 13:21:01 UTC
This appears to be a duplicate or at similar to 769372.

Comment 9 Tom McKay 2012-01-25 13:24:57 UTC
Fixed in candlepin 0.5.10


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