Tracking state

[salty2011]

After using TMF modules it would definitely benefit from some sort of state tracking capability. Example if you make a change in the name of a resource that exists, TMF assumes the resource does not exist because it cannot resolve the name.

A suggested approach would be to do something similar to what terraform does by having a statefile that would record the object id, name and resource type in a file. This would provide TMF the ability to edit existing resources even though the name may have changed.

[johannesvwgs]

Hi @salty2011, sorry for the late response ...
You can use the oldNames property to rename an already existing resource. https://github.com/ATVWGS/tenant-management-framework#261-general-properties

I already thought about caching/tracking resources, but more for faster resolve times when reloading / activating a configuration.

[salty2011]

@johannesvwgs all good.

Not sure I follow , would have though loading cached information would be quicker than querying an api. Wouldn't you need to make multiple calls to get a full definition of the object. ie for an access package you would need to do this for package and policies and resolve all the related resources for the package and policies it consumes.

Guess the other benefit it does allow for checking config drift, ie we defined config, deployed it and then changes are made outside of the code. Yes I know thats bad and thats partly a process problem but its a common issue all parties deal with.

[johannesvwgs]

@salty2011 I think I expressed myself incorrectly. You are right. Caching objects/resources makes absolute sense. I was also thinking about such a feature. Any idea how we could realize something like that?

[salty2011]

Yeah been thinking about this one, no matter the approach think there will be bit of work to implement.

Initial thoughts on a mvp, though would need to spend more time going through the code

• When defining config we would need to have an alias for the object, ie CA rule, Group etc
• When the config is applied it stores the object id's from Azure output in a json file along with the alias
• The internal functions that exist today for resolving names to object id's could be retrofitted to look at a statefile for existing matching alias and then resolve the config of the object id, then do a compare against the defined config vs whats actually set or if the alias doesn't exist its defined as new config to then create the object etc.

Oversimplifying the above a little but thats the gist of it.