Array field usage in schema


#1

Is there any example of array field usage in schema? How to fill it and use it?


#2

You define an array with square brackets with elements separated commas. The data within is treated like a string.

A schema array element filled out like [foo, bar, baz]
Results in a Ruby array ["foo", "bar", "baz"] when the array is instantiated.

This hold for numbers too, so:
[1,2,4]
Results in a Ruby array ["1", "2", "4"].


#3

Thanks a lot @ewannema

And about multi-dimentional arrays?


#4

Interesting, we haven’t had a need for multi-dimensional arrays. Do you have an example of what you are trying to accomplish?

We have situations where we instantiate an instance based upon some identifier (say group name) via $evm.instantiate(‘path’) and then reference the values there, so in a way we have an array of instances each containing an array of values, but not exactly a multi-dimensional array.

I would probably look for alternative approaches, but you may be able to put a JSON object in the field and parse it in your code if you really needed complicated data structures.


#5

In our infoblox/F5 integration code, we list lots of informations relatives to application type.

Lets say we have 2 applications to deploy. Our ‘application’ tag can be appA or appB.
Each application have specific networks information, depending on environment, application type, etc.

so appA should be deployed on a vm with these informations:
In production env:

  • public vlan vlanAPub, infoblox range name rangeAPub, infoblox cidr cidrAPub
  • admin vlan vlanAAdmin, infoblox range name rangeAAdmin, infoblox cidr cidrAAdmin
  • private vlan vlanAPriv, Infoblox range name rangeAPriv, infoblox cidr cidrAPriv

other env:

  • etc …

Same for F5: an Application A should be associated with F5 pools, depending on environment.

Finally, it would be useful to have a multidimensional array , containing all applications and all informations about applications needed for F5 , so we have not to modify Infoblox/F5 integration code anymore.


#6

We have solved this a few different ways.

  1. With an external application that manages data (nicest way IMO).
  2. With data embedded in instances named significantly. “Easiest”, but this has limitations because of instance names and trying to cram too much stuff in here.
  3. With data embedded in instances using data only in the schema. This requires $evm.instance_find and some trickery to get all inherited instances which you can then filter by the data they contain.

For approach #2 you could maybe do something like:

config = $evm.instantiate("/Configuration/NetworkInfo/#{app_code}-#{env_code}-#{vlan_name}")

infoblox_range = config['range_name']
infoblox_cidr = config['other_value']

#7

Thanks. Approach #2 works fine for us.


#8

Must i instantiate it in every state method when i need it? Or is there a way to instantiate it at the begining and use it in every state method?


#9

We have found that configuration instances return very quickly because they do not require any Automate methods to run. Because of this and because it makes the code easier to reason about, we do tend to instantiate them whenever needed.

However, if you want to keep information around then the “Saving Variables Between State Retries” section in this book https://pemcg.gitbooks.io/mastering-automation-in-cloudforms-4-2-and-manage/content/state_machines/chapter.html may be useful.


#10

ok.

should i delete it when not needed anymore, to prevent memory leaks?


#11

I can not really speak to the details of the internal implementation, but generally you would not need to. Once that code is done being used it should be automatically removed from memory.