Conditionally control where Acquire Package step executes

[Robert_Livermore]

Using Octopus Server 2020.5.6, I am trying to figure out how to control when the acquire package step is scheduled.

The project will attempt live updates using a blue/green pattern. Two tentacles one with Blue machine role the other Green. A project variable prompted at deployment time indicates which tentacle to install from and the other will be removed, assuming the install works. Therefore each step has variable run conditions to control which tentacle the install or remove is done on.

Given the following step Structure when executed, the condition correctly skips steps, however the Acquire Packages is sequenced between 4.1 and 5 and downloads to both Blue and Green tentacles. Ideally, if blue is used then Acquired step packages should only go to the Blue node. Acquire Packages does not honor the variable conditions set on parent or child nodes.

1. InspectBlue
   1.1 ChildStep…
2. InspectGreen
   2.1 ChildStep…
3. RepairBlue
   3.1 ChildStep…
4. RepairGreen
   4.1 ChildStep…
5. InstallBlue
   5.1 Script…
   5.2 Package…
   5.3 Docker Run…
6. InstallGreen
   6.1 Script…
   6.2 Package…
   6.3 Docker Run…
7. RemoveBlue
8. RemoveGreen

The Conditional Documentation describes a Package Required option to control Acquire step. But this condition is missing on parent step. Or at least that is where I expected to find it.

My ideal solution would be to use an Assert template step which I can sequence into the project selected which packages to acquire now

[phil.stephenson]

Hi Robert,

I’m sorry for the delayed response here. Thanks for your question.

I spoke to a colleague about this one, and I think your assertion is correct: The acquisition of packages happens regardless of whether you have a variable run condition set. I can see how this might not seem intuitive, but I believe this works as it was designed.

Another way you could model this blue/green deployment though, rather than using run conditions, is to instead setup separate Blue/Green environments. Your targets could then have the same role, but rather than prompting for a variable at deployment time, you just select which environment (blue or green) you’d like to deploy to. You could probably even simplify your deployment process in that case too and you wouldn’t need separate steps for blue and green respectively.

Are these services behind a load balancer that gets adjusted after deployment? If you’re controlling traffic via your load balancer, is there any reason you need to actually “remove” the services like in steps 7/8?

Thanks,

Phil

[Robert_Livermore]

Hi Phil,

Thanks for the response

I reviewed the blue/green solutions in the documentation realized I needed to double either the environment, tenant or project step to objects. Unfortunately, tenants tags and environment are automated with other enterprise services. So I stuck on the project step implementation.

Can you add a note for me to the design’ s user story. Scheduling Acquiring Packages step without honouring the step conditional results in docker pull error on one node. Set up one docker on a Windows Server core release 1809 and the second on Windows Server release 20H2. A docker pull of a container image with based 20H2 ends in a invalid image error. The inline container upgrades are not supported on 1809. If I can schedule the Acquiring Packages step later the docker pull error is circumvented. This is the reason to remove services from Acquiring Packages step. Remember the goal is a live update and migration from older OS to a newer one.

One additional observation. On deployment if the Install steps are excluded on the opposite colour then Acquiring Packages is sequenced in a functional order. I can work around the problem, but this add a human factor to the deployment which will be error prone.

Yes the some of the tentacles span a parameter networks. This results in the use of dynamic package implementation.