Forum Discussion

CraigD1_147916's avatar
CraigD1_147916
Icon for Cirrus rankCirrus
Nov 23, 2016

Import irules that have different content but same name

As I am trying to get all of my LTMs into BigIQ, just to manage certs and backups, when I go to import an LTM that has an irule with the same name but different content from a previous LTM, the BigIQ asks me which I'd like to keep, the LTM copy or the BigIQ copy. I assume that if all of my irules had different names, this wouldn't be an issue, but if I tell it to keep the LTM copy, do I have to be concerned of it overwriting the differing irule on the other LTM?

 

application delivery
BIG-IQ

3 Replies

Sort By
  • Kyle_Oliver's avatar
    Kyle_Oliver
    Icon for Employee rankEmployee
    Nov 24, 2016

    If you were to deploy changes from BIG-IQ, the version on the iRule that is in the BIG-IQ database would be compared against what is on the BIG-IP that you are deploying to. BIG-IQ would show the difference as part of the evaluation process prior to deploy.

     

    In your workflow above, the iRule version that is in the BIG-IQ database would be the version from the last BIG-IP you imported. If you tried to deploy to a BIG-IP that was discovered prior to that one, BIG-IQ would show the iRule as needing to be updated.

     

  • CraigD1_147916's avatar
    CraigD1_147916
    Icon for Cirrus rankCirrus
    Nov 24, 2016

    Thank you. So I am safe to import and keep the latest version from whichever LTM I import last, as long as I never deploy for BigIQ, correct? I just want to be sure that I'd have to deliberately make such a policy push and that even so, as you mention above, I'd be warned of the difference.

     

    At this point, I don't plan to use BigIQ to make config changes anyway but would like to use it as a read-only repository of LTM configs and certs etc.

     

    Is there a way to disable the ability to push config changes from BigIQ so that I don't need to be concerned that it may happen inadvertently?

     

  • eey0re's avatar
    eey0re
    Icon for Cirrostratus rankCirrostratus
    Dec 09, 2016

    I just asked a similar question to support. This behaviour in BIG-IQ CM seems completely unsuited to real world deployments.

     

    There are two main scenarios where objects with the same name legitimately should have different configuration on different appliances:

     

    • In production where the object refers to a resource in a datacentre (e.g. pool members local to the region) and you want to be able to have other objects (e.g. a VS) be consistently configured in all locations - including pool name references.

       

    • Where an application release is graduating through development and test environments (or parallel development environments working on different releases) and the configuration change should not prematurely be deployed to other environments.

       

    Due to this, and the way CM gives quite a limited range of configuration compared to BIG-IP, I can't see us using CM for configuration deployment at all.