Discussion:
Dependencies on other hosts in a distributed application?
Mike Meyer
2008-09-22 23:44:21 UTC
Permalink
I find myself responsible for managing an ecosystem of rpms for our
custom application. One of the interesting sticking points is what we
call the "db" rpm. Most of the other rpms won't run correctly unless
that rpm is installed. The catch is, it's got to be installed on the
database node(s) of the application, not the application nodes that
the other rpms are being installed on.

I haven't seen anything to indicate that the rpm format can handle
such a dependency. Have I overlooked something? Anybody got *any*
ideas on how such a thing might be handled?

Thanks,
<mike
--
Mike Meyer <***@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
G***@aotx.uscourts.gov
2008-09-23 13:52:46 UTC
Permalink
Post by Mike Meyer
I find myself responsible for managing an ecosystem of rpms for our
custom application. One of the interesting sticking points is what we
call the "db" rpm. Most of the other rpms won't run correctly unless
that rpm is installed. The catch is, it's got to be installed on the
database node(s) of the application, not the application nodes that
the other rpms are being installed on.
I haven't seen anything to indicate that the rpm format can handle
such a dependency. Have I overlooked something? Anybody got *any*
ideas on how such a thing might be handled?
As far as I know it not a feature. Most applications with similar
distributed configurations tend to rely on the db client packages and then
require you to setup the package manually or with a script after the
install.

I guess there is one method you could try, although I'm sure most packagers
would disagree with the practice, as do I. However this is an internal
custom application, and I've been placed in similar situations before. You
can try setting up the check for the remote db inside the %pre script and
failing at that point if the check is unsuccessful. This way you can at
least have a fairly controlled failure point based on that dependancy
before your rpm tries to do any additional work. Having typed it I like
the idea even less, but there it is. Having re-read your question, I'm not
sure if that is what you are already doing or not.

-greg
Jason Pyeron
2008-09-23 14:03:12 UTC
Permalink
-----Original Message-----
Sent: Tuesday, September 23, 2008 9:53 AM
To: RPM Package Manager
Subject: Re: Dependencies on other hosts in a distributed application?
Post by Mike Meyer
I find myself responsible for managing an ecosystem of rpms for our
custom application. One of the interesting sticking points
is what we
Post by Mike Meyer
call the "db" rpm. Most of the other rpms won't run
correctly unless
Post by Mike Meyer
that rpm is installed. The catch is, it's got to be
installed on the
Post by Mike Meyer
database node(s) of the application, not the application nodes that
the other rpms are being installed on.
I haven't seen anything to indicate that the rpm format can handle
such a dependency. Have I overlooked something? Anybody got *any*
ideas on how such a thing might be handled?
As far as I know it not a feature. Most applications with
similar distributed configurations tend to rely on the db
client packages and then require you to setup the package
manually or with a script after the install.
I guess there is one method you could try, although I'm sure
most packagers would disagree with the practice, as do I.
However this is an internal custom application, and I've been
placed in similar situations before. You can try setting up
the check for the remote db inside the %pre script and
failing at that point if the check is unsuccessful. This way
you can at least have a fairly controlled failure point based
on that dependancy before your rpm tries to do any additional
work. Having typed it I like the idea even less, but there
it is. Having re-read your question, I'm not sure if that is
what you are already doing or not.
I alwayss hated the prescript, it breaks too much.

So what we have done in situations like this:

Make a faux client db package and require that.
In the faux db package do the mojo, in particular we generate these faux rpm
from the "db server" so they have the proper config inside.


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
G***@aotx.uscourts.gov
2008-09-23 14:53:17 UTC
Permalink
Post by Jason Pyeron
Post by Mike Meyer
Post by Mike Meyer
I find myself responsible for managing an ecosystem of rpms for our
custom application. One of the interesting sticking points
is what we
Post by Mike Meyer
call the "db" rpm. Most of the other rpms won't run
correctly unless
Post by Mike Meyer
that rpm is installed. The catch is, it's got to be
installed on the
Post by Mike Meyer
database node(s) of the application, not the application nodes that
the other rpms are being installed on.
I haven't seen anything to indicate that the rpm format can handle
such a dependency. Have I overlooked something? Anybody got *any*
ideas on how such a thing might be handled?
As far as I know it not a feature. Most applications with
similar distributed configurations tend to rely on the db
client packages and then require you to setup the package
manually or with a script after the install.
I guess there is one method you could try, although I'm sure
most packagers would disagree with the practice, as do I.
However this is an internal custom application, and I've been
placed in similar situations before. You can try setting up
the check for the remote db inside the %pre script and
failing at that point if the check is unsuccessful. This way
you can at least have a fairly controlled failure point based
on that dependancy before your rpm tries to do any additional
work. Having typed it I like the idea even less, but there
it is. Having re-read your question, I'm not sure if that is
what you are already doing or not.
I alwayss hated the prescript, it breaks too much.
Make a faux client db package and require that.
In the faux db package do the mojo, in particular we generate these faux rpm
from the "db server" so they have the proper config inside.
what type of proper configs does your application need to be present ? is
it inside the scripts in the RPM itself that needs the configs to be there,
or does the application just not work after install if they arent?

-greg
Jeff Johnson
2008-09-23 20:51:59 UTC
Permalink
Post by Mike Meyer
I find myself responsible for managing an ecosystem of rpms for our
custom application. One of the interesting sticking points is what we
call the "db" rpm. Most of the other rpms won't run correctly unless
that rpm is installed. The catch is, it's got to be installed on the
database node(s) of the application, not the application nodes that
the other rpms are being installed on.
I haven't seen anything to indicate that the rpm format can handle
such a dependency. Have I overlooked something? Anybody got *any*
ideas on how such a thing might be handled?
rpm5 has something called a "probe dependency", basically
a boolean valued function call that returns SATISFIED/UNSATISFIED
depending on the run-time environment. An additional compiled in
probe for the condition "package is installed on database node"
is likely no more complicated than attempting a connection to a
URI that includes hostname and port.

rpm5 also expands macros while checking dependencies, that's
sufficient to fire an external script that returns 0 == satisfied !0
== unsatisfied.

But you are unlikely to be using rpm5. Oh well ...

73 de Jeff

Continue reading on narkive:
Loading...