> Not sure what's required in the Go to ensure that tenancy can't be turned
off.

And yes, it's pretty easy in Go, too. Just a matter of removing those query
bits, and calls to IsTenancyEnabled.


On Tue, Jan 8, 2019 at 10:09 AM Rawlin Peters <[email protected]>
wrote:

> I believe we essentially agreed to make tenancy required in 3.0 (and
> have done so via a DB migration), but there is still a dependency on
> the use_tenancy parameter in the codebase. So until we can go through
> and fix all those places that check the use_tenancy parameter, we
> can't really get rid of it altogether. In the meantime though, we
> could potentially disable PUT/DELETE for that specific parameter in
> the API so that you can't just "disable tenancy" (air quotes because
> there are endpoints now that already make the assumption that tenancy
> is always enabled), but it would be best to just go through and fix
> the code that depends on that parameter.
>
> - Rawlin
> On Tue, Jan 8, 2019 at 8:59 AM Fieck, Brennan <[email protected]>
> wrote:
> >
> > +1 down with optional tenancy.
> >
> > Changes in Go would be similar I think - just remove the check for
> enabled tenancy and the code that handles the disabled case.
> > (I'd also like to submit for consideration the idea of re-writing Perl
> endpoints instead of updating them)
> > ________________________________________
> > From: Jeremy Mitchell <[email protected]>
> > Sent: Tuesday, January 8, 2019 8:55 AM
> > To: [email protected]
> > Subject: [EXTERNAL] Tenancy no longer optional?
> >
> > I feel like we discussed this and agreed that moving forward tenancy
> should
> > no longer be optional in TP/TO but I can't find the email so maybe it was
> > just a dream. :) (fyi at Comcast, we've been using tenancy for over 1.5
> > years i think)
> >
> > Currently, you can toggle tenancy on/off using a parameter (use_tenancy).
> >
> > This adds complexity to the code which I think can lead to errors in
> logic.
> > Also, if tenancy is turned off it falls back to role checking and/or
> > ds/user assignment. ds/user assignment isn't even supported in TP and
> role
> > checking goes against the idea of roles/capabilities.
> >
> > Therefore, i'd like to suggest that in the next release of TC (4.0.x?),
> > tenancy is required and cannot be turned off. Of course, if you still
> don't
> > want to use tenancy, you can assign all users/delivery services to the
> > "root" tenant which in essence turns off tenancy for all users.
> >
> > Making tenancy required would require stripping out all conditions like
> > this from the Perl:
> >
> >
> https://github.com/apache/trafficcontrol/blob/master/traffic_ops/app/lib/API/Job.pm#L179
> >
> > or simply going to the source of that method and make the necessary code
> > change to prevent turning it off:
> >
> >
> https://github.com/apache/trafficcontrol/blob/master/traffic_ops/app/lib/Utils/Tenant.pm#L256
> >
> > Not sure what's required in the Go to ensure that tenancy can't be turned
> > off.
> >
> > Jeremy
>

Reply via email to