reclass and jinja template

[Stephan de Bot]

Hi Martin,

 
Thanks for you response, and you create work. The way I get the desired output  at this moment is by doing the following:

 
In the common class I do this:

 
applications:
  - resolver
parameters:
  resolver:
    searchpaths: ['b-it.internal']
    nameservers: ['192.168.1.2','192.168.1.3']
    options: []

 
 
And the node looks like this:

classes:
  - common
parameters:
  resolver:
    searchpaths: ['b-it.internal']
    nameservers: ['192.168.1.1']
    options: ['single-request-reopen']
classes:
  - resolver

 
And this is the content of resolver.yml

applications:
  - resolver

 
When I run a salt-call pillar.items I get the  desired output. Not sure if this i a correct approach but it seems to work.

local:
    ----------
    __reclass__:
        ----------
        applications:
            - resolver
        classes:
            - resolver
        environment:
            base
        nodename:
            nlmbux001
    resolver:
        ----------
        nameservers:
            - 192.168.1.1
        options:
            - single-request-reopen
        searchpaths:
            - b-it.internal

 
Met vriendelijke groet, Kind regards,

--------------------------------
    Stephan de Bot

    www.b-it.org <http://www.b-it.org> | stephan at b-it.org <mailto:stephan at b-it.org> 
    Stevensweerterweg 69, Maasbracht, NL, 6051GR
 
 

 
-----Original message-----
From:martin f krafft <madduck at madduck.net>
Sent:Thu 07-30-2015 08:02 pm
Subject:Re: reclass and jinja template
Attachment:digital_signature_gpg.asc
To:Stephan de Bot <stephan at b-it.org>; 
CC:reclass at lists.pantsfullofunix.net; 
Sorry for the late reply.

also sprach Stephan de Bot <stephan at b-it.org> [2015-07-25 11:23 +0200]:
>         nameservers:
>             - 192.168.1.1
>             - 192.168.1.2
>             - 192.168.1.3
>  So the entry on hostlevel does not override the on hosted@ level.
>  When I run the state I get all 3 nameservers  in resolv.conf.

Yes, this is a feature, and I realise that half the world want it
and the other half would prefer if lists were replaced.

So far, I have not found a smart way to let you have both, as I am
limited by YAML syntax on this one. And I really don't want to go
down the path of syntax addons, e.g. hacking such functionality into
names and interpreting the parsed output.

One idea might be to let an empty list clear an existing list, so
that you'd include a helper class after the base class which would
set

  nameservers: []

but this also gets ugly quite fast.

So far, the way I've dealt with this was to have the base class
define "nameservers_base_set" and define "nameservers" per-host and
then either used parameter expansion to seed the per-host list with
the base set, or used some Jinja2 logic to get to the result.

>  When I define the nameserver in reclass in a different way on hosted@ level:
>     nameservers:
>       192.168.1.1
>       192.168.1.2

No you are defining the content of "nameservers" to be a string…

>                   +nameserver 1
>                   +nameserver 9
>                   +nameserver 2
[…]

and when you iterate a string in Python, this is what you get.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"i think, therefore i'm single"
                                                      -- lizz winstead
 
spamtraps: madduck.bogus at madduck.net

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pantsfullofunix.net/pipermail/reclass/attachments/20150804/c3a349cf/attachment.html>