Automation

 View Only
last person joined: 7 days ago 

Ask questions and share experiences about Apstra, Paragon, and all things network automation.
  • 1.  commit script question

    Posted 01-01-2017 08:01

    Hi 

     

    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:

    1. 

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

     

    2. 

    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

    statements.

     

    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.

     

    thanks


    #delete
    #commitscript
    #vxlan
    #vlan


  • 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.

    /doug

     



  • 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.