We use one of templates that you provided in this blog post to deploy Neo4j Casual Cluster in AWS. We did copy-paste template that you provided from the s3 to our project.
Today I found out that AMI which we used in eu-west-1 region not available. Instead there is a new AMI in a template which available by link (http://neo4j-cloudformation.s3.amazonaws.com/neo4j-enterprise-stack-3.5.3.json).
So my question is did anything was changed in a template except AMI? Also is it possible to provide them in a GitHub or something with changes history?
Is there any reason not use new instance types r5 with Neo4j?
So as for that AMI change, I can explain it. I originally published 3.5.3 AMIs and then published that article. In the intervening 2 days, a colleague internally found a small bug in the AMI that affected customers who were launching the AMI in private VPCs with no external IP addresses, and so we fixed the bug and had to issue new AMIs to make sure that they captured the bugfix. Because we had published the cloudformation templates, the thought was that most people were not yet (by timing) coupled to the specific AMI IDs, rather they were coupled to the CloudFormation template URL.
In the CF template, the only things that changed were the AMI IDs, and also I slightly increased the "timeout". A separate problem we've had with our CloudFormation is that every once in a while (maybe 1 time in 20) the deploy fails because the timeout expires. This isn't due to an error in the CloudFormation, it happens when AWS takes too long to provision the EC2 instances! (This we can't control of course). Deploying Neo4j should take 10 minutes or less, but this is only true if AWS instantly gives you a VM when you ask. Sometimes the infinite cloud pool of resources isn't so infinite -- and in fact in some AZs it can fail because AWS doesn't have the space to allocate a new VM, or simply takes too long to get it done!
Typically what we do is build the AMIs, publish the CloudFormation templates, and then publish updates to the Amazon marketplace. The AWS marketplace takes some time to accept the publish and we're in that waiting period right now for 3.5.3 where we have released the software but it's not yet live on the marketplace. I typically wait until everything is live before announcing that a new version is available. Because we had some customers asking for guidance on automating cluster deploys, in this instance we made an exception and published the blog post -- but that in combination with a rapid turn-around bugfix caused the AMI change.
Once the marketplace stuff is published, I'll post an announcement here about the AMI IDs. When you see me post the AMI IDs publicly, that's the point where we're locking them in for a particular version and won't then subsequently pull those AMIs. If we temporarily publish something (i.e. for testing, but not announced) then it's not yet a guarantee. This particular patch level version has just been a bit more complicated than previous due to the interaction of the bugfix and the AWS publishing timeline.
IO1 volumes are specialized kinds of volumes where extra configuration is required. This doesn't have much to do with Neo4j or the CloudFormation templates, it's an oddity of the way AWS has set things up.
If you want to use this particular type of volume, then in the CloudFormation template where the AWS::EC2::Volume is provisioned you need to specify an Iops key and give it a value. This key/value doesn't apply to some other types, so it isn't in the template by default.
I mean that "io1" is in the list of allowed values for VolumeType parameter in a template.
So if I deploy it using CloudFormation console or from AWS MarketPlace (which in turn will open CloudFormation console) then I can choose this type of volume from the list and then I will get an error..
P.S. not sure about case with AWS MarketPlace (coz this template not available there for now)