CiscoSystems/grizzly-manifests — pull request #154 by markvoelker (2013-08-20 04:27:23+00:00)
Title: Modify supplemental apt repo setup

Fix bug 1214145 by doing two things:
* Add the signing key for the supplemental repo to the apt::source
definition. This prevents attempts to fetch the key based on
ID from a keyserver, even though it's the same key used in the
main repo.
* Make the supplemental repo optional and allow users to specify
it's location. The supplemental repo is currently not needed for
many installations and it is not necessary to configure it for
a functional cloud. Users with no-net install scenarios may
also wish to point to a local mirror or cache rather than the
real thing if they need it at all. This commit allows users
to choose to not set up the supplemental repo at all by commenting
out one line in site.pp or to change the location from the
defaults.

Fixes: bug #1214145

=====
Some additional notes:
* After some discussion I've elected not to do this by setting a boolean in site and setting the URL for the supplemental repo based on the main repo. We're doing it this way to avoid a proliferation of repositories: e.g. we don't want to have to set up an n1k-test supplement repo in addition to the cisco-supplemental repo and make sure the two always have the same packages. That's a pain because the supplemental repos are currently managed by hand (and symlinking one to the other would produce warnings that--though harmless--would potentially make users unfortable). We're therefore aiming to provide a single supplemental repo whether you're using the n1k branch or the mainline branch. If a scenario develops in the future where we need to supply separate supplemental repos we can revisit this, but as it stands today we don't see a need to (particularly if the n1k branch collapses back into mainline COI once the relevant bits are upstream in Havana).

* We also made the supplmental repo completely optional (comment out one line in site.pp and it won't get configured at all) for those that don't want to fiddle with it because they're doing no-net installs and don't need anything it provides and can therefore save the labor of setting up a local mirror.

* It may look odd that I have the same multi-line key block for both repo definitions. Based on the logs in the bug, it's actually necessary to supply the key rather than just the key ID if you want to avoid an attempt to fetch the key from public keyservers...even if the two repos share the same key. This could possibly be a timing issue, but if so it's one someone has obviously hit.