Excerpts from Nick Coghlan's message of 2013-07-31 11:39:46 +1000:
Putting these thoughts in email form so Dan can either take them
into
account when rewriting the system pools proposals, or else suggest areas
which seem like unneeded complexity. For example, with ad hoc groups,
maybe we don't need system pools as a separate notion for tagging
purposes (just create a group instead). They're all only half-formed
notions, so definitely take them with a rather large grain of salt :)
Firstly, I'm thinking that we should ensure the system <-> access policy
relationship is always one-to-one. Anything else will be too confusing.
If we decide to later implement a tagging system for referring to kinds
of systems, that should be a separate thing independent of access policies.
Agreed. I still think that the original reasoning behind system pools
was valid, which is that people want to group systems into arbitrary
collections which are not (necessarily) correlated with user groups,
for:
* purely informational purposes ("these are all inside the wifi tent",
"these are out of warranty and should be discarded", ...)
* scheduling purposes
* applying a consistent access policy across the collection
* other purposes which I don't recall, or which we don't know of?
The above purposes sometimes overlap, but not always, and it might be
a mistake to try and cover all of them with the one concept of "system
pools". This conflict (a system having multiple access policies does not
make sense, but a system being in multiple scheduling pools *does* make
sense) is just one indication that we are trying to over-generalise.
I'm contemplating up to four different "kinds" of
access policy:
- system access policy. Just a transition mechanism from the current
system level permissions, these will be created automatically as part of
the data migration from the legacy access model. These would be
represented in the UI as a "Custom access policy".
- user access policy. The default access policy applied to systems owned
by a particular user if no other policy is nominated. Can only be edited
by the user themselves.
- group access policy. An access policy controlled by the owners of a
particular group. System owners may switch the access policy from an
implicitly created system policy or their user policy over to a group
access policy.
- pool access policy. An access policy independent of any particular
group. In a certain sense, system access policies are an example of
this, using a pool containing exactly one system.
As part of this, I'm wondering if we want to borrow the *nix account
management notion of creating an implicit group for each user, where
they're the group owner and only member. Then we can require that access
policies have an "owning group", and for user access policies, this
would be the user's implicit group. Similarly, for custom access
policies, the policy owner would be the system owner's implicit group. I
suspect there are trade-offs either way (modelling user-owned policies +
group-owned policies separately, or introducing an implicit group for
each user), but it's something we should deliberately consider.
I don't think it's necessary that a policy have any kind of owner. The
ability to modify the policy would be controlled by a permission on the
policy itself (``edit-policy`` below). The system owner controls what
policy applies to their system.
(I also think Beaker's current requirement that every system have
exactly one owner is not adequate, but I don't think we should try and
tackle that right now.)
What if "predefined access policies" were first class named entities,
not tied to anything else? The custom access policies for each system
which be represented in the same table, but as anonymous, hidden
policies referencing a single system. So the UI at the system level
would be: pick a predefined policy from the list, create a new named
policy, or make a custom one for this system. Then users can set up
predefined policies associated with whatever they want ("Company-wide
shared systems", "Kernel QE hardware", "dcallagh's
systems").
So this is essentially back to the system pools idea, except only for
access control purposes, not trying to conflate all the other different
purposes.
In terms of permissions, the list in the current system pools
proposal
looks pretty good:
edit system details (edit-system)
loan system to anyone (loan-any)
loan system to self (loan-self)
issue power and provisioning commands (control-system)
implicitly schedule recipes on the system when submitting jobs
(schedule-recipe)
reserve system manually (via web UI or bkr client) (reserve-manual)
The last two are really equivalent, it just depends whether the system
is set to run scheduled jobs (Automated) or must be manually reserved
(Manual). I had merged them into one permission ``reserve`` in my patch.
However, we may want to consider some additions:
edit access policy (edit-policy)
switch access policy (switch-policy)
explicitly request the system when submitting jobs (schedule-explicit)
edit-policy refers to changing the policy itself. If we don't add it,
updates would be limited to the owning user (for user access policies)
or owners of the owning group (for group access policies)
As above, I think edit-policy is good, and should obviate the need for
an explicit "owner" of the policy.
switch-policy refers to changing the access policy on a system to a
different policy. If we don't add it, updates would be limited to the
system owner.
I'm not sure this makes sense. It feels like escaping the permission
system. In any case, I think we could safely defer it for now.
schedule-explicit gets us back to the notion of having systems in
the
general pool that are available to the scheduler, but only when
explicitly requested in the job XML. This extra field would allow you to
have a policy where "schedule-recipe" was empty (so the system would
never be used automatically), but we could add new features to the job
XML to override the normal rules. Since there would need to a lot of
other supporting changes to make this happen, it should be a deferred
feature, but it's something to keep in mind as a future enhancement that
may guide the underlying implementation details.
I think "schedule-explicit" is an interesting idea but it's really
orthogonal to the access policy. It's more about what kinds of
reservations the system will allow: so, not *who* is permitted to
reserve, but rather *how* they are permitted to reserve it. We are
already using the Condition field (Broken, Automated, Manual) for that.
There is also the Type field which serves a similar purpose (requires
explicitly opting it to the system) but by a completely different
mechanism. So I think these need to be generalised/simplified rather
than adding yet another different mechanism through the access policy.
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.