Helm namespaces

I’ve been creating my own Helm chart for an application. I initially tried to shoe-horn the namespace into the values.yaml and then pull it through into the service and deployment yaml files. Turns out that isn’t a good way to do it, which is kind of obvious when you think about it. It’s a common scenario for an application to exist multiple times in the same cluster, separated by namespace.

When you install the chart for the first time, provide the name of the namespace which already exists.
Here’s the steps from Creating a new Helm Chart to deploying and then upgrading it.

helm create nginx-webapp
#tweak the values.yml
cd nginx-webapp/
kubectl create namespace whatthehack-webapps2
helm install --name nginx-webapp . --namespace whatthehack-webapps2
#make a change to the application
helm upgrade nginx-webapp .
kubectl get svc --all-namespaces
helm upgrade nginx-webapp .

Kubectl apply annotation for rollback history

The great thing about Kubernetes is the declarative nature of the YAML files you write to describe your deployments. You can always be sure that your deployment will match what’s in your YAML. More often than not, i’m hacking something together and submitting my deployments to Kubernetes incrementally by changing my YAML file and then performing a kubectl apply command. As such, I don’t get a lot of information in my history. EG. if I run kubectl rollout history deployments then the change-cause is just empty.

I’ve been going through a hack, where rollbacks have become a critical part of the exercise – so felt this needed more exploration. I wanted to start getting an annotation coming through to serve as a quick change log. Here’s how I did it.
kubectl apply -f contentweb.yaml
kubectl annotate deployment content-web kubernetes.io/change-cause="my release note" --record=false --overwrite=true
kubectl rollout history deployments

Home security automation done right – blog series

I’ve been putting some time into perfecting my smart home, documenting each area in it’s own blog post

Arlo, Hue, IFTTT, Stringify and Logic Apps – Home security automation done right pt1
[Link Pending blog post completion]
Selection of the right hardware component and software toolsets for the best smart home automation.

Smart Video archive with Arlo – Home security automation done right pt2
[Link Pending blog post completion]
Getting around the Arlo premium plan with your own Cloud, then opening up other opportunities for getting smart with the video.

Google Assistant broadcast api remotely – Home security automation done right pt3
Remotely issuing (broadcast) commands to the Google home assistant devices by API

Google Assistant broadcast api remotely – Home security automation done right pt3

I have 7 Google assistant devices in my house, I was an Amazon Echo fan early on but ran both side by side and went with Google. One of the things I use a lot on the Google devices is music playback from Spotify. It can synchronise playback on several or all of the devices using Speaker Groups.

The Problem

So the Google Assistant API doesn’t allow you to initiate commands. I want to initiate Spotify to play on several devices at a certain volume, automatically via API.

Eg. I can from my Google home device say “hey Google turn on all the lights” or remotely from my phone I can manually start a broadcast of “turn off all my lights”. What I’m unable to do it from a 3rd party system (eg Stringify or Logic Apps) is call the API and issue the commands.


There isn’t really many viable workarounds for this either, I’ve “googled” this one pretty hard. I think the best option is having a device positioned near a Google assistant that will play a recording of my voice issuing a command… Which isn’t ideal by any means, but does work.
However I do have the complications of choosing the right device that can be remotely initiated reliably for this specific purpose.


So focussing on the hardware constraint, I need something reliable and ideally something I already own that won’t cost a fortune to run. I happen to have a spare PAYG phone SIM card lying around in an old Windows Mobile 640 device – good enough.

I recorded my voice onto the device with an app in the Windows App store, set it as my text notification tone and sent it a text. The result, it worked great. However, although I don’t use this number much I still get odd texts from spammers.
I need a dedicated way to play the audio clip. Now if this was Android, I’d use Tasker and would be finished already. Windows Mobile presents some problems, I don’t want to write an app that would poll so it needs to use a sms or a phone call to play the audio clip. Windows Mobile prevents developers that aren’t telecoms providers from reading sms messages on the phone, but I am able to assign a specific ringtone to a specific contact…. 😉

I now need to acquire a dedicated phone number to automatically call my phone from, in order to play this specific ringtone. Introducing Twillio. It will allow me to programmatically sent sms or do clever stuff with telephony. My use case is simple, initiate an outbound call to a specific number.

Twilio Integration

The first thing to do, is to register for Twilio, and pay for a number (this is $1 a month, and I can’t see another way around the problem). I then have to write some code to talk to the Twilio API in order to initiate the phone call.

Here’s the Azure Function I’ve written, you can find it in GitHub here: https://github.com/Gordonby/OutgoingPhoneCall

From an HTTP request, I can now have remote access to my Google Assistant at home 🙂

This post is part of a series of posts in my home automation journey, check out the rest here;

Azure availability zones vs availability sets

Availability Zones in Azure ensure VM/service placement on physically separate infrastructure with no shared dependencies (power/cooling/etc). This leads to a design decision for new Azure projects as well as prompting a revisit to designs that use Availability sets.

I’m not going to list all the services that support Zones, or the regions that support them as this is constantly changing. It’s summarised here: https://docs.microsoft.com/en-us/azure/availability-zones/az-overview However, at the time of writing: Not all Regions support Availability Zones, if your desired region does not support them yet then it is likely on the roadmap but it does limit your options for the time being. The first Azure Services to support Zones were VM’s, Disks, Public IP’s and Load Balancers – clearly geared up for the IaaS market. Since then many of the PaaS services have onboarded to support Zones.

Availability SLA

I think it’s fair to say that if the Region you’re deploying to supports Availability Zones, then use them! VM’s in Availability Zones offer a higher SLA that Availability Sets: 99.99% VS 99.95% and many of the Azure PaaS services are now being enabled to work in Zones by being “Zone Redundant”.


Zone’s are supported by VM Scalesets, which mean you don’t need to explicitly place them, however for normal VM’s you are required to specify the Zone. When using Availability sets, Azure would automatically set placement of the VM based on the Availability Set properties.

Disk storage

Availability Zone’s require Managed Disks, wheras VM’s in Availability Sets could choose between Managed or Unmanaged. I won’t go into the pro’s and con’s on disk storage now but my rule of thumb is that most VM’s should use Managed Disks.


Availability Zone’s do carry an extra cost when compared to Availability Sets, not for the VM Compute cost but for the bandwidth. This is charged at $0.01 per GB in/out of the Zone. It’s a pretty minimal charge when you think about it, and really it’s the price for the extra 0.05% in the SLA. Still, it’s worth including when you’re designing your architecture.