3:37 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I did some debugging with James Antill today and we found and fixed a
bug in the yum dependency resolver that was giving us trouble with
auto-selecting a CIMOM in the Fedora packaging.
The patch for yum is here[1] and will be included in the next build of
yum for Fedora 19+.
With that patch fixing things, I've attached a patch for both SFCB and
Pegasus packaging in Fedora to allow us to have yum properly select
Pegasus as the default CIMOM unless SFCB is 1) already installed or 2)
specified on the command-line.
It will do this by providing a versioned virtual Provides for
cim-server that is a higher number than the SFCB virtual Provides. I
have tested that this works by hotfixing my local copy of yum with
this patch.
This should make it much easier to get people installed on the right
platform.
[1]
http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=3eaca8456a9b8c4321...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlISghIACgkQeiVVYja6o6NUpACfbzAtR8UCg47PSyCbMrUBsIOH
FbIAoIDToMeO2xCGhX/ImiXwb3TZp8vz
=1Ol7
-----END PGP SIGNATURE-----
7:56 a.m.
This seems to be correct.
What I can imagine is also a group of packages. What other thinks about
it? Having all stuff (CIMOM, providers, lmishell, ...) in one group will
inform people what other thing are available.
RR
On 08/19/2013 10:37 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I did some debugging with James Antill today and we found and fixed a
bug in the yum dependency resolver that was giving us trouble with
auto-selecting a CIMOM in the Fedora packaging.
The patch for yum is here[1] and will be included in the next build of
yum for Fedora 19+.
With that patch fixing things, I've attached a patch for both SFCB and
Pegasus packaging in Fedora to allow us to have yum properly select
Pegasus as the default CIMOM unless SFCB is 1) already installed or 2)
specified on the command-line.
It will do this by providing a versioned virtual Provides for
cim-server that is a higher number than the SFCB virtual Provides. I
have tested that this works by hotfixing my local copy of yum with
this patch.
This should make it much easier to get people installed on the right
platform.
[1]
http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=3eaca8456a9b8c4321...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlISghIACgkQeiVVYja6o6NUpACfbzAtR8UCg47PSyCbMrUBsIOH
FbIAoIDToMeO2xCGhX/ImiXwb3TZp8vz
=1Ol7
-----END PGP SIGNATURE-----
_______________________________________________
openlmi-devel mailing list
openlmi-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
8:08 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/21/2013 08:56 AM, Roman Rakus wrote:
This seems to be correct. What I can imagine is also a group of
packages. What other thinks about it? Having all stuff (CIMOM,
providers, lmishell, ...) in one group will inform people what
other thing are available.
I was thinking about having us provide a set of meta-packages like
'openlmi-server' and 'openlmi-enterprise' that would bind up the set
of providers, CIMOMs and dependencies that we want people to be
installing most of the time.
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlIUu+YACgkQeiVVYja6o6OZvQCgmFHInKhZGQ17JOfRFKIftQ3R
pSoAn18eDZRBanpCvyC9r0ioIjjxAwNR
=EsA/
-----END PGP SIGNATURE-----
8:32 a.m.
On Wed, 2013-08-21 at 09:08 -0400, Stephen Gallagher wrote:
On 08/21/2013 08:56 AM, Roman Rakus wrote:
> This seems to be correct. What I can imagine is also a group of
> packages. What other thinks about it? Having all stuff (CIMOM,
> providers, lmishell, ...) in one group will inform people what
> other thing are available.
>
I was thinking about having us provide a set of meta-packages like
'openlmi-server' and 'openlmi-enterprise' that would bind up the set
of providers, CIMOMs and dependencies that we want people to be
installing most of the time.
openlmi-server (normal set of providers for all servers):
tog-pegasus
openlmi-storage
openlmi-networking
openlmi-software
openlmi-account
openlmi-realmd
I would make realmd optional, or at least put it in the enterprise
package.
openlmi-service
The hardware (inventory) Provider should be in
the base package.
What about the lmi-tools package?
Do we want to install anything from sblim? (I don't think so, but want
to raise the question.)
openlmi-enterprise (comprehensive providers and discovery):
openlmi-server
openslp
openlmi-fan
openlmi-hardware
openlmi-logicalfile
openlmi-powermanagement
Looking ahead, which package (if any) should new Providers be included
in?
* firewall
* SELinux
* SCAP
* Monitoring (general, Performance Copilot)
* logging
* other?
_______________________________________________
openlmi-devel mailing list
openlmi-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
9:59 a.m.
On Wed, 2013-08-21 at 16:30 +0200, Roman Rakus wrote:
On 08/21/2013 03:32 PM, Russell Doty wrote:
> Do we want to install anything from sblim? (I don't think so, but want
> to raise the question.)
Now we depend (all providers?) on sblim-cmpi-base.
Sounds like we should include
it!
RR
_______________________________________________
openlmi-devel mailing list
openlmi-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
10:30 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/21/2013 10:59 AM, Russell Doty wrote:
On Wed, 2013-08-21 at 16:30 +0200, Roman Rakus wrote:
> On 08/21/2013 03:32 PM, Russell Doty wrote:
>> Do we want to install anything from sblim? (I don't think so,
>> but want to raise the question.)
> Now we depend (all providers?) on sblim-cmpi-base.
Sounds like we should include it!
Well, dependencies are handled automatically. We don't need to specify
them directly. I left out 'openlmi-providers' from my list above for
the same reason. It's automatically pulled in by the others.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlIU3S0ACgkQeiVVYja6o6Pu7wCeLNC5RUgmKOsTrJaMs7IM/Sy2
qVwAmgMPd+aIFjg72sRXVW/LxHVsvPa/
=cvMX
-----END PGP SIGNATURE-----
10:43 a.m.
On Wed, 2013-08-21 at 11:30 -0400, Stephen Gallagher wrote:
On 08/21/2013 10:59 AM, Russell Doty wrote:
> On Wed, 2013-08-21 at 16:30 +0200, Roman Rakus wrote:
>> On 08/21/2013 03:32 PM, Russell Doty wrote:
>>> Do we want to install anything from sblim? (I don't think so,
>>> but want to raise the question.)
>> Now we depend (all providers?) on sblim-cmpi-base.
> Sounds like we should include it!
Well, dependencies are handled automatically. We don't need to specify
them directly. I left out 'openlmi-providers' from my list above for
the same reason. It's automatically pulled in by the others.
Hmmm, good point.
For the purposes of planning and discussion, can we have our list of
packages include the ones brought in as dependencies - at least the LMI
specific packages. If, for example, openlmi-tools brings in
sblim-cmpi-base, can we show it as:
*openlmi-server
- openlmi-tools
- sblim-cmpi-base
9:33 a.m.
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...
Regards,
--
Tomáš Smetana
Platform Engineering, Red Hat
9:49 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
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.
Other thoughts?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlIWJQQACgkQeiVVYja6o6N7FwCdH1HHiMsMwi5s1GbI0gLyrf78
eYgAn12IWGXHoieVGsLG6WJ8jFBoZCjX
=WJNU
-----END PGP SIGNATURE-----
10 a.m.
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
3915
days inactive
3918
days old
openlmi-devel@lists.fedorahosted.org
10 comments
4 participants
participants (4)
-
Roman Rakus -
Russell Doty -
Stephen Gallagher -
Tomáš Smetana