Skip to content

Instantly share code, notes, and snippets.

@vpavlin
Created September 18, 2015 18:07
Show Gist options
  • Save vpavlin/f46444efd647e0d8a48f to your computer and use it in GitHub Desktop.
Save vpavlin/f46444efd647e0d8a48f to your computer and use it in GitHub Desktop.
Atomic App re-design

Re-architecting of Atomic App

Steps

  1. Create a tool to generate Python classes from the json spec
  2. Drop install, run modules, prepare operations module
  • load - loads Nulecule and creates objects from generated classes, if a component is external, pull and process the source (i.e. whole Nulecule graph tree should be available as objects after load finishes)
  • create_transaction - traverse the graph and generate a list of components representing a serialized graph
  • install - unpack files to disk
  • run - deploy to provider(s) (i.e. loop through component list generated by create_transaction and run provider plugin)
  • stop - stop/undeploy app
  • get_providers - get all available providers for the app
  • get_params - get params with defaults for app
  • get_values - get params values with answers applied

How this solves current problems

As run will be just a cycle through the list of ordered components, we can gather some information from one component and pass it to next one. This solves the problem for docker-compose provider - we can add prepare function which will parse and return content of compose artifact and that will be appended to a global compose content. Once the run reaches last component, it can generate the compose.yaml file and pass it to docker compose binary.

We can easily implement automatic naming and linking of containers for Docker provider.

Implementation of REST API will be simpler because Atomic App will know and recognize whole application without weird recursions and losing context and so on.

Other applications (DA) can reuse generated Python classes, or by calling load only it can work with whole Nulecule application at once (like validation, suggesting params name changes to match external components params names..)

Big portion of code base will need to be rewritten (not sure if this belongs to pros or cons :), which will enable us to add proper unit testing

Application workflow will be much simpler and easier to understand, thus will make it more digestable to wider audience

Challenges

We need to make sure that everything works as it does now, but we already have some tests, so it shouldn't be that hard

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment