What your proposing is extremely similar to what we had been doing in our
data model in Maya in that the base profile defined by an administrator
could be augmented by a user. In this case, we had envisioned rules as to
what could be excluded such that some adminstrator defined software would be
required while others could be updated to be excluded by the user. The big
difference in what we were doing in Maya was that the profiles were shared
across systems, though I have a feeling if the use cases we defined worked
out well in the shared case, then whether shared across systems or shared by
users of a single system, I imagine the model could still work out fine.
In the case of integrating with Linux, the user would need to be able to
define potentially multiple derivative profiles off of the base system one.
The challenge will be maintaining consistency of those derived profiles as
the system-wide profile is updated by various package operations RPM, etc.
In that regard, I think the ease would depend on the rules of the added
software. If the added software conflicted with what the user already had
in the profile, but the included software is able to be excluded, that it
would be automatically added as an exclude rule. In addition, in the case
of a managed provisioning scenario with governance, if the governance model
prohibits adding certain software that is added by RPM or other package, the
user's profile would still need to have that software excluded.
On 8/7/07, Andrew Overholt <[EMAIL PROTECTED]> wrote:
> The week before last I had some discussions with Pascal about how
> Equinox provisioning stuff will interact with Linux distribution
> packages. Since then I've been struggling a bit to get my thoughts and
> our discussions collected so I'd like to discuss them here to get
> others' opinions.
> One of the ideas we discussed was profile inheritance. With that, we
> would have a system-wide (administrator-managed) profile that is
> populated with the entire set of bundles available via installed distro
> packages (RPMs, .debs, whatever). (I am thinking we'd have to manually
> avoid conflicts in what we ship, but that's tangential here.) We would
> also have per-user profiles that allow for system-wide things to be
> disabled/enabled and allows for per-user bundle installation. Does this
> make sense?
> provisioning-dev mailing list
provisioning-dev mailing list