Elasticsearch: degraded instance

AWS will warn you when you have an instance running on degraded hardware. You will get a scheduled retirement date and, on this date, your instance will be switched off.

However, your hardware is likely already compromised. If you’re running Elasticsearch on this hardware you need to decommission the node and create another node.

The steps to do this are:

1. get current status

From outside box:

2. disable shard allocation

3. stop service

sudo service elasticsearch stop

4. terminate the instance via console

5. create a new instance – e.g. with Terraform

6. re-enable shard allocation

7. validate cluster health goes back to green


git rebase: CONFLICT

git rebase master
First, rewinding head to replay your work on top of it…
Applying: using feature branch for now
Applying: building from feature branch
Using index info to reconstruct a base tree…
M file/A
Falling back to patching base and 3-way merge…
Auto-merging file/A
CONFLICT (content): Merge conflict in file/A
error: Failed to merge in the changes.
Patch failed at 0002 building from feature branch
Use ‘git am –show-current-patch’ to see the failed patch

Resolve all conflicts manually, mark them as resolved with
“git add/rm <conflicted_files>”, then run “git rebase –continue”.
You can instead skip this commit: run “git rebase –skip”.
To abort and get back to the state before “git rebase”, run “git rebase –abort”.


Rant on technology and legacy institutional processes

The commercial web has been about since 1995.

  1. Why has it taken 23 years for my accounting software to finally connect to my bank to withdraw statements?

‘cos of damn institutions like the law.

2. Why do I have to click Accept Cookies on every website I go to?

‘cos of damn institutions like the law.


On point 2, stuff was fine until about 5 years ago when some Judge or the Queen realised that cookies existed.



Given the incredible speed of modern computers and networks I shouldn’t have to spend half my time waiting for various computer tasks to complete.

E.g. I’m simultaneously waiting on 3 separate devices for things to load.

  1. MacBook Pro Number 1
    1. for my bank web pages to load AND
    2. for this blog post dashboard to load so I can write this rant about slow computers
  2. Another MacBook Pro: for Terraform to complete
  3. My phone for Spotify to load

Then, waiting for my external Bluetooth speaker and phone to connect.

What EC2 instances available in London?

Seems like a simple question, right?

However, it starts getting a little more intricate when you look a the details. Let’s say I want an m3.medium. Here’s my goto info page:


Cool – these are available.


But lets say I need them for Elasticache.

OK, looking at: https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/CacheNodes.SupportedTypes.html

I can see a cache.m3.medium. But then, reading further on – i.e. the Supported Node Types by AWS Region section – as of the time of posting this blog post, m3 is not supported in EU (London). Nor in EU (Paris).

m4is supported in EU (London). But not in EU (Paris)!

Fortunately, we’re only looking for London.

So, the obvious choice would be an m4.medium. However, scanning back up to the top of the Supported Node Types page the smallest available is a cache.m4.large.

It’s all in the details!


redis – testing connectivity for a server

brew install redis

redis-cli <hostname>




Note, a quick way of testing without installing redis is to use nc. i.e.

You can also do this with curl.