1.1.0

Fixes and Features

• allowedSizes patched in ui and arm template through build
• number of nodes in UI is now controlled through allowedValues
• binpack map to distribute storage accounts evenly is now also generated based on number of allowed nodes
• can now pick the vm size for the kibana machine
• sshPublicKey is now a securestring
• all the public bits now get a DNS name (lb-, kb-, jb-*)
• The kibana url, public loadbalancer url and jumbox ssh info are now clearly output on the template.
• normalized some naming conventions of the resources e.g all data node resource start with data-node-
• we now always simply deploy to the resource of the resource group, deploying in a different location then the resource group location feels like an edgecase
• fixed default value for loadbalancer in UI
• use newer api version for storage accounts
• remove shield empty defaults
• Kibana size picker in UI used a label that mentioned client nodes
• recommended and default datanodes are now controlled through the build process
• Switched to recommending DS_v2 instances
• Add support for way more VM Sizes, the only ones we do not support now are:
  • GS, more compute heavy left out for now
  • D14, D5_v2, D14_v2, DS14, DS5_v2, DS14_v2. Since these allow 32 disks attached and our templates can only do 16 at the moment.
  • D15_v2, DS15_v2 can support 40 attached disks but our template only goes to 16

Provisioning reseliency

• vm-disk-utils is now loaded from our repository.
• Java installation failed quite often do to checksum failures post download, built in retries including a final nuclear clear cache and install again on the final 3rd retry.
• Sometimes mdadm failed to be installed completely, similary we now retry. Have not seen failures since.
• mdadm creation of the raid0 disk suffered from race condition and sometimes the attached disks were in use or "busy". Added a fix found here. Sent a PR to azure quickstart with these fixes too here Azure/azure-quickstart-templates#1978
• Quite often waagent crashes due to timeouts [1] and then eventhough the elasticsearch install scripts runs to completion noone is letting azure know causing the deployment to get stuck and eventually timeout (1h+). We now forcefully start this service (noop if already running) throughout and at the end of the deployment. This has helped tremendously.

Testing

Started with casperjs based testing of our UI (development version), it can login to azure and verify we did not break the UI from loading. In the future I would like to be able to write UI scenarios and it will fill the controls and assert the output on the console.