View Only


This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.

  • 1.  commit script question

    Posted 01-01-2017 08:01



    I have an IP fabric based on qfx5100 with VXLAN/EVPN.


    I wish to make a commit script so that my users simply need to add a vlan name and ID and then commit.

    the script will create all the EVPN/VXLAN related config parts. all vlans configured on the box will support vxlan.


    I see two options:


    I can see that if I loop through the VLANS and emit transient-changes.  this keeps the candidate config clean.



    I can loop through and emit perm changes.  This is better for the end users but my concern with this is, that if the user then deletes a vlan via the CLI and commits , I havent seen a how a commit script gets notified of this deletion, it seems that it just doesnt appear in the candidate config passed to the commit script?  Im concerned that I will end up with stranded config



    the commit script logic seems great for enforcing or adding, but not so great when trying to delete code based on the deletion of  a trigger piece of config.


    very new at this scripting process so any strategy pointers would be great.




  • 2.  RE: commit script question
    Best Answer

    Posted 01-03-2017 10:31

    You indicated you thought permanent config changes were "better for the endusers", but I'm not sure why.   I'll assume it's just because they're accustomed to a certain behavior that doesn't include appending " | display inheriance"


    It sounds like you're on the right track. Either of the 2 options you listed will require some amount of retraining for anyone making vlan changes. If that's a correct inference, you might want to just consider using an approach where you create/update/delete a custom apply-macro with your required minimal data, then have your commit script read that group and do everything else as transient config changes.  


    That way, the apply-macro data is still "explicit" in the configuration -- It could be completely self-contained in a custom configuration group. Users can still see/update those items in your new custom configuration group *and* the commit script is free to act on changes to those apply-macros and emit all of the appropriate transient config.  


    Just a thought.



  • 3.  RE: commit script question

    Posted 01-10-2017 10:52

    Hi Doug, thanks


    thats exacty what I did, the user simply adds the apply-macro <macro> with the required parameters, and the commit generates transient changes.


    works a treat.