FAQ
Hi,
We are planning to use SaltStack for our inhouse LDAP based Configuration
Management system. Our system is designed for mostly networking related
operation. Where operator add lots of networing configuration e.g vlan, ip
and routes.
We are thinking that to use Pillar to store these user added configuration.
We will write some code to generate the desired pillar data and also update
if need.

From the documentation we can find that following command to refresh the
pillar data to minion
salt '*' saltutil.refresh_pillar

*But how to write the state module to get the delta of change so the
execution module also get notification of delta and apply the change ?*

*Example* - user add one vlan and add 2 ip address to this vlan.Next day he
add one more ip address to the yesterday added vlan. In this case our
system should only add the newly added ip address not try to add all three
ip address.

Any help appreciated.

Brs
Suvendu

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Stephen Spencer at Oct 6, 2014 at 9:20 pm
    1. LDAP

    I would recommend creating an LDAP replica that has the sole purpose of
    handling the salt bits. Make it a minion and deploy an execution module
    that will monitor a FIFO that will receive the syslog messages from LDAP
    (use one of the unused LOCAL facilities) Configure your LDAP software to
    emit replication-related messages to the aforementioned syslog facility.

    Note: By themselves, pipes (FIFOs) block writes (and their upstream
    feeders) if they are not read. This is particularly problematic for
    single-threaded feeders as they will get stuck. rsyslogd is multi-threaded
    as is syslog-ng. I believe, at best, even multi-threaded logging systems
    will just drop a message that a thread cannot receive, but at least the
    whole program won't freeze!

    This can be mitigated by creating a (daemonized) python process that
    buffers the messages from the pipe and feeds them downstream as they are
    asked for. You could use UNIX or IP sockets (depending on your future
    plans) . Depending on how many systems you manage, the frequency changes
    are entered and the potential for down-time for the minion software, there
    might be a call for some kind of on-disk buffering (sqlite or ldb
    perhaps). If traffic is low enough you might be able to ignore this issue
    altogether and have a scheduled job that runs a module to queries the LDAP
    tree for any stanzas that have a modifyTimestamp* that is within a

    The execution module will fire salt events in response to seeing
    replication messages that it retrieves on the part of your tree that houses
    the DNs of the systems in question. It can parse out the hostname bits and
    send them with the event message to make it easier on the other end.

    2. Salt Master

    Write a reactor to receive these messages and execute a state or execution
    module targeted at the minion running on the salt master. It would then
    rebuild the on-disk pillar data with the complete set of parameters for the
    target minion's interfaces. As part of the reactor, you could also execute
    a state that reconciles the current minion's configuration (available via
    grains), determine what needs to be added/removed and issue the appropriate
    salt calls to make the changes.

    It would need to reconcile the contents of the LDAP stanza with what is
    deployed and add or remove any entries on the target minion that are no in
    sync. This bit would connect to LDAP and retrieve the IP address
    information for the host referenced in the event and rebuild the host's
    pillar. If you're comfortable with relatively-immediate changes being made
    to the target minion, you can also have the reactor immediately call out to
    the target minion to run its network interface configuration management
    state.

    Just a top-of-the-head flow of how I might address such a situation.

    Actually kinda sounds fun!

    Best,

    -S


    On Mon, Oct 6, 2014 at 4:09 AM, Suvendu Mitra wrote:

    Hi,
    We are planning to use SaltStack for our inhouse LDAP based Configuration
    Management system. Our system is designed for mostly networking related
    operation. Where operator add lots of networing configuration e.g vlan, ip
    and routes.
    We are thinking that to use Pillar to store these user added
    configuration. We will write some code to generate the desired pillar data
    and also update if need.

    From the documentation we can find that following command to refresh the
    pillar data to minion
    salt '*' saltutil.refresh_pillar

    *But how to write the state module to get the delta of change so the
    execution module also get notification of delta and apply the change ?*

    *Example* - user add one vlan and add 2 ip address to this vlan.Next day
    he add one more ip address to the yesterday added vlan. In this case our
    system should only add the newly added ip address not try to add all three
    ip address.

    Any help appreciated.

    Brs
    Suvendu

    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    You know, I used to think it was awful that life was so unfair. Then I
    thought, wouldn't it be much worse if life were fair, and all the terrible
    things that happen to us come because we actually deserve them? So, now I
    take great comfort in the general hostility and unfairness of the universe.

    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Stephen Spencer at Oct 6, 2014 at 9:57 pm
    (dangling paragraph 3)...
    particular amount of time.

    Ugh. I need to not try to compose mailing list messages while doing other
    things. If my poor excuse for writing is mangled beyond understanding,
    please do not hesitate for clarification. I'm going to go Over There and
    be ashamed now.

    -S

    On Mon, Oct 6, 2014 at 4:20 PM, Stephen Spencer wrote:


    1. LDAP

    I would recommend creating an LDAP replica that has the sole purpose of
    handling the salt bits. Make it a minion and deploy an execution module
    that will monitor a FIFO that will receive the syslog messages from LDAP
    (use one of the unused LOCAL facilities) Configure your LDAP software to
    emit replication-related messages to the aforementioned syslog facility.

    Note: By themselves, pipes (FIFOs) block writes (and their upstream
    feeders) if they are not read. This is particularly problematic for
    single-threaded feeders as they will get stuck. rsyslogd is multi-threaded
    as is syslog-ng. I believe, at best, even multi-threaded logging systems
    will just drop a message that a thread cannot receive, but at least the
    whole program won't freeze!

    This can be mitigated by creating a (daemonized) python process that
    buffers the messages from the pipe and feeds them downstream as they are
    asked for. You could use UNIX or IP sockets (depending on your future
    plans) . Depending on how many systems you manage, the frequency changes
    are entered and the potential for down-time for the minion software, there
    might be a call for some kind of on-disk buffering (sqlite or ldb
    perhaps). If traffic is low enough you might be able to ignore this issue
    altogether and have a scheduled job that runs a module to queries the LDAP
    tree for any stanzas that have a modifyTimestamp* that is within a

    The execution module will fire salt events in response to seeing
    replication messages that it retrieves on the part of your tree that houses
    the DNs of the systems in question. It can parse out the hostname bits and
    send them with the event message to make it easier on the other end.

    2. Salt Master

    Write a reactor to receive these messages and execute a state or execution
    module targeted at the minion running on the salt master. It would then
    rebuild the on-disk pillar data with the complete set of parameters for the
    target minion's interfaces. As part of the reactor, you could also execute
    a state that reconciles the current minion's configuration (available via
    grains), determine what needs to be added/removed and issue the appropriate
    salt calls to make the changes.

    It would need to reconcile the contents of the LDAP stanza with what is
    deployed and add or remove any entries on the target minion that are no in
    sync. This bit would connect to LDAP and retrieve the IP address
    information for the host referenced in the event and rebuild the host's
    pillar. If you're comfortable with relatively-immediate changes being made
    to the target minion, you can also have the reactor immediately call out to
    the target minion to run its network interface configuration management
    state.

    Just a top-of-the-head flow of how I might address such a situation.

    Actually kinda sounds fun!

    Best,

    -S


    On Mon, Oct 6, 2014 at 4:09 AM, Suvendu Mitra wrote:

    Hi,
    We are planning to use SaltStack for our inhouse LDAP based Configuration
    Management system. Our system is designed for mostly networking related
    operation. Where operator add lots of networing configuration e.g vlan, ip
    and routes.
    We are thinking that to use Pillar to store these user added
    configuration. We will write some code to generate the desired pillar data
    and also update if need.

    From the documentation we can find that following command to refresh the
    pillar data to minion
    salt '*' saltutil.refresh_pillar

    *But how to write the state module to get the delta of change so the
    execution module also get notification of delta and apply the change ?*

    *Example* - user add one vlan and add 2 ip address to this vlan.Next day
    he add one more ip address to the yesterday added vlan. In this case our
    system should only add the newly added ip address not try to add all three
    ip address.

    Any help appreciated.

    Brs
    Suvendu

    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    You know, I used to think it was awful that life was so unfair. Then I
    thought, wouldn't it be much worse if life were fair, and all the terrible
    things that happen to us come because we actually deserve them? So, now I
    take great comfort in the general hostility and unfairness of the universe.


    --
    You know, I used to think it was awful that life was so unfair. Then I
    thought, wouldn't it be much worse if life were fair, and all the terrible
    things that happen to us come because we actually deserve them? So, now I
    take great comfort in the general hostility and unfairness of the universe.

    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsalt-users @
postedOct 6, '14 at 9:09a
activeOct 6, '14 at 9:57p
posts3
users2

2 users in discussion

Stephen Spencer: 2 posts Suvendu Mitra: 1 post

People

Translate

site design / logo © 2022 Grokbase