Bug 986177 - command-line tool to debug kickstart templates/snippets
command-line tool to debug kickstart templates/snippets
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: scheduler (Show other bugs)
0.9
Unspecified Unspecified
high Severity medium (vote)
: 0.15.3
: ---
Assigned To: Raymond Mancy
tools-bugs
UX
: FutureFeature
Depends On:
Blocks: 593663
  Show dependency treegraph
 
Reported: 2013-07-19 02:51 EDT by Dan Callaghan
Modified: 2018-02-05 19:41 EST (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 817795
Environment:
Last Closed: 2014-02-02 23:52:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Callaghan 2013-07-19 02:51:49 EDT
+++ This bug was initially created as a clone of Bug #817795 +++

On bug 817795 John suggested a command-line tool for debugging Beaker's kickstart generation. It would need to take a system FQDN, and perhaps a recipe ID and some other optional parameters, and use the code in bkr.server.kickstart to spit out the same kickstart that Beaker would generate during its provisioning process.

The tool should also have some way of supplying an additional lookup directory for templates/snippets, to be inserted at the front of the Jinja ChoiceLoader. Admins can use this to test out modifications to templates/snippets outside of /etc/beaker first, and then copy them into /etc/beaker when the kickstarts are right.
Comment 1 Raymond Mancy 2013-12-16 23:54:31 EST
So is the idea to generate a kickstart based (at least partially) on an existing recipe, or is it to see what a kickstart would look like with a recipe that had distro X, arch Y etc?

I guess there's no reason why both options could not be implemented.
Comment 2 Dan Callaghan 2013-12-17 00:11:58 EST
The simplest case is to generate a kickstart with no associated recipe (that's what happens you do a manual provision). Although you're right, the user would have to supply a distro tree in that case (by its id I suppose). Maybe it could take one or the other:

    beaker-test-kickstart --snippet-dir ./mysnippets \
        --system example.com --distro-tree-id 1234

    beaker-test-kickstart --snippet-dir ./mysnippets \
        --system example.com --recipe-id 1234

The other improtant option is the user -- by default it could use 'admin', or the user could pass --user someusername. Since this is a server-side command it can't there will be no identity.current.user.
Comment 3 Raymond Mancy 2013-12-17 00:27:49 EST
Oh, I didn't realise this was a server side command. So that makes a little bit more sense as to why we would use a distro tree id, and id is the simplest way to for us (developers) to implement it.
Comment 4 andrew 2013-12-20 12:27:41 EST
So lets say we have some Kickstart Metadata snippets. How to we add that to this? that's really what this to be able to handle.
Comment 5 Raymond Mancy 2014-01-12 20:46:13 EST
By doing something like: 

    beaker-test-kickstart --ks-meta skipx
Comment 6 Raymond Mancy 2014-01-15 21:57:50 EST
http://gerrit.beaker-project.org/#/c/2690/
Comment 10 Nick Coghlan 2014-02-02 23:52:26 EST
This change is included in the Beaker 0.15.3 maintenance release:

http://beaker-project.org/docs/whats-new/release-0.15.html#beaker-0-15-3

Note You need to log in before you can comment on or make changes to this bug.