FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 01-22-2009, 06:00 PM
Les Mikesell
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

Joshua Kramer wrote:
>> So how do you package such a thing in RPM so it can permit both new and
>> old instances to run simultaneously while you do all of this required
>> testing? I suppose these days virtualbox is an almost-reasonable answer
>
> I think this discussion is a reflection of our different environments.

I see it as a generic problem with RPM packaging/deployment that you are
forced to work around by maintaining duplicate equipment.

> On my websites... when 8.3 came out, I downloaded it to a test machine. I
> then did a dump of the production data from 8.2, and did an import into my
> 8.3 test machine. After pointing an Apache dev instance at the test
> database, I could verify that my applications still worked, and make any
> code changes that were required.

That's great if you have a test machine for every application. For an
important production web site it kind of goes with the territory.

> After I had a test/dev environment that was stable under 8.3, I planned
> the migration: 1. Dump 8.2; 2. Shutdown 8.2 and remove packages; 3. Move
> 8.2's data directory; 4. Install 8.3 packages, and initdb; 5. Import data
> made during the dump and start db; 6. Migrate code changes to web server.
> After things baked for a week and there were no errors, I deleted the old
> 8.2 data directories.

What would you do for something simple that doesn't justify buying a
duplicate machine, yet is probably even more likely to break from a
version change?

> I realize that this is much more difficult if you're using a VM on a web
> host that only allows one machine. Is this the type of environment that
> is constraining you?

I'd just like to see a realistic approach to updates via packages.

> As long as you can test your application under the
> new database version to make sure it's OK, the migration can be done on
> one machine. But let me ask: in what case would you not want to test your
> application against a new database version?

I do want the ability to test while still running the old version. I
just don't see how that is possible with any RPM-deployed package
without having duplicate hardware or virtual machines. Postgresql makes
a good example because the conversion needs both new and old code
present for different steps, and 8.2->8.3 especially so because some
implict casts were removed that can break client code in odd ways, but
the principle is the same for any change where you want to know the new
version works in your environment before the old one is shut down. If
you build from source you can make it use different locations and ports
and run concurrently, but with RPM binaries you can't.

--
Les Mikesell
lesmikesell@gmail.com

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-22-2009, 06:05 PM
Jeff Johnson
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

On Jan 22, 2009, at 2:00 PM, Les Mikesell wrote:




I'd just like to see a realistic approach to updates via packages.



Reality check:

You have a postgres upstream devel with years of experience
packaging postgres and me both saying
Don't attempt postgres database upgrades in packaging.

But create your own virtuality reality approach if you want.

Have fun!

73 de Jeff______________________________________________ _
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-22-2009, 06:23 PM
Les Mikesell
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

Jeff Johnson wrote:
>
> On Jan 22, 2009, at 2:00 PM, Les Mikesell wrote:
>>>
>>
>> I'd just like to see a realistic approach to updates via packages.
>>
>
> Reality check:
>
> You have a postgres upstream devel with years of experience
> packaging postgres and me both saying
> Don't attempt postgres database upgrades in packaging.
>
> But create your own virtuality reality approach if you want.
>

I think you missed my point, which is that RPM packaging doesn't provide
facilities for what needs to be done. Postgres upstream is just more
honest than most in recognizing the problem. It's not the only thing
that ever has non-backward-compatible updates.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-22-2009, 08:04 PM
Jeff Johnson
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

On Jan 22, 2009, at 2:23 PM, Les Mikesell wrote:


Jeff Johnson wrote:


On Jan 22, 2009, at 2:00 PM, Les Mikesell wrote:




I'd just like to see a realistic approach to updates via packages.



Reality check:

You have a postgres upstream devel with years of experience
packaging postgres and me both saying
Don't attempt postgres database upgrades in packaging.

But create your own virtuality reality approach if you want.



I think you missed my point, which is that RPM packaging doesn't
provide

facilities for what needs to be done. Postgres upstream is just more
honest than most in recognizing the problem. It's not the only thing
that ever has non-backward-compatible updates.



I believe that one can easily conclude
RPM packaging doesn't provide facilities for what needs to be done
from
Don't attempt postgres database upgrades in packaging.

You the one who wishes
I'd just like to see a realistic approach to updates via packages.

That Does Not Compute with current RPM facilities and existing postgres
upgrade mechanisms.

73 de Jeff______________________________________________ _
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-22-2009, 08:40 PM
Les Mikesell
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

Jeff Johnson wrote:
>
>>> But create your own virtuality reality approach if you want.
>>>
>>
>> I think you missed my point, which is that RPM packaging doesn't provide
>> facilities for what needs to be done. Postgres upstream is just more
>> honest than most in recognizing the problem. It's not the only thing
>> that ever has non-backward-compatible updates.
>>
>
> I believe that one can easily conclude
> RPM packaging doesn't provide facilities for what needs to be done
> from
> Don't attempt postgres database upgrades in packaging.
>
> You the one who wishes
> I'd just like to see a realistic approach to updates via packages.

Meaning I'd like RPM to be changed so multiple versions of packages
could co-exist, as is often necessary in practice.

> That Does Not Compute with current RPM facilities and existing postgres
> upgrade mechanisms.

Agreed, it doesn't work. Nor does any other RPM-managed update where
you need to have both old and new packages simultaneously working for a
while. The special case for the kernel is about the only place where it
even attempts to keep old versions around for an emergency fallback.

--
Les Mikesell
lesmikesell@gmail.com

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-22-2009, 08:49 PM
Jeff Johnson
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

On Jan 22, 2009, at 4:40 PM, Les Mikesell wrote:


Agreed, it doesn't work. Nor does any other RPM-managed update where
you need to have both old and new packages simultaneously working
for a
while. The special case for the kernel is about the only place
where it

even attempts to keep old versions around for an emergency fallback.



Honking about RPM deficiencies on a CentOS Devel list is hot air going
no place.


FWIW, there's no package system that provides sufficient facilties to
undertake

a postgres upgrade reliably during upgrade that I'm aware of. Nor is it
"recommended" afaik.

But supply a pointer to your favorite package manager that _DOES_
attempt
postgres database upgrades and I'll be happy to attempt equivalent in
RPM.


Personally, I think that database upgrades have almost nothing
to do with instaling packages, but I'd rather add whatever is useful
than discuss well known RPM deficiencies for another decade.

73 de Jeff

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-22-2009, 09:43 PM
Les Mikesell
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

Jeff Johnson wrote:
>
> On Jan 22, 2009, at 4:40 PM, Les Mikesell wrote:
>>
>> Agreed, it doesn't work. Nor does any other RPM-managed update where
>> you need to have both old and new packages simultaneously working for a
>> while. The special case for the kernel is about the only place where it
>> even attempts to keep old versions around for an emergency fallback.
>>
>
> Honking about RPM deficiencies on a CentOS Devel list is hot air going
> no place.
>
> FWIW, there's no package system that provides sufficient facilties to
> undertake
> a postgres upgrade reliably during upgrade that I'm aware of. Nor is it
> "recommended" afaik.
>
> But supply a pointer to your favorite package manager that _DOES_ attempt
> postgres database upgrades and I'll be happy to attempt equivalent in RPM.
>
> Personally, I think that database upgrades have almost nothing
> to do with instaling packages, but I'd rather add whatever is useful
> than discuss well known RPM deficiencies for another decade.

The reason the discussion is intertwined with packaging is that if you
name the delivered files the same, the old and new can never co-exist as
they should for the conversion and test period.

I think the only way it can be done reasonably is to install the new
code with different names and/or paths and scripts that can be run later
to do the conversion and (after testing) replacement of the old version.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-22-2009, 10:06 PM
Jeff Johnson
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

On Jan 22, 2009, at 5:43 PM, Les Mikesell wrote:



Personally, I think that database upgrades have almost nothing
to do with instaling packages, but I'd rather add whatever is useful
than discuss well known RPM deficiencies for another decade.


The reason the discussion is intertwined with packaging is that if you
name the delivered files the same, the old and new can never co-
exist as

they should for the conversion and test period.



In fact, the old <-> new can/do coexist during upgrade; lib/fsm.c in
RPM has had
a form of apply/commit since forever that puts the new in place (the
apply) but

does not remove the old (renaming into old is the commit).

And there are provisions to rename the old into a subdirectory
as part of committing the new; at least the necessary path
name generation including a subdirectory has been there
since forever in RPM. Adding the necessary logic to
achieve whatever goal is desired installing files is just not that hard,
the code is a state machine.

Personally (and as I pointed out), including old files in the new
package

is likelier to be reliable, and has the additional benefit that whatever
conversions are needed can be done anytime, not just during a "window"
during upgrade where old <-> new coexist. A conversion side-effect at
the scale of a database conversion is hugely complicated to guarantee
reliability during a "window". Are you volunteering to test?


I think the only way it can be done reasonably is to install the new
code with different names and/or paths and scripts that can be run
later
to do the conversion and (after testing) replacement of the old
version.




You think, I know, is the difference.

But as always
Patches cheerfully accepted.

And you *really* need to take this conversation to an RPM list instead.

I'd add the CC, but I have no idea what RPM you wish to use.

73 de Jeff______________________________________________ _
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-22-2009, 10:40 PM
Les Mikesell
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

Jeff Johnson wrote:
>
>> The reason the discussion is intertwined with packaging is that if you
>> name the delivered files the same, the old and new can never co-exist as
>> they should for the conversion and test period.
>>
>
> In fact, the old <-> new can/do coexist during upgrade; lib/fsm.c in RPM
> has had
> a form of apply/commit since forever that puts the new in place (the
> apply) but
> does not remove the old (renaming into old is the commit).

Co-existing, as in being stored somewhere isn't quite the point. They
both have to be able to be run, find the correct libraries, etc, and the
one currently known to work has to be found by other applications.

> And there are provisions to rename the old into a subdirectory
> as part of committing the new; at least the necessary path
> name generation including a subdirectory has been there
> since forever in RPM. Adding the necessary logic to
> achieve whatever goal is desired installing files is just not that hard,
> the code is a state machine.

But RPM can't do it unless it can always succeed with no user/admin
input. I don't believe that's possible.

> Personally (and as I pointed out), including old files in the new package
> is likelier to be reliable, and has the additional benefit that whatever
> conversions are needed can be done anytime, not just during a "window"
> during upgrade where old <-> new coexist.

But you can't replace my current old files with new ones of the same
name until you know they work. And you can't know that they work
because you don't know what applications I have.

> A conversion side-effect at
> the scale of a database conversion is hugely complicated to guarantee
> reliability during a "window". Are you volunteering to test?

Sure, if it is something like running a script, testing an app known not
to work with 8.3 (I think some versions of OpenNMS would qualify) and
then seeing if the back-out strategy works.

>> I think the only way it can be done reasonably is to install the new
>> code with different names and/or paths and scripts that can be run later
>> to do the conversion and (after testing) replacement of the old version.
>>
>
> You think, I know, is the difference.

That's why I want the conversion to be scripted.

> But as always
> Patches cheerfully accepted.
>
> And you *really* need to take this conversation to an RPM list instead.

It really doesn't have much to do with RPM. It has to do with naming
the replacement files so they don't overwrite the things that have to
remain.

--
Les Mikesell
lesmikesell@gmail.com

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-23-2009, 12:15 AM
John Summerfield
 
Default Upgrading postgresql ( CentOS/RHEL 5.3)

Les Mikesell wrote:
> Jeff Johnson wrote:
>> On Jan 22, 2009, at 2:00 PM, Les Mikesell wrote:
>>> I'd just like to see a realistic approach to updates via packages.
>>>
>> Reality check:
>>
>> You have a postgres upstream devel with years of experience
>> packaging postgres and me both saying
>> Don't attempt postgres database upgrades in packaging.
>>
>> But create your own virtuality reality approach if you want.
>>
>
> I think you missed my point, which is that RPM packaging doesn't provide
> facilities for what needs to be done. Postgres upstream is just more
> honest than most in recognizing the problem. It's not the only thing
> that ever has non-backward-compatible updates.
>
It's not hard to rebuild (some, at least) packages to use rpm's prefix
option. It allows to relocate the package at install time.

Doubtless Jeff will comment on the practicality of this, it's a feature
that's been around for years and years, but I've not seen it used much.

Best, though to have a complete test system where the entire application
- OS, database, webserver and anything else required is tested as an
integrated whole.

It's getting easier with so many virtualisation choices, but even that
aside most organisations of any size should be able to find an old
Pentium IV or better to test on.

--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 08:31 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org