Gerhardus Geldenhuis wrote:
Hi Adrian,
I still think that a differentiation is called for between application
deployment and os level deployment. If you have well over a 1000
machines then investing time in looking at application level
deployment mechanisms would be time well spend in my view.
rpm/yum/spacewalk works well to distribute os patches but I do not
think that one should spend to much time writing involved update
scripts embedded in rpm's if there is available frameworks to
distribute applications, especially if it is java based.
This is a bad route to take. Packages are packages.
First of all, it does not matter what language the deployment tools are
written in, and there is no major difference from updating OS plumbing
as applications. Pretty much all LAMP applications update fine via
yum without problems. Most desktop applications do. The idea that
you have to bring a database application down to upgrade it's database
is not language specific, it's an organizational thing. This is about
downtime windows.
It's another story that Java developers are typically not good about
packaging their software via RPM, but when there are RPM's, you have all
of the advantages of the packaging system.
But this thread really isn't about what is pushing something out, so
that's irrelevant -- what this thread was more about was "how do I
decide when to update software?". That's an organizational policy kind
of thing that doesn't depend on language or application, or whether
something is a libc update or a new openoffice.
Linux has no problem replacing /usr/bin/myapp while it's running without
affecting the running process. If it's a database application, then
yes, you want to stage your updates. The need to do that with respect
to downtime windows does /not/ change whether you have a J2EE app or
some other mission critical database/web application. It's just an
organizational thing, and yes, it's perfectly fine to be using Spacewalk
(or just yum) to do this -- lots of folks do.
The original post asked if downloading updates and applying them later
was a good idea. It might be, though such an application on top of
something like repotrack does not IIRC exist. It's a bit like the
"preupgrade" idea in newer Fedora but not so upgrade centric.
You could also just do something simple such as decide to run yum update
only at a certain time, which is simpler.
Ultimately something like Func may be ideally suited, where you could
just do:
Func "webservers*.example.org" call yum update
at 3:00 AM (from cron)
And you could update other servers at other times.
I am less familar with spacewalk's actions tooling but I suspect it can
do similar, either way you are still going through yum_rhn_plugin for
the updates.
Either way, I'd seriously look at doing something like that and training
your folks to understand scheduled outage windows for updates, and then
everything becomes much simpler.
Regards
On Thu, Oct 9, 2008 at 9:01 PM, Adrián Márques <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Thank you Michael for all of your valuable feedback.
Yes, ooffice is not the best example. I just wanted to illustrate
that operators will be working against a GUI, which can't just
restart apparently out of its own volition whenever there's an
update.
For starters, RPM is a package format, yum is the updater.
Deciding when you want to do updates is a good thing to be
thinking about. Configuring spacewalk to /not/ pull down
updates automatically is I presume doable (spacewalk folks?),
in which case you can just push them out when you want
(Spacewalk also have a facility to do this as well and can
probably explain better).
Maybe I wasn't clear with my previous mail. I do understand the
difference between RPM and YUM. I know that from the spacewalk POV
I could push the updates at specific times, but to the best of my
knowledge this gives me no guarantee the updates will be applied
to the clients at a specific time. Furthermore, I'm thinking of
administering as much as well over a thousand hosts this way, in
an environment were mantainance windows could be quite impractical
to enforce. Thus I though of having the yum-rhn plugin download
all rpms in the backgound, while the app might be running, and
have them installed when I know I can restart the app without
inconveniences. I'd also have to ensure that the app can't be
started while an update is taking place.
I hope with this I took care of any preceding ambiguities in my
intentions.
So I restate my questions: Do you consider this a terrible
solution? Am I trying to defeat RPM/YUM/Spacewalk design with
this? Is there a better alternative?
Thank you all.
Adrián.
Michael DeHaan escribió:
Adrián Márques wrote:
Thanks a lot Michael.
I'd never heard of condrestart before and your other
suggestions also seem to be more than worth checking out.
If I understood you correctly though, the advice you are
giving me is geared towards updating services and in the
process starting/stopping/restarting them based on
conditions (I'll be looking into the links you provided to
verify whether this is right). The conundrum I'm facing is
that this is a desktop app, picture ooffice as an example,
and I can't restart it while the users are logged in it.
office doesn't have a backend service, so that may not be the
best example.
In either case, you'd want to deploy your new software in a
window where it made since to do it.
The hosts were this app will be running will be dedicated,
so I'm leaning towards the idea of hacking the spacewalk
client as I mentioned before (so it won't install the
updates until told to) and periodically install downloaded
rpms either at boot time or whenever I can ensure that no
users are logged into this app. Do you consider this a
terrible solution? Am I trying to defeat RPM with this? Is
there a better alternative?
For starters, RPM is a package format, yum is the updater.
Deciding when you want to do updates is a good thing to be
thinking about. Configuring spacewalk to /not/ pull down
updates automatically is I presume doable (spacewalk folks?),
in which case you can just push them out when you want
(Spacewalk also have a facility to do this as well and can
probably explain better).
Thanks.
Adrián.
Michael DeHaan escribió:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> wrote:
Hi Adrián,
The question is probably more suitable on a rpm list.
We don't distribute our jar's with rpm but I
appreciate your dillema.
I don't personnally think that for such complex
applications, rpm is the right way to upgrade
with. I see rpm has a way to distribute "core"
stuff, and not suitable for distributing weird and
wonderfull applications that requires restarts and
database upgrades etc. There is application
servers and frameworks that is better suited for
this type of thing and that sits on a logically
higher level. JBoss, Wesphere and I think even
tomcat has some basic stuff build in.
Regards
This is generally true only for applications that are
packaged /poorly/. Properly packaged RPMs can be
configured to do "condrestart" as needed.
If you need something more advanced, this is typically
where you would want to look at something like
puppet/cfengine/bcfg2 where you can describe the state
you want your services to be (and remain) in.
Also you may be interested in a simple tool such as
Func (http://fedorahosted.org/func) for restarting
services remotely. It is in many ways easier to
deploy than SSH and also provides you a way of
defining arbitrary groups of systems to send commands to.
--Michael
-----Original Message-----
From: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>] On
Behalf Of Adrián Márques
Sent: 06 October 2008 18:45
To: [email protected]
<mailto:[email protected]>
Subject: [Spacewalk-list] How to update
running applications?
Dear all,
I'm having a difficult time in finding the
correct forum to pose this question since I
guess it's part spacewalk, part RPM, part
basic aplication design.
Being an RPM end-user for years I had always
assumed that updating running apps was a piece
of cake with RPM. After all, I always did it
and the most I got were occasional messages
such as "Firefox restart required", never
encountering other side-effects.
However, after reading through the RPM guide,
getting my hands dirty trying to package an
app, scouring the internet for info and asking
around in the RPM mailing list, I'm still not
sure how to write my RPM so updating won't be
an issue.
The scenario is the following: I'd like to use
spacewalk to distribute a custom desktop app.
Hence, it's unavoidable that some users will
be working at the time of an update. So far
I've identified two problems with this, 1) If
I have to modify the app's database schema as
part of the update, the running app might
break down if it's not aware of the change 2)
This happens to be a java app, so in case a
jar gets updated a class might get loaded that
is not compatible with those already loaded by
the running app.
I understand that what I've explained so far
might be outside of the scope of the subjects
treated in this mailing list, if so, please
just treat it as a detailed background problem
description.
What I would like to know from you guys is
whether you've had any problems when updating
apps through Satellite/Spacewalk due to them
being running at the time or what precautions
(if any) you take when doing so.
Finally, I suppose that as a last resort I
could hack the spacewalk client to only
download updates and not install them until it
is told to do so from the command line. Is
this already possible? If not, where's the
place to start with hacking this?
I thank you all for your time and attention.
It'd be amazing if you had any comments
regarding my background issue, but I'll be
more than satisfied and grateful if you could
just provide any feedback on those questions
strictly spacewalk-related.
Thanks.
Adrián.
_______________________________________________
Spacewalk-list mailing list
[email protected] <mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/spacewalk-list
--
Gerhardus Geldenhuis
Registered Linux User #193352
_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list
