Bug 785225

huh.. I thought anaconda would fail on that.. interesting

Anaconda may fail but yum does not.  I've verified this behaviour on the command line.

Annoyingly, a reference to a package group _will_ fail if there are not groups at all in any of the associated repos.  However, once defined groups are present, adding a non-existent group name does not produce an error.

I will see if we can get yum to be more strict about this.  If not, this is going to be a bit more effort to fix, since we'll need to check all groups and packages in the TDL in some step that is distinct from the yum install command.

Ian, what's the expectation on this?  If you think it will be done prior to the puddle build on 2/8, plz annotate here.

wondering if jlaska could assist here w/ yum foo

(In reply to comment #1)
> huh.. I thought anaconda would fail on that.. interesting

If you are using "%packages --ignoremissing" in the kickstart, anaconda will blissfully ignore any typos in the %package section.  I've never been clear how to find the kickstart used when building images.

https://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_3._Package_Selection

After talking this over with James, and James in turn talking to Seth, it seems there's no way to induce yum to err out when packages or groups are missing, unless every package and/or group in a transaction is missing.

The solution they've proposed is to use a series of yum commands, one per package or group in the TDL.

This sounds fine to me but will require some non-trivial changes to Oz that I'm hesitant to make prior to 1.0.

Created attachment 559642 [details]
0001-BZ-785225-Customize-packages-one-at-a-time-to-captur.patch

(In reply to comment #6)
> After talking this over with James, and James in turn talking to Seth, it seems
> there's no way to induce yum to err out when packages or groups are missing,
> unless every package and/or group in a transaction is missing.
> 
> The solution they've proposed is to use a series of yum commands, one per
> package or group in the TDL.

Rather than looping over SSH calls, I wonder if it might be sensible in the short-term to iterate within a single SSH call?

I have attached a patch to demonstrate.  Would this be acceptable for 1.0?

JRD, need you/Ian to make a call whether this is doable for 1.0 or not. Either dev-ack it or move it to cloudforms-1.1.0.

I would prefer to push this to 1.1.0.  The proposed approach (looping through yum commands) is entirely reasonable but is a pretty fundamental change in our customization step, one that I don't want to make at this point.

The only downside is a failure to clearly notify users that they've included packages or groups that don't actually exist.

Given that we are encouraging people to use auto-generated templates, and these templates are being generated by a tool (Katello) that has absolute knowledge of what is present in individual repos, I think the risk associated with keeping this as-is is minimal.

(In reply to comment #9)
> I would prefer to push this to 1.1.0.  The proposed approach (looping through
> yum commands) is entirely reasonable but is a pretty fundamental change in our
> customization step, one that I don't want to make at this point.

No objections

> The only downside is a failure to clearly notify users that they've included
> packages or groups that don't actually exist.
> 
> Given that we are encouraging people to use auto-generated templates, and these
> templates are being generated by a tool (Katello) that has absolute knowledge
> of what is present in individual repos, I think the risk associated with
> keeping this as-is is minimal.

Agreed.  Additionally, I don't think we are inconsistently handling missing or incorrect package issues.  Perhaps the only difference between image build+push and the yum command-line is that with the command-line ... you get the following feedback:

> # yum install homey-dont-play-that
> Loaded plugins: langpacks, presto, refresh-packagekit
> Setting up Install Process
> No package homey-dont-play-that available.
> Error: Nothing to do

Perhaps our focus for 1.0 is ensuring that information is available in a log somehwere?

This appears to have been auto-approved because flags weren't flipped prior to moving to 1.1.0?.  This is will be considered for a future release.

Here again, the move seems to be away from using TDL and back toward using custom kickstart/preeseed/etc.  I'm going to close this as WONTFIX.