On Thu, Sep 02, 2004, Thomas Werschlein wrote:
> I am wondering how experienced openPKG users handle the release pace
> openPKG provides - and enforces. If I look at the documentation, I see
> that there are 3 openPKG releases per year and security updates are
> provided for the last two releases "only".
>
> Somehow the same picture with the supported platforms: relatively new
> versions of distributions (such as Suse 9.0) are already considered
> obsolete.
Well, we already support multiple Linux distributions, but because of
resource reasons (both hardware and manpower) we cannot additionally
also support multiple versions of each distribution. Debian is our
mainly supported Linux distribution, hence we support two versions
there only. For all others we support just the latest version. But this
doesn't mean that you cannot run OpenPKG on older versions. Usually
OpenPKG still runs fine under older versions. It is that we just have
not made sure during our release engineering phase that this is the
case.
> Don't get me wrong - this is no criticism. I just wonder how you do it
> out there (especially for production systems, where you might have an
> SLA on the services and only limited maintenance windows).
>
> - do you always have identical test system hardware available?
At C&W we usually test things on a VMWare GSX server in order
to no having to establish physical test boxes.
> - or do you have two openPKG instances on the same host, one
> productive and one to test the new release?
Yes, at C&W for smaller upgrades we use additional staging OpenPKG
instances on the same host.
> - how would you switch from one instance to the other?
Say you want to upgrade /foo from 2.0 to 2.1. Then we install a /bar
with 2.1 on the box and install there all packages which are in use
under /foo (just in versions from OpenPKG 2.1 instead of 2.0). Then once
the stuff in /bar works as expected we upgrade /foo to 2.1 and remove
/bar.
> - if there is a test system: after successful integration test - do
> you mirror it on the production system or do rebuild the upgrade on
> the production system?
At C&W we usually always rebuild from scratch on the target machines,
both for upgrades and migrations.
> Introducing openPKG within our organization would clearly increase the
> overall upgrade pace.
> [...]
Well, the amount of supported older releases (currently 2) is just a
matter of manpower. Keep in mind that we are just a half dozend people
doing Open Source development here while other commercial vendors
can afford having hundrets of people just for security maintainance.
Obviously because they let you pay a few throusand dollars for their
enterprise products, of course.
So, if you really need upgrade-cylces of many years you have to avoid
cross-platform situations and non-commercial open source solutions like
OpenPKG. Instead you have to stick with commercial vendors like Sun,
RedHat, SuSE, etc and pay for their enterprise products. Then you are
forced to upgrade just every 2 years ;-)
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List [EMAIL PROTECTED]
