Re: [EXTERNAL] Re: Tenancy is broken

["Fieck, Brennan" <Br...@comcast.com>]

RE: disabling the root tenant being impossible: I'm not sure that there's a specific check for that, it's just that one cannot submit a `PUT` request for it because it cannot be assigned to one of its own children, and the endpoint won't allow a `null` or `undefined` "parentId". A future `PATCH` method would need to look out for that, as well as any other kind of API restructures, added feature etc.

Regarding your other suggestions, it sort of sounds like you're talking about eliminating the concept of active/inactive status, because one would need to disable/reassign/destroy all child tenants and resources prior to disabling. That's conceptually not much different from deleting the tenant, except that I guess such configurations could be left intact for future use. But a returning tenant would by default have no (active) children and no (active) resources or child resources, so you're almost starting from scratch anyway. I don't mean to split hairs, but if that's the route we take it may be much easier to enforce and support moving forward to just prefer deletion to a "disable" option.
________________________________________
From: Nir Sopher <ni...@qwilt.com>
Sent: Wednesday, December 12, 2018 12:45 AM
To: dev@trafficcontrol.apache.org
Subject: [EXTERNAL] Re: Tenancy is broken

Hi,
IIRC, when tenancy was added, the plan was that a user of an inactive
tenant cannot do anything.
A user of its active parent can manipulate the inactive tenant resources.
I thought it was even covered by a UT, but anyhow, as I see it, any other
current behavior should be fixed.

See [NS] inline per your suggestion

On Wed, Dec 12, 2018, 01:59 Fieck, Brennan <Brennan_Fieck@comcast.com wrote:

> There are massive issues with how 'active' on a tenant is treated. The
> discussion has been had on this github issue:
> https://github.com/apache/trafficcontrol/issues/2732 but I will try to
> summarize.
>
>
> First problem: An inactive tenant can be neither modified in any way
> (including re-activating them) nor deleted. Likewise any Delivery
> Services/origins/whathaveyou that were assigned to them become totally
> immutable and indestructible. Less shockingly, no resources
> (DSs/origins/whathaveyous) can be assigned to the inactive tenant.
>
>
> Second problem: An inactive tenant can still manipulate its child tenants,
> and the resources of those child tenants.
>
>
> Third problem: The child of an inactive tenant can still manipulate
> itself, its resources, and any of its descendants or its descendants'
> resources.
>
>
> This has sort of raised a debate about what tenancy truly is/ought to be
> and what active/inactive means/ought to mean.
>
>
> The first issue to tackle is: Do we even care about inactive tentants?
> Maybe instead we just say "you first must delete or reallocate all
> resources belonging to the tenant's descendants, then all descendants
> themselves, then the tenant's own resources, then delete the tenant. There
> is no 'inactive'.
>
>
> If we decide to proceed with active/inactive tenants (I personally like
> the idea), then my fix for the above problems is to enforce this behavior
> regarding tenancy:
> 1. If the ultimate goal is to have everything respect tenancy (or even
> maybe if not), then I see no reason why a user belonging to an inactive
> should be able to log in at all
>
[NS]+1

>
> 2. When a tenant is made inactive, all of its descendants must recursively
> be made inactive as well - the reverse (enabling a tenant enables its
> descendants) should not be true.
>
[NS] I would suggest a validation instead of automatically change the
descendants clients. Notifying the user that the de-activation operation
failed due to an active descendant and let him consciously deal with that.
The reason that such behavior was not added in the first place was the need
to maintain the "no active descendant of inactive" assumption in multiple
location.
For example, if you are moving a tenant from on parent to another, you need
to add a validation.
A future change in this area may easily add a bug there.

Going in this direction, we can additionally consider not to allow tenant
to become inactive if it has an active delivery-service.
This addition might be in conflict with #4 in your list - we need to choose
product wise what is the desired behavior.,


> 3. When adding a new tenant, its active/inactive state defaults to that of
> its immediate parent (if #2 is enforced there is no need to recurse up the
> ancestry tree), and it should be impossible to add an active tenant to an
> inactive parent.
>
[NS] True, as well as for tenant parent change.

>
> 4. An active tenant should be able to manipulate all of its resources, all
> of its descendants and all of its descendants' resources, regardless of the
> active/inactive state of any of those descendants
>
[NS] Agree

>
> 5. Modifying the 'root' tenant to be inactive should not be allowed
>
[NS] Should be the already true

>
>
> All together these will eliminate all three problems and ensure no
> resources or tenants ever wind up indestructible or immutable. I also think
> they're rather sensible.
>