Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable untenanted projects to be deployed to tenanted deployment targets #2722

Closed
michaelnoonan opened this Issue Sep 8, 2016 · 27 comments

Comments

@michaelnoonan
Copy link
Contributor

michaelnoonan commented Sep 8, 2016

(Same logic applies to Accounts)

We made a decision during the beta phase of Octopus 3.4 to make a clear distinction between tenanted deployment targets and untenanted deployment targets. The main reasoning was that we shouldn't accidentally leak dedicated-tenant variables and deployments onto shared servers.

This decision prevents a scenario where you want to deploy tenanted applications onto a server, and use another project to deploy a common component like a telemetry agent.

The workarounds available are:

  1. Add another tentacle to the server (one tenanted, the other untenanted) but this adversely affects licensing
  2. Create a dummy tenant and make the common project use that dummy tenant.

We should enable this situation in a nicer way. Current options we're considering are:

  1. Use the project > settings > multi-tenant deployments option as a way to modify the deployment target calculation when starting a deployment.
  2. Add another setting to the deployment targets so they can define how they participate in tenanted/untenanted deployments.

Source: http://help.octopusdeploy.com/discussions/questions/9090-tenanted-un-tenanted-and-deployment-target-licence-double-use

Source: http://help.octopusdeploy.com/discussions/questions/9061-feature-use-account-for-tenant-and-non-tenant-deployments

Source: http://help.octopusdeploy.com/discussions/questions/9031-tennant-and-non-tennant-deploys-to-the-same-server

Source: https://secure.helpscout.net/conversation/344338204/0/

Update 30/05/2017: The implemention for this issue is in progress

Our working plan is to address this by replacing the Tenants section on the Machine settings with something like the following:

machine-tenants-exclude

Selecting the 2nd or 3rd option will cause the Tenant selector you see today to be displayed.

machine-tenants-include

Machines currently assigned to tenants will default to option 2: Include only in tenanted deployments.

Selecting option 3: Include in both tenanted and un-tenanted deployments will do just what you would expect.

@zentron

This comment has been minimized.

Copy link

zentron commented Sep 8, 2016

Also need to keep in mind\test what this means for permissions

@TIllingworth

This comment has been minimized.

Copy link

TIllingworth commented Sep 14, 2016

This is currently having a huge impact on licence use, I know there is a workaround however the time required to configure our current deployment process would be very large. Are a large number of people experiencing this issue?

@tothegills

This comment has been minimized.

Copy link

tothegills commented Sep 14, 2016

Add another setting to the deployment targets so they can define how they participate in tenanted/untenanted deployments.

Could use machine policy

@TIllingworth

This comment has been minimized.

Copy link

TIllingworth commented Sep 23, 2016

An alternative might be to only have a single licence usage when you have multiple connections to the same machine, though this may not work with the design currently in place and allowing a deployment target to be configured as tenanted and untenanted specifically may be a better option.

@ohTHATaaronbrown

This comment has been minimized.

Copy link

ohTHATaaronbrown commented Sep 29, 2016

Add another customer to your list who want the ability to mix tenanted and non-tenanted work on deployment targets, please.

Our use case is this:

  • we have a whole bunch of operations-related deployment projects that are tenant-agnostic, but operate on machines that have tenanted applications installed as well as on common, non-tenanted servers (like common database servers, etc).
  • we also have deployment projects that we want to make tenant-aware. (these currently use our own in-house tenant layer on top of octopus, which was in place before the new first-class tenant support, but we want to move to the first-class new shiny stuff).

The proposed dummy tenant workaround is cumbersome in large environments.

We need to be able to deploy our back-end operations projects to the same deployment targets as we deploy our tenanted applications to. Ideally without having to make the operations deployments "tenanted".

@ohTHATaaronbrown

This comment has been minimized.

Copy link

ohTHATaaronbrown commented Sep 29, 2016

I also have a desire to have some steps in a deployment run only once per machine, while other steps run once per tenant per machine. I don't see this as possible in the current tenant implementation. Am I missing something?

@graemechristie

This comment has been minimized.

Copy link

graemechristie commented Oct 5, 2016

+1. Again we have too many Tentacles and Projects for the Dummy Tenant Hack or Running multiple tentacles per server to be feasible.

@TIllingworth

This comment has been minimized.

Copy link

TIllingworth commented Oct 7, 2016

Also, not to be picky but technically doesn't this break the way licences work since you'd end up using multiple licences for the same deployment target. Is that good enough to categorise this as a bug?

@tobylo

This comment has been minimized.

Copy link

tobylo commented Oct 11, 2016

I won't repeat what people before me has written, but here is another customer that is affected negatively by this descision. Sadly, neither of the workarounds are feasible solutions in our case.

@juliank

This comment has been minimized.

Copy link

juliank commented Nov 3, 2016

I would also like to chime in on this issue. In our case, we would like to gradually move some of our projects over to using tenanted deployments. However, some of the projects are "composite", with several projects deploying to the same deployment target, and not all of the projects should us a tenanted model. Using the proposed dummy tenant solution appears to be a bit cumbersome.

We also have the scenario where we would like to use tenants for "feature deployments" in our dev environment (we test features from many different branches in dev, where we would like to deploy these to different sites on the same deployment target). For our main deployment line however (which is dev-test-production), the deploys should be un-tenanted.

@michaelnoonan

This comment has been minimized.

Copy link
Contributor Author

michaelnoonan commented Nov 4, 2016

Thanks so much for taking the time to weigh in on this issue. I can't give you an estimate of when this will be completed, but I did want to let you know this issue is high on our radar. Enabling everyone to fully adopt multi-tenant deployments in Octopus is important to us.

Hope that helps!
Mike

@espenwa

This comment has been minimized.

Copy link

espenwa commented Dec 8, 2016

We are also eagerly awaiting being able to deploy a mix of tenant and non-tenant-based projects on the same targets. The version-tag on this issue says 3.4 - have you any information about the currently targeted release?
(Tenants/Channels are very nice features, and we plan to use them in-house for keeping multiple versions in production simultaneously in an enterprise environment).

@michaelnoonan

This comment has been minimized.

@MortenChristiansen

This comment has been minimized.

Copy link

MortenChristiansen commented Jan 11, 2017

"Card not found.

This card may be on a private board. If someone gave you this link, they may need to invite you to one of their boards or teams."

@lonevvolf

This comment has been minimized.

Copy link

lonevvolf commented Jan 11, 2017

Yes, it would be nice to know the status here - it still references 3.4, which is a bit in the past; :)

@vanessalove

This comment has been minimized.

Copy link
Contributor

vanessalove commented Jan 11, 2017

@MortenChristiansen @lonevvolf Not all the links that we provide are for public consumption such as private support tickets as source documents and also links to our internal trello. They are to link to our systems and allow us to provide the context we need for our processes.

The was added to a roadmap in a trello so the aim is to be completed in Q1 for this year.

While it says release/3.4 in a tag that is also a tracking tag of ours and nothing to do with intended milestones. It was for a feature released in that version.

@mackayj

This comment has been minimized.

Copy link

mackayj commented Feb 14, 2017

@vanessalove Any update on the timeline? We currently have to edit the environment every time we want to deploy to our mixed tenanted / non-tenanted servers

@michaelnoonan

This comment has been minimized.

Copy link
Contributor Author

michaelnoonan commented Feb 17, 2017

Hi @mackayj - we don't have a fixed date to ship this logic change. Please be assured it is definitely on our roadmap and we will post updates in here once it gets to the top of the stack. Hope that helps!

@MJRichardson MJRichardson self-assigned this May 26, 2017

@bjammin

This comment has been minimized.

Copy link

bjammin commented May 29, 2017

It's been 3.5 months since the last update in this thread, and nearly 9 months since this was first raised. In that time there have been 9 major version releases that could have included this.

Is it really still on the roadmap?

@MJRichardson

This comment has been minimized.

Copy link

MJRichardson commented May 29, 2017

Hi folks,

Update: The implemention for this issue is in progress

Our working plan is to address this by replacing the Tenants section on the Machine settings with something like the following:

machine-tenants-exclude

Selecting the 2nd or 3rd option will cause the Tenant selector you see today to be displayed.

machine-tenants-include

Machines currently assigned to tenants will default to option 2: Include only in tenanted deployments.

Selecting option 3: Include in both tenanted and un-tenanted deployments will do just what you would expect.

Permissions

We are also intending to make a change to the permission model to correspond with the above. We are going to change the way the permissions for teams without tenant scope are handled.

Currently:

  • Team without tenant scope: The permissions for a team not scoped to any tenant(s) apply ONLY to un-tenanted machines. This team's permissions do not apply to tenanted machines.

  • Tenant-scoped team: The permissions for a team team scoped to tenant(s) apply ONLY to the machines scoped to those same tenant(s). This team's permissions do not apply to un-tenanted machines.

After this change:

  • Team without tenant scope: The permissions for a team not scoped to any tenant(s) will apply to both tenanted and un-tenanted machines. This aligns with the behaviour of teams not scoped to any environments/projects - it's like a wildcard.

  • Tenant-scoped team: The permissions for a team team scoped to tenant(s) apply ONLY to the machines scoped to those same tenant(s). This team's permissions do not apply to un-tenanted machines. This is the same behaviour as today.

This change will align tenant scoped permissions with how environment/project scoped permissions are interpreted. We also believe this new behaviour corresponds with the way most people grant permissions.

The end result is:

  • Grant MachineView to a team with the scope Environments: Production: All members of this team can view machines in the Production environment. This is common when you have certain people managing all machines in an environment.

  • Grant MachineView to a team with the scope Environments: Production and Tenants: A: All members of this team can view machines in the Production environment allocated to tenants A. This is common for 3rd-party self service access.

  • Grant MachineView to a team with the scope Environments: Production and Tenants: A, B, C: All members of this team can view machines in the Production environment allocated to tenants A B or C. This is common when you have certain people managing machines on behalf of certain tenants.

@bjammin

This comment has been minimized.

Copy link

bjammin commented May 30, 2017

Thanks Michael, this looks like a good solution (at least for my requirements) and I appreciate the update.

@MJRichardson

This comment has been minimized.

@mackayj

This comment has been minimized.

Copy link

mackayj commented Jun 19, 2017

@MJRichardson

Card not found.

This card may be on a private board. You may be able to view it by logging in.

Been looking forward to this update for a while now, can you give us a rough ETA?

@KasperHoldum

This comment has been minimized.

Copy link

KasperHoldum commented Jun 26, 2017

We're also waiting for this feature to be able to roll out tenanted deployments mixed with untenanted deployments. Any ETA?

@MJRichardson

This comment has been minimized.

Copy link

MJRichardson commented Jun 29, 2017

@mackayj @KasperHoldum
Thanks for your patience folks. This will ship with Octopus 3.15, which if everything goes according to plan will be released next week.

@lock

This comment has been minimized.

Copy link

lock bot commented Nov 24, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.

@lock lock bot locked as resolved and limited conversation to collaborators Nov 24, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.