More attributed graphs

These examples are shamelessly stolen from a recent post on r/devops.

Developer A makes a change to cookbook A. Cookbook B and environment cookbook C have dependencies on cookbook A. How do I know when/if to upgrade this dependency on B and C?

Same as above, but for terraform module versions. And how do I know which environments have been updated?

Both of these examples are very similar to the schema drift problem so their expression as an attributed graph follows the same pattern. Each node has a version and is linked to its dependencies. When versions change the links are invalidated and need to be reconciled. In general, any kind of version dependency is trivial to express with attributed graphs.

Our jenkins envs are currently autoscaling EC2 images with a custom AMI. As we make changes to that AMI, new instances roll out and eventually the old AMI becomes “useless” and I’d like to clean it up to save on costs. How to keep track of which AMIs are still being used in a generic way?

This one is a little more interesting because modeling it has a dynamic component. There is an AMI node and every other AMI in the system links to it, i.e. A0: {} -> AMI: {}. The nodes don’t have attributes because they’re not going to be relevant for how I’m modeling the problem but I can imagine adding attributes. Jenkins will also be expressed as a node and from the above description the graph will look like J: {} -> A0: {} -> AMI: {}. Now let’s say we add a new AMI. The new graph will look like J: {} -> A0: {} -> AMI: {} <- A1: {}. At this point nothing is actually broken because we haven't invalidated anything. The constraint we are dealing with is that dangling nodes like A1 are potentially useless and need to be cleaned up. In this case what we actually want to do is link J to A1 and clean up A0 but that's a higher level constraint/process that needs to be programmed. What the graph structure does is let us query the graph to find dangling AMIs.

New Centos base AMI gets released, and we want to rebuild all of our AMIs. How to track which AMIs have been rebuilt, in which environment, and when we can deprecate the old AMIs?

This follows the same structure as the previous problem. Expressing it as an attributed graph will look the same except the AMI links will have 3 nodes instead of 2, i.e. A0: {} -> C0: {} -> AMI: {}. The process can be similar to what we did above or we can solve the problem with attributes and invalidation. If we use attributes then an invalidation of the Centos node will have a version attribute and it becomes another instance of the schema drift problem.

Same as above, but for docker images. New version of debian base image, for example.

This again has the same general structure so the AMI solutions still work.

Same as above, but for home-built base images. Say we have our own programming-language base image that we use as the basis for our apps. Now app images have 2 "parent" dependencies, our base image and the debian base image. How to know when to rebuild these, and what the current state of that is?

I hope the pattern is clear at this point. The structure of the problem itself doesn't really matter because whether it is docker containers or AMIs the solution is the same, i.e. express the constraints as a graph and then look for dangling nodes and update the dependency graph accordingly.