Changes between Version 10 and Version 11 of Usage/UserDocumentation


Ignore:
Timestamp:
07/10/12 17:48:15 (8 years ago)
Author:
sil
Comment:

Removed text about templates, and merged it to the dedicated page.

Legend:

Unmodified
Added
Removed
Modified
  • Usage/UserDocumentation

    v10 v11  
    337337}}}
    338338
    339 
    340 
    341 = CMT Templates =
    342 
    343 CMT offers a powerful feature, powered by templates.
    344 With these templates you're able to let CMT generate various kind of files, like configuration files or reports about your clusters.
    345 
    346 The syntax of the templates in CMT is based on Django templates, therefore the documentation of the [https://docs.djangoproject.com/en/dev/topics/templates/ Django template language] can be useful as a reference.
    347 Django templates are usually meant for web pages, but since we use it for our configuration files some functionalities have been added for CMT-specific needs.
    348 By extending the Django template language, it has been made possible to:
    349  * Define an epilogue script
    350  * Pre-load datasets from database
    351  * Set a path to write the output to
    352 
    353 To make use of these functionalities you have to start your template with
    354 
    355 {{{
    356 {% load cmt_client %}
    357 }}}
    358 
    359 and store the file in your template-directory as `<name>.cmt`
    360 
    361 
    362 == Epilogue script ==
    363 
    364 Some configuration files need to be reloaded by the program when they are modified.
    365 Or maybe some other things should be done to activate the new configuration.
    366 This is where an epilogue script comes in.
    367 You can write the epilogue script in the template itself, between the ''epilogue'' and ''endepilogue'' tag:
    368 
    369 {{{
    370 {% epilogue %}
    371 # this epilogue-script will restart the DHCP server
    372 /etc/init.d/dhcp3-server restart
    373 {% endepilogue %}
    374 }}}
    375 
    376 
    377 == Pre-load datasets from database ==
    378 
    379 You may define collections of objects to use in your templates.
    380 These collections can be defined with a filter, and assigning it to a variable name to use.
    381 
    382 {{{
    383 # syntax for the use-tag is:
    384 #  use <entity> with <filter> as <variable name>
    385 {% use network with 'name=lisa consoles' as net_consoles %}
    386 {% use interface with 'network__name=lisa consoles' as ifaces_consoles %}
    387 }}}
    388 
    389 In the example two collections are assigned to a variable:
    390  * `net_consoles` will contain the network with the name ''lisa consoles''
    391  * `ifaces_consoles` will contain all interfaces in that network
    392 
    393 Now these collections can be used in the template, to build a part of a DHCP config-file for example:
    394 
    395 {{{
    396 group { # Start Console network
    397     option domain-name "{{net_consoles.domain}}";
    398 
    399     {% for iface in ifaces_consoles %}
    400     {% if iface.hwaddress != None %}
    401     host {{iface.fqdn}} {
    402         hardware ethernet {{iface.hwaddress}};
    403         fixed-address {{iface.ip}};
    404         option host-name "{{iface.fqdn}}";
    405     }
    406     {% endif %}
    407     {% endfor %}
    408 } # End Console network
    409 }}}
    410 
    411 
    412 == Set a path to write the output to ==
    413 
    414 To save the result of your template, you can store the output to a file.
    415 This can be done by using the ''store''-tag, and give it a path:
    416 {{{
    417 # syntax for the store-tag is:
    418 #  store <outputpath>  as output
    419 {% store /etc/dhcp/dhcpd.conf as output %}
    420 }}}
    421 
    422 In this example the result will be written to `/etc/dhcp/dhcp.conf`.
     339More information about how to write your own templates can be found at a [wiki:Usage/TemplatingDocumentation separate page about the template language].