default

Istio: Canary upgrade of Operator from Istio 1.8 directly to 1.10

Istio announced it will support upgrades jumping directly from 1.8 to 1.10, instead of forcing an intermediate upgrade through 1.9. In this article, I will show you how to do a canary upgrade from a 1.8 operator to 1.10 operator without affecting end user traffic.  We will incorporate the new 1.10 concept of revision tags Istio: Canary upgrade of Operator from Istio 1.8 directly to 1.10

Istio: Upgrading from Istio 1.7 operator without revision to fully revisioned control plane

Istio 1.7 has the ability to do canary upgrades for revisioned control planes and operators, but if you did your initial installation without the ‘revision’ flag, then you’ll need to apply these settings. In this article, I will show you how to go from an non-revisioned 1.7.5 Istio operator and control plane to a 1.7.5 Istio: Upgrading from Istio 1.7 operator without revision to fully revisioned control plane

Istio: Upgrading from Istio 1.6 operator without revision to 1.7 fully revisioned control plane

Istio has the ability to do canary upgrades for revisioned control planes, but it was only in 1.7 that the Operator itself got  support for the ‘revision’ flag. In this article, I will show you how to go from an non-revisioned 1.6.6 Istio operator and control plane to a 1.7 revisioned operator and control plane Istio: Upgrading from Istio 1.6 operator without revision to 1.7 fully revisioned control plane

Ansible: pulling values from nested dictionaries when path might not exist

It is typically straightforward to resolve Ansible errors where a simple variable used within an action is not defined.  However, when dealing with nested dictionary variables in your Ansible tasks, it can become more complex because not only can the leaf be missing, but also any of the parent container paths. For example, the nested Ansible: pulling values from nested dictionaries when path might not exist