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-history-list(1) -- Export history of activity for the
110 given system
111 · bkr-system-list(1) -- List Beaker systems
113 · bkr-system-modify(1) -- Modify system attributes
115 · bkr-system-power(1) -- Control power for a Beaker system
117 · bkr-system-provision(1) -- Provision a Beaker system
119 · bkr-system-release(1) -- Release a reserved Beaker system
121 · bkr-system-reserve(1) -- Manually reserve a Beaker system
123 · bkr-system-status(1) -- Return the current status of a system
125 · bkr-task-add(1) -- Upload tasks to Beaker's task library
127 · bkr-task-details(1) -- Export details of a Beaker task
129 · bkr-task-list(1) -- List tasks in Beaker's task library
131 · bkr-update-inventory(1) -- Submits a inventory job for the system
133 · bkr-update-openstack-trust(1) -- Update OpenStack Keystone trust
135 · bkr-update-prefs(1) -- Update user preferences
137 · bkr-user-modify(1) -- Modify Beaker users
139 · bkr-watchdog-extend(1) -- Extend Beaker watchdog time
141 · bkr-watchdog-show(1) -- Show time remaining on Beaker watchdogs
143 · bkr-watchdogs-extend(1) -- Extend Beaker watchdogs time
145 · bkr-whoami(1) -- Show your Beaker username
147 · bkr-workflow-installer-test(1) -- DEPRECATED workflow to generate a
149 kickstart for testing Anaconda
150 · bkr-workflow-simple(1) -- Simple workflow to generate Beaker jobs
152 Specifying tasks
154 Some bkr subcommands accept one or more <taskspec> arguments. This
155 allows the user to identify a job, or any subcomponent of a job, by its
156 id. The format is <type>:<id> where <type> is one of the following
157 abbreviations, in descending hierarchical order:
158 J job
160 RS recipe set
162 R recipe
164 T recipe-task
166 TR task-result
168 For example, J:123 might contain RS:456, which might contain R:789,
170 which might contain T:1234 and T:5678.
171 This format is also used in the Beaker web UI to identify jobs and
173 their subcomponents.
174
176 Common options
177 These options are applicable to all bkr subcommands.
178 --hub <url>
180 Connect to the Beaker server at the given URL. This overrides
181 the HUB_URL setting from the configuration file. The URL should
182 not include a trailing slash.
183 --insecure
185 Skip all SSL certificate validity checks. This allows the client
186 to connect to a Beaker server with an invalid, expired, or
187 untrusted SSL certificate.
188 --username <username>
190 Authenticate using password authentication, with <username>. If
191 a password is not given using --password, the user is prompted
192 for the password on stdin.
193 This option overrides the authentication type specified in the
195 configuration file, forcing password authentication to be used.
196 --password <password>
198 Authenticate using <password>. This option is only applicable
199 when --username is also passed.
200 --proxy-user <username>
202 Impersonate <username> in order to perform actions on their
203 behalf.
204 This option can only be used when the authenticating user is a
206 member of a group which has been granted 'proxy_user' permission
207 by the Beaker administrator. Typically this permission is
208 granted to service accounts so that a trusted script can perform
209 actions on behalf of any other Beaker user.
210 --help Show a brief summary of the command and its available options
212 then exit.
213 Workflow options
215 These options are applicable to bkr workflow subcommands, such as bkr
216 workflow-simple.
217 --dry-run, --dryrun
219 Don't submit the job(s) to Beaker.
220 --debug
222 Print the generated job XML before submitting it to Beaker.
223 --pretty-xml, --prettyxml
225 Pretty-print the generated job XML in a human-readable form
226 (with indentation and line breaks).
227 --wait Watch the newly submitted job(s) for state changes and print
229 them to stdout. The command will not exit until all submitted
230 jobs have finished. See bkr-job-watch(1).
231 --no-wait, --nowait
233 Do not wait on job completion [default].
234 --quiet
236 Be quiet, don't print warnings.
237 Options for selecting distro tree(s):
239 --family <family>
241 Run the job with the latest distro in <family> (for example:
242 RedHatEnterpriseLinux6).
243 --tag <tag>
245 Run the job with the latest distro tagged with <tag>. Combine
246 this with --family. By default the STABLE tag is used.
247 --distro <name>
249 Run the job with distro named <name>. If the given name includes
250 a % character, it is interpreted as a SQL LIKE pattern (the %
251 character matches any substring).
252 --variant <variant>
254 Run the job with distro variant <variant>, for example Server.
255 Combine this with --family.
256 --arch <arch>
258 Use only <arch> in job. By default, a recipe set is generated
259 for each arch supported by the selected distro. This option may
260 be specified multiple times.
261 Options for selecting system(s):
263 --machine <fqdn>
265 Run the job on system with <fqdn>. This option will always
266 select a single system, and so does not make sense combined with
267 any other system options.
268 --ignore-system-status
270 Always use the system given by --machine, regardless of its sta‐
271 tus.
272 --systype <type>
274 Run the job on system(s) of type <type>. This defaults to
275 Machine which is almost always what you want. Other supported
276 values are Laptop, Prototype and Resource. Laptop type would be
277 used to select a system from the available laptop computers.
278 Similarly, Resource and Prototype would be used in cases where
279 you would want to schedule your job against a system whose type
280 has been set as such.
281 --hostrequire <tag> <operator> <value>
283 Additional <hostRequires/> for the job. For example, labcon‐
284 troller=lab.example.com would become <labcontroller op="="
285 value="lab.example.com"/> in the job XML.
286 For more advanced filtering (for example using <device/>) you
288 can also pass raw XML directly to this option. Any value start‐
289 ing with < is parsed as XML and inserted directly into <hostRe‐
290 quires/>.
291 See job-xml for more information about the <hostRequires/> ele‐
293 ment.
294 --host-filter <name>
296 Look up the pre-defined host filter with the given name,and add
297 the corresponding XML snippet to <hostRequires/>.
298 You can use pre-defined host filters as a short-hand for compli‐
300 cated or difficult to remember XML snippets. Beaker includes
301 many pre-defined filters for different types of hardware. For
302 example, pass --host-filter=INTEL__FAM15_CELERON to filter for
303 hosts with an Intel Celeron CPU.
304 Filter definitions are read from the following configuration
306 files:
307 · /usr/lib/python2.x/site-packages/bkr/client/host-fil‐
309 ters/*.conf
310 · /etc/beaker/host-filters/*.conf
312 · ~/.beaker_client/host-filter
314 Files within each directory are processed in lexicographical
316 order. The files contain one filter definition per line, con‐
317 sisting of the filter name and the associated XML snippet sepa‐
318 rated by whitespace. If the same filter name appears in multi‐
319 ple files, the last definition overrides earlier definitions.
320 --keyvalue <name> <operator> <value>
322 Run the job on system(s) which have the key <name> set to
323 <value> (for example: NETWORK=e1000).
324 --random
326 Select a system at random. The systems owned by the user are
327 first checked for availability, followed by the systems owned by
328 the user's group and finally all other systems.
329 Options for selecting tasks:
331 --task <task>
333 Include <task> in the job. This option may be specified multiple
334 times.
335 --taskfile <filename>
337 Include tasks listed in <filename>, each line contains one task
338 name. Lines not starting with '/' are ignored.
339 --package <package>
341 Include tests for <package> in the job. This option may be spec‐
342 ified multiple times.
343 --task-type <type>
345 Include tasks of type <type> in the job. This option may be
346 specified multiple times.
347 --install <package>
349 Install additional package <package> after provisioning. This
350 uses the /distribution/pkginstall task. This option may be spec‐
351 ified multiple times.
352 --kdump
354 Enable kdump using using /kernel/networking/kdump.
355 --ndump
357 Enable ndnc using using /kernel/networking/ndnc.
358 --suppress-install-task
360 Omit the installation checking task.
361 By default, the first task in the recipe will be /distribu‐
363 tion/check-install (or the previous implementation /distribu‐
364 tion/install on RHEL7 and older). The purpose of this task is to
365 check that the operating system was installed successfully and
366 report back on any potential problems, and to collect informa‐
367 tion about the installed system for debugging.
368 Pass this option if you do not want this task to be implicitly
370 inserted at the start of the recipe.
371 Options for job configuration:
373 --job-owner <username>
375 Submit the job on behalf of <username>. The job will be owned by
376 <username> rather than the submitting user.
377 The submitting user must be a submission delegate of <username>.
379 Users can add other users as submission delegates on their Pref‐
380 erences page in Beaker's web UI.
381 --job-group <group>
383 Associate the job with <group>. This will allow other group mem‐
384 bers to modify the job.
385 --whiteboard <whiteboard>
387 Set the job's whiteboard to <whiteboard>.
388 --taskparam <name>=<value>
390 Sets parameter <name> to <value> for all tasks in the job.
391 New in version 0.14.3.
393 --ignore-panic
396 Disable kernel panic detection and install failure detection for
397 the recipe. By default if a kernel panic appears on the serial
398 console, or a fatal installer error appears during installation,
399 the recipe is aborted. When this option is given, the messages
400 are ignored and the recipe is not aborted.
401 --reserve
403 Reserve the system at the end of the recipe, for further testing
404 or examination. The system will be reserved when all tasks have
405 completed executing, or if the recipe ends abnormally. Refer to
406 reservesys.
407 --reserve-duration <seconds>
409 When --reserve is used, this option controls the duration for
410 the reservation. The default duration is 86400 seconds (24
411 hours).
412 --cc <email>
414 Add <email> to the cc list for the job(s). The cc list will
415 receive the job completion notification. This option may be
416 specified multiple times.
417 --priority <priority>
419 Set job priority to <priority>. Can be Low, Medium, Normal,
420 High, or Urgent. The default is Normal.
421 --retention-tag <tag>
423 Specify data retention policy for this job [default: Scratch]
424 --product <product>
426 Associate job with <product> for data retention purposes.
427 Options for installation:
429 --method <method>
431 Installation source method (nfs, http, ftp) [default: nfs].
432 --kernel-options <opts>
434 Pass additional kernel options for during installation. The
435 options string is applied on top of any install-time kernel
436 options which are set by default for the chosen system and dis‐
437 tro.
438 --kernel-options-post <opts>
440 Pass additional kernel options for after installation. The
441 options string is applied on top of any post-install kernel
442 options which are set by default for the chosen system and dis‐
443 tro.
444 --ks-append <commands>
446 Specify additional kickstart commands to add to the base kick‐
447 start file.
448 --ks-meta <options>
450 Pass kickstart metadata <options> when generating kickstart.
451 --repo <url>
453 Make the yum repository at <url> available during initial
454 installation of the system and afterwards. This option may be
455 specified multiple times. The installation may fail if the repo
456 is not actually available.
457 --repo-post <url>
459 Make the yum repository at <url> available AFTER the installa‐
460 tion. This option may be specified multiple times. The repo con‐
461 fig will be appended to the kickstart's %post section. Whether
462 or not the installation succeeds is not affected by the avail‐
463 ability of the repo.
464 --kickstart <filename>
466 Use this kickstart template for installation. Templates are ren‐
467 dered on the server. Refer to the custom-kickstarts section in
468 Beaker's documentation for details about the templating language
469 and available variables. You can also pass raw kickstarts in -
470 if you don't use any Jinja2 variable substitution syntax, the
471 rendering process will reproduce the template verbatim.
472 If the template provides the following line:
474 ## kernel_options: <options>
476 the specified kernel options will be appended to existing ones
478 defined with --kernel-options.
479 Options for multi-host testing:
481 --clients <number>
483 Use <number> clients in the job.
484 --servers <number>
486 Use <number> servers in the job.
487
489 On startup bkr searches the following locations in order for its con‐
490 fig:
491 ~/.beaker_client/config
492 /etc/beaker/client.conf
494
496 The following environment variables affect the operation of bkr.
497 BEAKER_CLIENT_CONF
499 If set to a non-empty value, this overrides the usual configura‐
500 tion search paths. This must be the full path to the configura‐
501 tion file.
502
504 The Beaker team <beaker-devel@lists.fedorahosted.org>
505
507 2013-2019 Red Hat, Inc.
50826.5 Sep 26, 2019 BKR(1)