Bug 819924

weighing in here..
IMHO customers are going to have different content sets and versions in their own katello servers.  If the rpm versions conflict w/ whats in ec2 RHUI.. I believe we will hear customers screaming.

This is making my brain hurt.  I think I understand the desired behaviour, but I don't off the top of my head see how to make this work in the general case.  I worry about what happens when you've got "conflicting" packages available at run time vs build time.

Presumably we will need to pull together some folks from katello team and IF team and hash out what we want the end to end behaviour to be.  I'm hoping it's not as scary as It looks right now.

(In reply to comment #2)
> I worry about what happens when you've got "conflicting" packages available at
> run time vs build time.

You got it, that's exactly the problem I hit.  The repository set during build and deploy,emt time are different ... and it resulted in a yum dependency problem.

Granted, I'm the one adjusting the deploy-time repository set, by disabling the RHUI repos.  I can easily not do that.  However, it raises the question whether a customer will want to build and deploy ec2 images using *ONLY* private system engine content.  As currently designed, RHUI will be used to satisfy dependencies during image customization.

Talked to Wes about this for a while.

Basically the model we're stuck with imposes a hard one-or-the-other situation w/r/t RHUI and System Engine. Customers simply aren't going to be able to use both unless they really know what they're doing.

The right way to deal with this in Factory for snapshot builds is to by default disable the existing repos in the JEOS before installing any new software. This should ensure that we never get into a conflicting package situation, at least given that the user is smart enough not to use a JEOS that is newer than the base  repo they have set up in System Engine. (This seems like a minimal requirement to me.)

If a user *really wants* to pull content from RHUI or CDN, then they should have to turn that on explicitly either in the template or in Factory config (or wherever it is most appropriate). They will then be reasonably prepared to deal with the consequences.

Note, I have no idea how difficult it will be to make this work in Factory. It seems like it ought to be a fairly minor patch that would be a candidate for z-stream -- somebody correct me if I'm wrong...

Hugh,

I believe you are correct in thinking this is a relatively minor change.  Disabling RHUI amounts to moving, deleting or editing a couple of repo files prior to customization.  We already have hooks in place to do some RHEL specific shell commands that run before image customization.  We could simply add the required fixes there.

I also tend to agree that the default behaviour should be to disable the RHUI package access and only re-enable it via an explicit flag, either within the TDL or globally for the factory.  (Putting the flag in the TDL violates our stated goal of making TDL cloud-agnostic, so we should discuss further.)

Doing this will bring the post-JEOS customization environments for both EC2 snapshots and local upload builds into parity.  At the moment an upload build does not have access to the non-JEOS package set unless the user has created a repo containing these packages and included it explicitly in the TDL.

As long as we are discussing the differences between snapshot and upload builds on EC2, it would also be nice to make the starting point AMIs themselves more closely match the JEOS images that are created by Oz when doing upload builds.  The AMIs we currently use, the official RHEL hourlies, have a somewhat larger package set than the bare bones JEOS image created in Anaconda via Oz.

However, this is a separate issue.