Role and Machine scoped variables are not considered when resolving the feed during aquisition

[robpearson]

Rewritten by @droyad:

To reproduce

1. Have 2 different feeds on hand, eg (Feeds-21 and Feeds-41)
2. Have one machine in the role (MyMachine)
3. Create a project that deploys a pacakge from feed #{FeedId} to a role (eg Cloud)
4. Add the following variables to the project
   • Feeds-21 Unscoped
   • Feeds-41 Scope to the role of the step
   • Feeds-41 scoped to MyMachine

When the deployment is run, acquisition chooses Feeds-21.

It should choose Feeds-41 as we know the role/machine at that time.

[abcdeploy]

Hi Rob,

Any idea if this will be fixed in a near future build?

Thanks.

[droyad]

This is unlikely to be fixed until we re-write the deployment pipeline. We don't have any firm plans to do that this year.

The reason is that machines are currently not resolved until the step starts executing, long after acquisition occurs.

[droyad]

Changed this to an enhancement as this is by design

[officeSpacePirate]

This affects K8s deploys in a way that seems to require duplicate deploy processes.

For example, my team hosts K8s clusters in AWS and we use Octopus for all of our deploys. If there is one K8s cluster per AWS region and we use latency based or geolocation based routing for our app URLs across clusters, then each app must be deployed to all targets at the same time. In this case, how do we deploy container images to each target while also referencing an ECR corresponding to the AWS region the cluster is in?

The only solution I have come up with is to have a copy of each "Deploy Kubernetes Containers" step for as many targets need to be deployed to with the feed hardcoded and the step scoped per target instead. This is really cumbersome to maintain, especially when employing a microservices architecture and having a deploy process per app.

Hopefully this gets more priority in the future.