On Thu, 2013-08-22 at 10:49 -0400, Stephen Gallagher wrote:
On 08/22/2013 10:33 AM, Tomáš Smetana wrote:
> On Wed, 21 Aug 2013 09:08:54 -0400 Stephen Gallagher
> <sgallagh(a)redhat.com> wrote:
>
>> openlmi-server (normal set of providers for all servers):
>> tog-pegasus openlmi-storage openlmi-networking openlmi-software
>> openlmi-account openlmi-realmd openlmi-service
>>
>> openlmi-enterprise (comprehensive providers and discovery):
>> openlmi-server openslp openlmi-fan openlmi-hardware
>> openlmi-logicalfile openlmi-powermanagement
>
> I would rather see a distinction of "server" (CIMOM + providers +
> SLP server) and "client" (tools + python client development
> libraries). Also having more metapackages wouldn't solve the
> problem much: Either we would need to document which packages to
> install for a particular use-case or which metapackages to
> install...
>
Yes, Tomáš and I discussed this on a phone call earlier. I think he
makes a good point: we should just have one metapackage, probably
'openlmi-server' that contains the complete set of packages we think
belong in the OpenLMI collection on the managed system. A
technically-savvy individual could choose to install the separate
packages manually if they really wanted a smaller set, but in general
it just makes sense to install everything at once. This makes it
easier to define a "supported" configuration as well. We reduce the
test matrix that way.
We need a single, obvious package for users to use to install
OpenLMI -
I would suggest calling it either openlmi or openlmi-server. It should
be obvious from the name and description that this is the master package
to install OpenLMI. This package should install the base providers, not
every possible Provider.
I'm not sure we need a client metapackage yet, since at the moment
that would only be pulling in the openlmi-tools package. Though, I
suppose it would make it easier to add one or more scriptons to the
list later on. So I'm fine with this as well.
Let's put some thought into
designing the client environment. Since we
aren't planning on shipping the scriptons in RHEL 7.0, this will be a
bit tricky for RHEL. Do we want to package the scriptons in Fedora,
starting with F20?
Other thoughts?
_______________________________________________
openlmi-devel mailing list
openlmi-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel