On 02/18/2013 10:36 AM, Dan Callaghan wrote:
In my opinion, +1 to making it easier to set up common group/pool
configurations, but -1 to this proposed magic and hiding of details.
The mess we are currently in comes from having too much magic, and from
conflating user groups with system groups. So I think we need to make
a point of keeping them very distinct in the UI and in the docs.
If people are finding the proposal confusing, maybe we just need to
explain it better.
If people are worried that they will have to do too much clicking to set
up their "simple" configuration, then we can try and come up with some
UI to mitigate it -- but hiding the existence of system pools is not the
way to do it.
I'm happy to keep the explicit pool management part of the proposal - as
you say, only providing the implicit version would likely give people
the wrong idea about how it actually works. We'll need to add "edit pool
policy" as a permission, though. (Related: perhaps we need the ability
to limit permissions on a pool to *owners* of a linked group?)
However, I still like the idea of adding an automatically created pool
for each group and allowing the use of group names in autopick and
hostRequires. We can emphasise in the docs that <group>whatever</group>
is just shorthand for <pool>default-pool-for-group-whatever</pool>. That
would give the simple UI I am after for the typical case (i.e. prefer,
or use only, my group's machines), without hiding the underlying
implementation details.
I also still like the idea of having a Group Pool setting in the UI for
systems, distinct from an Additional Pools setting.
To help explain *why* explicitly created pools are useful, I think we
also need to come up with a design for marking a pool as "only use these
systems when explicitly nominated in autopick". This is desirable for
limiting systems to particular kinds of recipes, rather than assuming
they're candidates for every recipe run by users with access to the
pool. (We can put it in "Deferred Features" if we don't want to
implement it straight away - the important part is to explain what we're
building towards).
Perhaps we should do something similar to what I did with the
event-based-scheduler vs effective-job-priorities proposal - create a
"group management of systems" proposal that depends on the system pools
proposal. Then we can decide if we think we can get both done in a
single iteration, or if we need to do them across a pair of releases.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (http://beaker-project.org/)
PulpDist Development Lead (http://pulpdist.readthedocs.org)
_______________________________________________
Beaker-devel mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
