Imagine the following tenant tree: - root -- tenant A (2 users, 4 delivery services) --- tenant A.A (5 users, 3 delivery services) -- bad tenant B (6 users, 2 delivery services) --- bad tenant B.B (3 users, 4 delivery services)
Because tenant B is misbehaving, you can currently do this manually: 1. set the 9 tenant B* users to "disallowed" <-- this will prevent those users from logging in so they can't do anything 2. set the 6 tenant B* delivery services to inactive <-- this will exclude the delivery services from the cdn snapshot i believe It would be nice if simply flipping tenantB active flag to false would essentially do what I described above. Not literally but would have the same effect. Jeremy - On Wed, Dec 12, 2018 at 12:45 AM Nir Sopher <[email protected]> wrote: > 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 <[email protected] > 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. > > >
