Product Documentation
StyleBook configuration
View PDF

Dependency detection

January 8, 2024
Contributed by: 
C

Components in a StyleBook can refer to properties or sections of other components in the same StyleBook. Components are complete blocks by themselves and they may not be written in the same order that they have to be ran. The StyleBook compiler checks the order in which the components are written and then runs them in a logical order.

Example:

components:

  -

    name: lbvserver-comp

    type: ns::lbvserver

    properties:

      name: mylb

      ipv46: 10.102.190.15

      port: 80

      servicetype: HTTP

 -
    name: lb-sg-binding-comp

    type: ns::lbvserver_servicegroup_binding

    condition: $parameters.create-binding

    properties:

      name: $components.lbvserver-comp.properties.name

      servicegroupname: $components.sg-comp.properties.servicegroupname

-
    name: sg-comp

    type: ns::servicegroup

    properties:

      servicegroupname: mysg

      servicetype: HTTP
<!--NeedCopy-->

In the above example, there are three components defined - lbvserver-comp, lb-sg-binding-comp, and sg-comp. When you run this StyleBook, the lbvserver-comp is first created. The lb-sg-binding-comp refers to lbvserver-comp properties, but it cannot be created next though it is the second component defined in the StyleBook. This is because the lb-sg-binding-comp also has a dependency on the sg-comp which is yet to be created. As a result, the compiler reorders the components so that the dependencies of a component are resolved by the time a component is created, and runs this reordered list of components. The order of execution of the above StyleBook is: lbvserver-comp, sg-comp, and lb-sg-binding-comp.

Thus, the author of a StyleBook need not worry about the correct order of the components. The components may appear in any order. The compiler computes the correct order of execution of the components based on how the components refer each other. Note that this applies to substitutions and outputs sections as well.

Cyclic Dependencies

Since a component may refer another component, it is possible that the cycle of dependencies may be introduced in the definition of the StyleBook. For example, if component A refers to a property defined in component B, which again refers to a property defined in component A. This kind of dependency is called cyclic dependencies. Cyclic dependencies cannot be resolved automatically. The author of the StyleBook manually corrects the StyleBook definition to eliminate such cyclic dependencies. The compiler will be able to identify cyclic dependencies - if they exist, and report it.

The following example shows a cyclic dependency of components:

components:

  -

    name: lbvserver-comp

    type: ns::lbvserver

    properties:

      name: $components.lb-sg-binding-comp.properties.name

      ipv46: 10.102.190.15

      port: 80

      servicetype: HTTP

  -

    name: lb-sg-binding-comp

    type: ns::lbvserver_servicegroup_binding

    condition: $parameters.create-binding

    properties:

      name: mylb

      servicegroupname: $components.sg-comp.properties.servicegroupname

  -

    name: sg-comp

    type: ns::servicegroup

    properties:

      servicegroupname: mysg

      servicetype: $components.lbvserver-comp.properties.servicetype
<!--NeedCopy-->

In the above example, there are three components: lbvserver-comp, lb-sg-binding-comp, and sg-comp. The lbvserver-comp component depends on lb-sg-binding-comp, lb-sg-binding components. And, these components depend on sg-comp. The sg-comp component depends on lbvserver-comp. Here, a cycle of dependencies among these components is formed and this cannot be resolved automatically. As a result, this StyleBook cannot be ran. The StyleBook compiler detects this and prevents the StyleBook from being imported into NetScaler Console.

Dependency detection
January 8, 2024
Contributed by: 
C
January 8, 2024
Contributed by: 
C

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.