+1
On 7/12/18, 1:58 PM, "Rawlin Peters" <rawlin.pet...@gmail.com> wrote:
+1 on setting null tenants to "root" when tenancy is disabled and
"unassigned" when tenancy is enabled.
If we set null tenants to "unassigned" when tenancy is disabled and
enable tenancy after the migration, those tenants now only see
"unassigned" stuff rather than *everything* like they saw before (i.e.
if some things were assigned tenants and some weren't). So they'd then
be forced into *using* tenancy, which we probably shouldn't require.
Setting null tenants to "unassigned" when tenancy is already enabled
seems fine to me because those tenants shouldn't be seeing tenantable
stuff anyways.
- Rawlin
On Thu, Jul 12, 2018 at 12:36 PM Jeremy Mitchell <mitchell...@gmail.com>
wrote:
>
> Ok, just so i'm clear. On clean install or upgrade, in seeds.sql (or
> wherever) create a new tenant called "Unassigned" with parent=root.
>
> If use_tenancy = 0 (off):
>
> find all users where tenant = null and set tenant = root
> find all dss where tenant = null and set tenant = root
> find all origins where tenant = null and set tenant = root
>
> ^^ if tenancy is currently disabled, then setting everything to root will
> have no real impact but if/when tenancy is turned on, you'll want to audit
> the tenants of each resource....or you could leave everything as root
hence
> essentially disabling tenancy even when it's turned on :)
>
> If use_tenancy = 1 (on):
>
> find all users where tenant = null and set tenant = unassigned
> find all dss where tenant = null and set tenant = unassigned
> find all origins where tenant = null and set tenant = unassigned
>
> ^^ this allows you to easily find resources to assign the proper tenant
to.
>
> Part of me thinks, set all null tenants to unassigned regardless of
> whether use_tenancy
> = 0 or 1
>
> Jeremy
>
>
>
>
> On Thu, Jul 12, 2018 at 12:12 PM, Dan Kirkwood <dang...@apache.org> wrote:
>
> > Along those lines, there are currently no constraints in the db to
> > enforce that everything has an assigned tenant. I'd like to change
that.
> >
> > Currently, it's possible to have tenancy turned on but still have NULL
> > tenant_id on a user, deliveryservice, or origin. That leads to
ambiguous
> > situations that can be painful to handle in code. Here's what I'd like
to
> > suggest:
> >
> > If the use_tenancy parameter is OFF (0), set the tenant to ROOT for any
> > item without an assigned tenant. If ON, create a new tenant
> > ("unassigned"?) and assign any NULL tenant ids to that instead -- this
> > allows the admin to easily find the stray ones and assign them
> > appropriately. Once all those are assigned, we can add the
constraints
> > to the db to enforce tenancy. Then, we can do away with the code that
> > supports the use_tenancy flag and simplify the Traffic Ops code.
> >
> > Thoughts?
> > -dan
> >
> > On Thu, Jun 21, 2018 at 8:04 AM Dewayne Richardson <dewr...@apache.org>
> > wrote:
> >
> > > +1 I think giving reasonable defaults and making the role/capabilities
> > > feature available makes for it's awareness as well.
> > >
> > >
> > > -Dew
> > >
> > > On Sat, Jun 16, 2018 at 9:18 PM Dave Neuman <neu...@apache.org> wrote:
> > >
> > > > I'll admit I am not super close to this problem so I don't
understand
> > it
> > > > well but, from what I have read, I tend to agree with Jeremy. If we
> > are
> > > > going to have roles/capabilities we need to just incorporate them
into
> > > the
> > > > system and be done with it. We should have able to provide
reasonable
> > > > defaults and reasonable ways for people to do things that makes it
> > > tenable.
> > > >
> > > > On Fri, Jun 15, 2018 at 9:45 AM Jeremy Mitchell
<mitchell...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > regarding tenancy:
> > > > >
> > > > > @Nir is right. If you don't feel like using tenancy, then you give
> > all
> > > > your
> > > > > users tenant=root. so tenancy is easy to sidestep if you're not
> > > > interested
> > > > > in using it.
> > > > >
> > > > > regarding roles:
> > > > >
> > > > > here are our current roles:
> > > > >
> > > > > admin (priv level=30)
> > > > > operations (20)
> > > > > portal (15) <-- terrible name for a role btw. probably my fault
> > > > > federation (15)
> > > > > steering (15)
> > > > > ort (11)
> > > > > read-only (10)
> > > > > disallowed (0)
> > > > >
> > > > > ^^ in this world, it is your role's priv level that determines
what
> > you
> > > > > can/cannot access
> > > > >
> > > > > when roles/capabilities are introduced our roles will look like
this:
> > > > >
> > > > > admin (all capabilities)
> > > > > operations (the capabilities required to at a minimum to reproduce
> > > > current
> > > > > access level of priv level=20. capabilities yet to be determined)
> > > > > portal (the capabilities required to at a minimum to reproduce
> > current
> > > > > access level of priv level=15. capabilities yet to be determined)
> > > > > federation (the capabilities required to at a minimum to reproduce
> > > > current
> > > > > access level of priv level=15. capabilities yet to be determined)
> > > > > steering (the capabilities required to at a minimum to reproduce
> > > current
> > > > > access level of priv level=15. capabilities yet to be determined)
> > > > > ort (the capabilities required to at a minimum to reproduce
current
> > > > access
> > > > > level of priv level=11. capabilities yet to be determined)
> > > > > read-only (the capabilities required to at a minimum to reproduce
> > > current
> > > > > access level of priv level=10. capabilities yet to be determined)
> > > > > disallowed (no capabilities)
> > > > >
> > > > > ^^ in this world, it is your role's capabilities that determine
what
> > > you
> > > > > can/cannot access. if you're not interested in a "complex
permissions
> > > > > framework" as @Rob calls it :) , you really have to do nothing and
> > the
> > > > > access level of your users should not change (assuming we define
the
> > > > proper
> > > > > capabilities for each role).
> > > > >
> > > > > sooo...if in TC 3.0, we make both (tenancy and
roles/capabilities) an
> > > > > integral part of the system we can, like rob said, simplify a
bunch
> > of
> > > > > code. it's hard enough to explain access control/permissions to
> > people.
> > > > > having to explain 2 ways is almost impossible imo :)
> > > > >
> > > > > and yes, @Rob shims could be added to TP and/or the TO API to
handle
> > > both
> > > > > ways but again, more complexity=more bugs, etc. IMO we just need
to
> > > move
> > > > > forward towards the new approach and leave the old behind...
> > > > >
> > > > > Jeremy
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Jun 14, 2018 at 11:39 PM, Nir Sopher <n...@qwilt.com>
wrote:
> > > > >
> > > > > > Hi,
> > > > > > I'm with Jeremy on that.
> > > > > > The "use_tenancy" flag came to allow simple transition to the
> > > tenanted
> > > > > > world:
> > > > > > On the transition, the TC owner should adjust all tenancies,
most
> > > > > > importantly create a "root tenant" admin, and only then put the
> > > > > use_tenancy
> > > > > > flag on.
> > > > > >
> > > > > > For 3.0 I believe that tenancy should become mandatory -
transition
> > > > > period
> > > > > > done.
> > > > > > A TC that does not need tenants, should just put all elements
under
> > > the
> > > > > > root tenant. No need to maintain two pathes in the code....
> > > > > >
> > > > > > We can do the same for "role/capability" - adding a global knob
> > just
> > > > for
> > > > > > the transition.
> > > > > >
> > > > > > Nir
> > > > > >
> > > > > > On Thu, Jun 14, 2018 at 9:38 PM, Robert Butts <r...@apache.org>
> > > wrote:
> > > > > >
> > > > > > > >will the self-service stuff rob butts is working on be
affected
> > in
> > > > any
> > > > > > > way? Will self-service truly be turned off via a parameter?
> > > > > > >
> > > > > > > What I'm working on, change integrity, shouldn't be affected
by
> > > > turning
> > > > > > off
> > > > > > > tenancy/roles/capabilities.
> > > > > > >
> > > > > > > And we shouldn't turn off the API-visible parts of what I'll
be
> > > > doing:
> > > > > DS
> > > > > > > snapshots, server snapshots, etc.
> > > > > > >
> > > > > > > We should be able to turn off the complex permissions system
for
> > > > > > > self-service, while still retaining safe change integrity via
the
> > > > > > timestamp
> > > > > > > system.
> > > > > > >
> > > > > > > >it would be nice if TC 3.0 made tenancy / roles &
capabilities a
> > > > > > > requirement
> > > > > > >
> > > > > > > Requiring tenancy/roles/capabilities would certainly make the
> > code
> > > > > nicer,
> > > > > > > but I'm afraid it'll make the software much more difficult to
> > use,
> > > > for
> > > > > > > users who want an internal CDN, and have no need for a complex
> > > > > > permissions
> > > > > > > framework.
> > > > > > >
> > > > > > > @mitchell852 Is it possible to add GUI shims in Traffic
Portal,
> > > > and/or
> > > > > > API
> > > > > > > helpers, to make the interface pretend like
> > > > tenancy/roles/capabilities
> > > > > > > don't exist? E.g. to grant all permissions and the root
tenant to
> > > all
> > > > > > users
> > > > > > > on user-creation, if the "use_self_service" config flag is
set?
> > So
> > > > all
> > > > > > the
> > > > > > > code can keep working the same way, but people who don't need
> > > > > > > tenancy/roles/capabilities can still have the existing simpler
> > > > > interface?
> > > > > > > How difficult would that be?
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jun 14, 2018 at 12:18 PM, Jeremy Mitchell <
> > > > > mitchell...@gmail.com
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I like the idea but what will it really mean to turn off
> > > > > > > use_self_service.
> > > > > > > > I know it will mean tenancy will be disabled and API
> > permissions
> > > > > won't
> > > > > > be
> > > > > > > > checked against a user's capabilities, but will the
> > self-service
> > > > > stuff
> > > > > > > rob
> > > > > > > > butts is working on be affected in any way? Will
self-service
> > > truly
> > > > > be
> > > > > > > > turned off via a parameter?
> > > > > > > >
> > > > > > > > IMO it would be nice if TC 3.0 made tenancy / roles &
> > > capabilities
> > > > a
> > > > > > > > requirement. No more turning it on and off. The scope of
what
> > you
> > > > see
> > > > > > is
> > > > > > > > dictated by your tenancy and the api's that you have access
to
> > > are
> > > > > > > dictated
> > > > > > > > by your capabilities.
> > > > > > > >
> > > > > > > > Jeremy
> > > > > > > >
> > > > > > > > On Thu, Jun 14, 2018 at 11:49 AM, Volz, Dylan <
> > > > > dylan_v...@comcast.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Traffic Controllers,
> > > > > > > > >
> > > > > > > > > I am working on enforcing the roles->capabilities system
as a
> > > > > > > replacement
> > > > > > > > > for the soon-to-be legacy priv level system. Like tenancy
> > this
> > > > is a
> > > > > > > > feature
> > > > > > > > > moving us towards self-service; so to minimize our
> > > code/behavior
> > > > > > paths
> > > > > > > > > I would like to propose renaming the use_tenancy
parameter to
> > > > > > > > > use_self_service, so that if it is turned on both tenancy
and
> > > > > > > > capabilities
> > > > > > > > > are applied. This prevents some hairy cases arising when
> > > > > capabilities
> > > > > > > are
> > > > > > > > > on and tenancy is off or vice versa. Let me know if you
have
> > > any
> > > > > > > > questions,
> > > > > > > > > concerns, or suggestions.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Dylan
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
