0

I'm writing a module, that will provide for mirrored yum-repositories on our network. The single server will host the mirrors offering them to other hosts (and itself).

I have a problem with the initial chicken-and-egg -- the first download may not happen for a while, but, if I enable a new repository before the mirroring script for it finishes the first run, I can not install any package due to yum-failures. But at some point later it needs to be enabled...

Can I have the enabled-attribute of my yumrepo-resource depend on whether or not "${repodir}/repodata/repomd.xml" exists at the time of the Puppet-run?

I thought of inline_template, but it runs on Puppet-server, not client. Can anything else be done while staying within Puppet itself (without custom functions)?

Perhaps, the attribute can be triggered by whether or not an Exec took place -- I could then make Exec conditional on a file's presence with creates-attribute?

We are still at Puppet-3.7.5 here... Thanks!

Mikhail T.
  • 3,043
  • 3
  • 29
  • 46

1 Answers1

1

I thought of inline_template, but it runs on [the] server, not [the] client.

I'm not seeing why that's a problem here. The condition you want to evaluate is not specific to the clients; rather it is a property of a specific machine on the network (the mirror server) that has site-wide significance. As far as I can tell, evaluating that condition on the master during catalog compilation should not present any inherent problem.

And that's good news for you, because all managed property values are determined during catalog building. There is no way to express an indirect or to-be-evaluated property value. If you want to incorporate information drawn from the target node into its catalog then you must either glean that information from facts (possibly custom facts), or manage that information.

Two approaches to your problem come to mind:

  1. You can use the generate() function (on the master) to run commands that determine whether particular mirrors are ready. If the master does not run on the same machine that hosts the mirrors, then this requires some mechanism for the master to interrogate the mirror host remotely.

  2. You can use a custom fact on the mirror host to report on which repositories are present and ready, and based on that information, have it export the appropriate Yumrepo resources for all nodes, itself included, to collect.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • *There is no way to express an indirect or to-be-evaluated property value* -- yeah, that's what I was looking for. Something like `Exec`'s `creates` or `onlyif`, but for `Yumrepo`-resource or, better yet, for all resource-types (a metaparameter). – Mikhail T. Apr 09 '16 at 17:10