1BKR(1) Beaker BKR(1)
2
6 bkr - Beaker client
7
9 bkr <subcommand> [options] ...
10
12 Provides a scriptable command-line interface to the Beaker server.
13 The following subcommands are supported. Each subcommand is documented
15 in its own man page. This man page is reserved for common options and
16 features.
17 orphan
19 Subcommands
21 · bkr-distro-trees-list(1) -- List Beaker distro trees
22 · bkr-distro-trees-verify(1) -- Check Beaker distro trees for problems
24 · bkr-distros-edit-version(1) -- Edit the version of Beaker distros
26 · bkr-distros-list(1) -- List Beaker distros
28 · bkr-distros-tag(1) -- Tag Beaker distros
30 · bkr-distros-untag(1) -- Untag Beaker distros
32 · bkr-group-create(1) -- Create a group
34 · bkr-group-list(1) -- List groups
36 · bkr-group-members(1) -- List members of a group
38 · bkr-group-modify(1) -- Modify a group
40 · bkr-harness-test(1) -- Generate Beaker job to test harness installa‐
42 tion
43 · bkr-job-cancel(1) -- Cancel running Beaker jobs
45 · bkr-job-clone(1) -- Clone existing Beaker jobs
47 · bkr-job-comment(1) -- Add a comment to a job
49 · bkr-job-delete(1) -- Delete Beaker jobs
51 · bkr-job-list(1) -- List Beaker jobs
53 · bkr-job-logs(1) -- Print URLs of Beaker recipe log files
55 · bkr-job-modify(1) -- Modify Beaker jobs
57 · bkr-job-results(1) -- Export Beaker job results as XML
59 · bkr-job-submit(1) -- Submit job XML to Beaker
61 · bkr-job-watch(1) -- Watch the progress of a Beaker job
63 · bkr-labcontroller-create(1) -- Create a new lab controller
65 · bkr-labcontroller-list(1) -- List Beaker lab controllers
67 · bkr-labcontroller-modify(1) -- Modify a lab controller
69 · bkr-list-labcontrollers(1) --
71 · bkr-list-systems(1) --
73 · bkr-loan-grant(1) -- Grant a loan for a Beaker system
75 · bkr-loan-return(1) -- Return a current Beaker system loan
77 · bkr-machine-test(1) -- Generate Beaker job to test a system
79 · bkr-policy-grant(1) -- Grant permissions in an access policy
81 · bkr-policy-list(1) -- Lists access policy rules for a system
83 · bkr-policy-revoke(1) -- Revoke permissions in an access policy
85 · bkr-pool-add(1) -- Add systems to a system pool
87 · bkr-pool-create(1) -- Create a system pool
89 · bkr-pool-delete(1) -- Delete a system pool
91 · bkr-pool-list(1) -- List system pools
93 · bkr-pool-modify(1) -- Modify a system pool
95 · bkr-pool-remove(1) -- Remove systems from a pool
97 · bkr-pool-systems(1) -- List systems in a pool
99 · bkr-remove-account(1) -- Remove user accounts
101 · bkr-system-create(1) -- Create a system
103 · bkr-system-delete(1) -- Delete a Beaker system permanently
105 · bkr-system-details(1) -- Export RDF/XML description of a Beaker sys‐
107 tem
108 · bkr-system-list(1) -- List Beaker systems
110 · bkr-system-modify(1) -- Modify system attributes
112 · bkr-system-power(1) -- Control power for a Beaker system
114 · bkr-system-provision(1) -- Provision a Beaker system
116 · bkr-system-release(1) -- Release a reserved Beaker system
118 · bkr-system-reserve(1) -- Manually reserve a Beaker system
120 · bkr-system-status(1) -- Return the current status of a system
122 · bkr-task-add(1) -- Upload tasks to Beaker's task library
124 · bkr-task-details(1) -- Export details of a Beaker task
126 · bkr-task-list(1) -- List tasks in Beaker's task library
128 · bkr-update-inventory(1) -- Submits a inventory job for the system
130 · bkr-update-openstack-trust(1) -- Update OpenStack Keystone trust
132 · bkr-update-prefs(1) -- Update user preferences
134 · bkr-user-modify(1) -- Modify Beaker users
136 · bkr-watchdog-extend(1) -- Extend Beaker watchdog time
138 · bkr-watchdog-show(1) -- Show time remaining on Beaker watchdogs
140 · bkr-watchdogs-extend(1) -- Extend Beaker watchdogs time
142 · bkr-whoami(1) -- Show your Beaker username
144 · bkr-workflow-installer-test(1) -- DEPRECATED workflow to generate a
146 kickstart for testing Anaconda
147 · bkr-workflow-simple(1) -- Simple workflow to generate Beaker jobs
149 Specifying tasks
151 Some bkr subcommands accept one or more <taskspec> arguments. This
152 allows the user to identify a job, or any subcomponent of a job, by its
153 id. The format is <type>:<id> where <type> is one of the following
154 abbreviations, in descending hierarchical order:
155 J job
157 RS recipe set
159 R recipe
161 T recipe-task
163 TR task-result
165 For example, J:123 might contain RS:456, which might contain R:789,
167 which might contain T:1234 and T:5678.
168 This format is also used in the Beaker web UI to identify jobs and
170 their subcomponents.
171
173 Common options
174 These options are applicable to all bkr subcommands.
175 --hub <url>
177 Connect to the Beaker server at the given URL. This overrides
178 the HUB_URL setting from the configuration file. The URL should
179 not include a trailing slash.
180 --insecure
182 Skip all SSL certificate validity checks. This allows the client
183 to connect to a Beaker server with an invalid, expired, or
184 untrusted SSL certificate.
185 --username <username>
187 Authenticate using password authentication, with <username>. If
188 a password is not given using --password, the user is prompted
189 for the password on stdin.
190 This option overrides the authentication type specified in the
192 configuration file, forcing password authentication to be used.
193 --password <password>
195 Authenticate using <password>. This option is only applicable
196 when --username is also passed.
197 --proxy-user <username>
199 Impersonate <username> in order to perform actions on their
200 behalf.
201 This option can only be used when the authenticating user is a
203 member of a group which has been granted 'proxy_user' permission
204 by the Beaker administrator. Typically this permission is
205 granted to service accounts so that a trusted script can perform
206 actions on behalf of any other Beaker user.
207 --help Show a brief summary of the command and its available options
209 then exit.
210 Workflow options
212 These options are applicable to bkr workflow subcommands, such as bkr
213 workflow-simple.
214 --dry-run, --dryrun
216 Don't submit the job(s) to Beaker.
217 --debug
219 Print the generated job XML before submitting it to Beaker.
220 --pretty-xml, --prettyxml
222 Pretty-print the generated job XML in a human-readable form
223 (with indentation and line breaks).
224 --wait Watch the newly submitted job(s) for state changes and print
226 them to stdout. The command will not exit until all submitted
227 jobs have finished. See bkr-job-watch(1).
228 --no-wait, --nowait
230 Do not wait on job completion [default].
231 --quiet
233 Be quiet, don't print warnings.
234 Options for selecting distro tree(s):
236 --family <family>
238 Run the job with the latest distro in <family> (for example:
239 RedHatEnterpriseLinux6).
240 --tag <tag>
242 Run the job with the latest distro tagged with <tag>. Combine
243 this with --family. By default the STABLE tag is used.
244 --distro <name>
246 Run the job with distro named <name>. If the given name includes
247 a % character, it is interpreted as a SQL LIKE pattern (the %
248 character matches any substring).
249 --variant <variant>
251 Run the job with distro variant <variant>, for example Server.
252 Combine this with --family.
253 --arch <arch>
255 Use only <arch> in job. By default, a recipe set is generated
256 for each arch supported by the selected distro. This option may
257 be specified multiple times.
258 Options for selecting system(s):
260 --machine <fqdn>
262 Run the job on system with <fqdn>. This option will always
263 select a single system, and so does not make sense combined with
264 any other system options.
265 --ignore-system-status
267 Always use the system given by --machine, regardless of its sta‐
268 tus.
269 --systype <type>
271 Run the job on system(s) of type <type>. This defaults to
272 Machine which is almost always what you want. Other supported
273 values are Laptop, Prototype and Resource. Laptop type would be
274 used to select a system from the available laptop computers.
275 Similarly, Resource and Prototype would be used in cases where
276 you would want to schedule your job against a system whose type
277 has been set as such.
278 --hostrequire <tag> <operator> <value>
280 Additional <hostRequires/> for the job. For example, labcon‐
281 troller=lab.example.com would become <labcontroller op="="
282 value="lab.example.com"/> in the job XML.
283 For more advanced filtering (for example using <device/>) you
285 can also pass raw XML directly to this option. Any value start‐
286 ing with < is parsed as XML and inserted directly into <hostRe‐
287 quires/>.
288 See job-xml for more information about the <hostRequires/> ele‐
290 ment.
291 --host-filter <name>
293 Look up the pre-defined host filter with the given name,and add
294 the corresponding XML snippet to <hostRequires/>.
295 You can use pre-defined host filters as a short-hand for compli‐
297 cated or difficult to remember XML snippets. Beaker includes
298 many pre-defined filters for different types of hardware. For
299 example, pass --host-filter=INTEL__FAM15_CELERON to filter for
300 hosts with an Intel Celeron CPU.
301 Filter definitions are read from the following configuration
303 files:
304 · /usr/lib/python2.x/site-packages/bkr/client/host-fil‐
306 ters/*.conf
307 · /etc/beaker/host-filters/*.conf
309 · ~/.beaker_client/host-filter
311 Files within each directory are processed in lexicographical
313 order. The files contain one filter definition per line, con‐
314 sisting of the filter name and the associated XML snippet sepa‐
315 rated by whitespace. If the same filter name appears in multi‐
316 ple files, the last definition overrides earlier definitions.
317 --keyvalue <name> <operator> <value>
319 Run the job on system(s) which have the key <name> set to
320 <value> (for example: NETWORK=e1000).
321 --random
323 Select a system at random. The systems owned by the user are
324 first checked for availability, followed by the systems owned by
325 the user's group and finally all other systems.
326 Options for selecting tasks:
328 --task <task>
330 Include <task> in the job. This option may be specified multiple
331 times.
332 --taskfile <filename>
334 Include tasks listed in <filename>, each line contains one task
335 name. Lines not starting with '/' are ignored.
336 --package <package>
338 Include tests for <package> in the job. This option may be spec‐
339 ified multiple times.
340 --task-type <type>
342 Include tasks of type <type> in the job. This option may be
343 specified multiple times.
344 --install <package>
346 Install additional package <package> after provisioning. This
347 uses the /distribution/pkginstall task. This option may be spec‐
348 ified multiple times.
349 --kdump
351 Enable kdump using using /kernel/networking/kdump.
352 --ndump
354 Enable ndnc using using /kernel/networking/ndnc.
355 --suppress-install-task
357 Omit the installation checking task.
358 By default, the first task in the recipe will be /distribu‐
360 tion/check-install (or the previous implementation /distribu‐
361 tion/install on RHEL7 and older). The purpose of this task is to
362 check that the operating system was installed successfully and
363 report back on any potential problems, and to collect informa‐
364 tion about the installed system for debugging.
365 Pass this option if you do not want this task to be implicitly
367 inserted at the start of the recipe.
368 Options for job configuration:
370 --job-owner <username>
372 Submit the job on behalf of <username>. The job will be owned by
373 <username> rather than the submitting user.
374 The submitting user must be a submission delegate of <username>.
376 Users can add other users as submission delegates on their Pref‐
377 erences page in Beaker's web UI.
378 --job-group <group>
380 Associate the job with <group>. This will allow other group mem‐
381 bers to modify the job.
382 --whiteboard <whiteboard>
384 Set the job's whiteboard to <whiteboard>.
385 --taskparam <name>=<value>
387 Sets parameter <name> to <value> for all tasks in the job.
388 New in version 0.14.3.
390 --ignore-panic
393 Disable kernel panic detection and install failure detection for
394 the recipe. By default if a kernel panic appears on the serial
395 console, or a fatal installer error appears during installation,
396 the recipe is aborted. When this option is given, the messages
397 are ignored and the recipe is not aborted.
398 --reserve
400 Reserve the system at the end of the recipe, for further testing
401 or examination. The system will be reserved when all tasks have
402 completed executing, or if the recipe ends abnormally. Refer to
403 reservesys.
404 --reserve-duration <seconds>
406 When --reserve is used, this option controls the duration for
407 the reservation. The default duration is 86400 seconds (24
408 hours).
409 --cc <email>
411 Add <email> to the cc list for the job(s). The cc list will
412 receive the job completion notification. This option may be
413 specified multiple times.
414 --priority <priority>
416 Set job priority to <priority>. Can be Low, Medium, Normal,
417 High, or Urgent. The default is Normal.
418 --retention-tag <tag>
420 Specify data retention policy for this job [default: Scratch]
421 --product <product>
423 Associate job with <product> for data retention purposes.
424 Options for installation:
426 --method <method>
428 Installation source method (nfs, http, ftp) [default: nfs].
429 --kernel-options <opts>
431 Pass additional kernel options for during installation. The
432 options string is applied on top of any install-time kernel
433 options which are set by default for the chosen system and dis‐
434 tro.
435 --kernel-options-post <opts>
437 Pass additional kernel options for after installation. The
438 options string is applied on top of any post-install kernel
439 options which are set by default for the chosen system and dis‐
440 tro.
441 --ks-append <commands>
443 Specify additional kickstart commands to add to the base kick‐
444 start file.
445 --ks-meta <options>
447 Pass kickstart metadata <options> when generating kickstart.
448 --repo <url>
450 Make the yum repository at <url> available during initial
451 installation of the system and afterwards. This option may be
452 specified multiple times. The installation may fail if the repo
453 is not actually available.
454 --repo-post <url>
456 Make the yum repository at <url> available AFTER the installa‐
457 tion. This option may be specified multiple times. The repo con‐
458 fig will be appended to the kickstart's %post section. Whether
459 or not the installation succeeds is not affected by the avail‐
460 ability of the repo.
461 --kickstart <filename>
463 Use this kickstart template for installation. Templates are ren‐
464 dered on the server. Refer to the custom-kickstarts section in
465 Beaker's documentation for details about the templating language
466 and available variables. You can also pass raw kickstarts in -
467 if you don't use any Jinja2 variable substitution syntax, the
468 rendering process will reproduce the template verbatim.
469 If the template provides the following line:
471 ## kernel_options: <options>
473 the specified kernel options will be appended to existing ones
475 defined with --kernel-options.
476 Options for multi-host testing:
478 --clients <number>
480 Use <number> clients in the job.
481 --servers <number>
483 Use <number> servers in the job.
484
486 On startup bkr searches the following locations in order for its con‐
487 fig:
488 ~/.beaker_client/config
489 /etc/beaker/client.conf
491
493 The following environment variables affect the operation of bkr.
494 BEAKER_CLIENT_CONF
496 If set to a non-empty value, this overrides the usual configura‐
497 tion search paths. This must be the full path to the configura‐
498 tion file.
499
501 The Beaker team <beaker-devel@lists.fedorahosted.org>
502
504 2013, Red Hat, Inc
50526.3 Jan 31, 2019 BKR(1)