You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

Help:Puppet-compiler: Difference between revisions

From Wikitech-static
Jump to navigation Jump to search
imported>Arturo Borrero Gonzalez
(No longer a draft!)
imported>Andrew Bogott
(→‎Catalog compiler for CloudVPS: Updated to reflect that this is now MUCH easier :))
Line 24: Line 24:
== Catalog compiler for CloudVPS ==
== Catalog compiler for CloudVPS ==


This is a way to get a catalog compiler working for CloudVPS instanes. You can do a local run of the integration jenkins job. This is usually done in an instance VM on CloudVPS.
The [https://integration.wikimedia.org/ci/job/operations-puppet-catalog-compiler/ standard jenkins-hosted catalog compiler] can now target VPS instances. Because VMs are frequently created and deleted, it may be necessary to update the facts from whatever puppetmaster is hosting the VM in question -- instructions for doing that can be found at [[Nova Resource:Puppet-diffs]].


Steps are:
<br />
 
* Push your patch to [[gerrit]] using [[git-review]]. You will get a '''change''' number.
* Choose a puppet master server &lt;master&gt;
* Build &lt;worker&gt; as a large Jessie instance (probably anywhere, but ideally in the same project as &lt;master&gt; if &lt;master&gt; is a VM
* On &lt;worker&gt;, apply the classes "role::puppet_compiler" and "profile::puppetmaster::labsenc" (via Horizon, for example)
* On &lt;worker&gt;, apply the following hiera (via Horizon, for example): <syntaxhighlight lang="yaml">
discovery::app_routes: {}
etcd::cluster_name: <something arbitrary and distinctive>
etcd::cluster_state: new
etcd::host: '%{::fqdn}'
etcd::peers_list: <worker hostname>=http://<worker fqdn>:2380
etcd::port: 2739
etcd::ssl::puppet_cert_name: '%{::fqdn}'
etcd::use_ssl: true
labsdnsconfig: {}
</syntaxhighlight>
 
* Gather facts of target host. On a local (not a VM) with keys installed to access all the necessary hosts, run this script from the puppet repo:
<syntaxhighlight lang="shell-session">
$ PUPPET_MASTERS=<master> PUPPET_COMPILER=<worker> modules/puppet_compiler/files/compiler-update-facts
</syntaxhighlight>
 
* In order to see results in HTML for a web browser, you will need to set up a web proxy (ideally named puppet-compiler.wmflabs.org) pointing to &lt;worker&gt;
Make sure port 80 is open on &lt;worker&gt; so the proxy can reach it. You can do this via Horizon.
 
* Once all that is done, you can invoke a compiler test on &lt;worker&gt; like this:
<syntaxhighlight lang="shell-session">
CHANGE=<patch of interest> NODES=<node of interest> BUILD_NUMBER=8 puppet-compiler
</syntaxhighlight>
 
The source of this information is:
* Andrew's comment in [[phab:T97081#3681225]]


== Catalog compiler local run (pcc utility) ==
== Catalog compiler local run (pcc utility) ==
Line 82: Line 50:


If running locally, collect facts by hand from the corresponding puppetmaster. If running in the jenkins web service for a production host, follow [[Nova_Resource:Puppet-diffs#FAQ|these instructions]].
If running locally, collect facts by hand from the corresponding puppetmaster. If running in the jenkins web service for a production host, follow [[Nova_Resource:Puppet-diffs#FAQ|these instructions]].
== Limitations ==
The puppet-compiler mechanism won't discover all the issues in the resulting catalog. If the catalog was compiled OK by jenkins, you may still find some issues when running the puppet agent.<br>
Some known limitations:
* Files sources. When declaring a <code>File { '/my/file':</code>, the path information you specified in the <code>content</code> parameter will be resolved at puppet agent runtime.
* Private hiera lookups. The way hiera fetches data may vary between how is done in the puppet-compiler process to how is done in the final puppet master. Specifically, secrets in the private repo.
* Hiera behaviour. Currently, we don't have a way to know in concrete how hiera is behaving when compiling the catalog. See [[phab:T215507 | phabricator ticket T215507]] for more information.
'''TODO:''' I'm writting from memory. This section can be improved for accuracy.


== See also ==
== See also ==

Revision as of 16:57, 19 April 2019

You can run puppet-compiler by hand to get the results of a given puppet configuration without having to deploy it to servers.

This page gives some instructions on doing so.

Catalog compiler in integration Jenkins

There is a jenkins job that takes a gerrit change and runs the compiler.

Steps:

  1. Push your change to gerrit using git-review
  2. Go to https://integration.wikimedia.org/ci/job/operations-puppet-catalog-compiler/
  3. Go to "Build with parameters" https://integration.wikimedia.org/ci/job/operations-puppet-catalog-compiler/build
  4. In the form, fill change number (from gerrit) and list of nodes
  5. Hit the Build button
  6. Wait for the jenkins job to end
  7. You can check for results in the jenkins Console output
  8. You can see the compiled catalogs in a web frontend. The URL structure is https://puppet-compiler.wmflabs.org/compiler_host/build_id where...
    • compiler_host is the hostname (without domain name) of the compiler node that Jenkins dispatched the build to. A current list of possible compiler nodes is available at https://integration.wikimedia.org/ci/label/puppet-compiler-node/
    • build_id is the unique id of the Jenkins build (changes with every run).
    • This link is automatically constructed and can be found at the bottom of the Jenkins console output after each build.

NOTE: this method won't work for CloudVPS instances (see next method below).

Catalog compiler for CloudVPS

The standard jenkins-hosted catalog compiler can now target VPS instances. Because VMs are frequently created and deleted, it may be necessary to update the facts from whatever puppetmaster is hosting the VM in question -- instructions for doing that can be found at Nova Resource:Puppet-diffs.


Catalog compiler local run (pcc utility)

There is a also a tool called pcc under the operations/puppet/utils repo. You'll need your Jenkins API token to make it work, retrievable under https://integration.wikimedia.org/ci/user/$YOURUSERNAME/configure.

Example:

$ ./utils/pcc GERRIT_CHANGE_NUMBER LIST_OF_NODES --username YOUR_USERNAME --api-token 12312312312312313  
$ ./utils/pcc 282936 oxygen.eqiad.wmnet --username batman --api-token 12312312312312313

Troubleshooting

Some common errors and mistakes.

  • Catalog for Cloud VPS instances doesn't get any classes/roles.

This happens because $::realm is not set to labs. There are patches in place to fix this, but the puppet-compiler software needs to be released with these patches.

  • ERROR: Unable to find facts for host tools-services-01.tools.eqiad.wmflabs, skipping

If running locally, collect facts by hand from the corresponding puppetmaster. If running in the jenkins web service for a production host, follow these instructions.

Limitations

The puppet-compiler mechanism won't discover all the issues in the resulting catalog. If the catalog was compiled OK by jenkins, you may still find some issues when running the puppet agent.
Some known limitations:

  • Files sources. When declaring a File { '/my/file':, the path information you specified in the content parameter will be resolved at puppet agent runtime.
  • Private hiera lookups. The way hiera fetches data may vary between how is done in the puppet-compiler process to how is done in the final puppet master. Specifically, secrets in the private repo.
  • Hiera behaviour. Currently, we don't have a way to know in concrete how hiera is behaving when compiling the catalog. See phabricator ticket T215507 for more information.

TODO: I'm writting from memory. This section can be improved for accuracy.

See also