CR for deployment branch (commit e3ad701) - Atidot/platform GitHub Wiki

Platform.Deployment

Placeholder strings

Based on the way you're using string literals it seems like some of them are placeholders. Consider writing placeholderSecret = "tutorials/MyFirstTutorialSecret" and placeholderName = "hello-world", this would make it easier to understand which strings are permanent parts of the code and which are temporary.

Booleans in Deployment and DeploymentM.

I notice you're using a lot of booleans in these types, as well as in the functions you've defined here (e.g. in kiss and nsss). It would help if it was clarified by comments what these mean. If they keep track of whether a computation failed, maybe even define a type like so:

data DeploymentResult = DeploymentSuccess | DeploymentFailure.

This is structurally identical to the Bool type but it is much more clear what it means in the context of DeploymentM.

Platform.Deployment.Interpreter.AMI

Type signatures

Berko mentioned to me that we should write our type signatures to enable easier commenting and Haddock documentation. E.g. your line 105 reads

scpW :: MonadIO io => Text -> Text -> Text -> io ()

Instead, everything after the :: should be aligned like so:

:: MonadIO io
=> Text
-> Text
-> Text
-> io ()

Variable names

In scpW I can follow most of the variable names except for pdns. I can understand what it does by reading the function, but pdns is too abbreviated for me to understand.

runAMI's run helper function

Line 67 reads next True. For the same reasons I mentioned with Platform.Deployment, it isn't 100% clear to me what this means.

Platform.Deployment.Interpreter.Terraform

Long lines

Many of the lines from line 80 to 102 are very long. Consider splitting these along multiple lines, possibly using helper functions. There are a couple of pairs of functions, like updatePrep and updateExec, or attachDockerFolder and attachDockerSecret, which duplicate code. Refactoring these might help with readability.

Platform.Deployment.Interpreter.Terraform.Template

It's not clear to me where the values on lies 25-26 come from. Was this a configuration you used for testing? Or is this permanently part of the default?

Platform.Deployment.Interpreter.Utils

Possible runtime exceptions

You call Data.Text.tail in getPublicDns and getInstanceId. This will generate a runtime exception if the input has a length of zero. Specifically, Data.Text.tail calls Prelude.error if it gets a length-zero input.

The functions getPublicDns and getInstanceId are both called in Platform.Deployment.Interpreter.AMI.runAMI (although getInstanceId is commented out). They are both called within a Control.Monad.Catch.bracket pattern at the beginning of runAMI. So a length-zero input to getPublicDns, for instance, will cause runAMI to jump into its fini' cleanup routine and then re-raise the exception. Is this the behaviour we want? Or should getPublicDns watch for a length-zero value and return a suitable output in that case? It's an honest question, I'm not sure what is the better choice here.

Comment

  • Placeholder strings - done
  • Booleans in deployment/M - done. I removed the booleans completely. It was technical debt because of wrong design assumptions. Originally we thought that it will alert about failures during run and then we will manage that, but it doesn't hold any real meaning because the application creates a terraform file instead of running executable that runs terraform inside.
  • AMI type signatures - Reformatted all type signatures with more than 2 arguments
  • Variable names - Pdns stands for ‘public DNS’, renamed it
  • Booleans in runAMI - were removed
  • Terraform Long lines - I refactored a bit, these functions modify the terraformExtraConfig, which is updated using state monad. They are similar but update different fields. I tried to remove the duplication a bit, and reformatted other code pieces.
  • Lines 25-26 in terraform/template.hs.These are also placeholders I refactored them better. The TerraformExtraConfig needs tuples of (disk mapping,EBS volume names), so the first ones can be found in the links provided below in haste, I coded only some of them (Here), the second ones needs to be created before running the code, manually, in AWS management console. I hardcoded an example ebs volume I created with my user. They are needed to tell terraform how to attach devices correctly (here (more details in the links below), I made an entry in the readme ) that explains all of these prerequisites, read it and tell me if it’s understandable. links
  • Regarding runAMI, I am aware of the exception that might run there. The code in getPublicId could be written better, the expected behavior is fine because if one of these functions fail on tail we want the program to halt because this means that the program ran wrong. But dont worry about it now. This is the first version of the interpreter I wrote. It suffers from all sorts of design issues that made me discard it. This can be probably be deleted, but I left it so that we will have an example of how to run the terraform simultaneously with the deployment, and not offline (after) it.