Hi,
We added a Linux based ssh octopus worker to allow running bash scripts independent of a target and move our other deployment workloads to octopus.
As soon as we did this the existing PowerShell steps that were set to run on the octopus server started failing because they were running now on the Linux SSH worker. We tried adding a new pool but hit a licensing restriction with our plan.
Should workers not be chosen based on their capabilities?
Was it intentional to make SSH workers a more premium feature?
Thanks for getting in touch, sorry to hear that you had this experience.
We are increasing the awareness in product about just what adding a worker to the default pool will do, as we (belatedly) realised that we don’t call out just what adding a worker to this pool will do; which is disable the inbuilt worker and take over all run on server tasks. The GitHub issue is here if you want to have a look .
The objective of grandfathering our old licensing model was to make it as fair as possible to our customers, while also balancing the need to keep Octopus commercially viable. It was an intentional decision to restrict worker pools to the newer licensing models, but it’s not one we made lightly. Grandfathered licenses give you license renewals at a great price and includes new features, updates and bug fixes, but it doesn’t necessarily include the same benefits/limits as our newer licenses. Workers and worker pools are an entirely new paradigm against ‘run on server’ that is only enabled (at varying levels) with the new licensing scheme.
Having said that I would recommend reaching out to our sales team directly on as there may be something we can do to assist here (sales@octopus.com).