Guys, I would second Maxim's comments. While we have a large Oracle database here at my company, we are always looking for ways to cut costs. An Oracle 11g server costs a pretty penny and we are looking forward to having PostgreSQL available so that we can move our enterprise to it. From a large business perspective, you will find most businesses, large and small alike, looking for the low cost approach rather than the more supported approach. One of the things you should definitely be asking yourself is who is your user base. From my perspective, Spacewalk is meant to be used in a larger environment with tens of machines or more, not home users who have three machines and just want some more "Linux cred". I am the same as Maxim and don't know much about porting a database but I have implemented Spacewalk and from my large business perspective, we want PostgreSQL much more than we want to keep Oracle around.
Just my two cents... Jonathan Hooker Desktop Support - Engineering Garmin International [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Colin Coe Sent: Monday, May 03, 2010 5:57 AM To: [email protected] Subject: Re: [Spacewalk-devel] Moving postgres support forward Speaking only for myself, I believe is right to continuing supporting Oracle, if only due to the current install base. CC On Mon, May 3, 2010 at 4:09 PM, Maxim Burgerhout <[email protected]> wrote: > PostgreSQL support would really mean a lot to me and I dont think > alone. Please do not drop this. > > I understand it is hard to port the database from Oracle to PostgreSQL > (as it is a huge schema), but at my company we were highly > anticipating the future migration to PostgreSQL. We were really very > happy when it was announced PostgreSQL would be supported in a future > release. I mean, wasn't the embedded Oracle database one of the > reasons for Satellite's relatively high price tag? And PostgreSQL > being open source was a big plus, too. > > Sadly, I do not have the resources, nor the knowledge to do the > porting myself. Maybe the guys at EnterpriseDB (I think I remember Red > Hat partnering with them recently) could make a showcase project out > of this? To show how good PostgreSQL can do the work of an Oracle > database? > > Given the size of the schema, migrating to PostgreSQL from Oracle > instead of supporting both might be the only option if conversion > tools do not work well enough. Moving to PostgreSQL entirely would > have it's own complicated demands outside of the schema too, though. > Most large Red Hat-based deployments have pretty large Oracle clusters > too. If Satellite is regarded as mission critical and the database is > hosted on one of those Oracle clusters, dropping Oracle support might > make them slightly annoyed. And adding optional built-in redundancy > for PostgreSQL surely is complicated. > > Maxim Burgerhout > [email protected] > ---------------- > GPG Fingerprint > EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A > > > > On Fri, Apr 30, 2010 at 18:12, Travis Camechis <[email protected]> wrote: >> I agree it would be nice to not have to worry with oracle at all but I think >> people still would like to have the option and there are many people already >> using oracle in there spacewalk environment. >> >> On Fri, Apr 30, 2010 at 11:46 AM, Kevin Fox <[email protected]> wrote: >>> >>> On Fri, 2010-04-30 at 01:22 -0700, Miroslav Suchý wrote: >>> > On 04/29/2010 11:57 PM, James Hogarth wrote: >>> > > Hi all, >>> > > >>> > > Great to see the 1.0 milestone reached. Friday afternoons in my team >>> > > we assign to 'personal projects' and I've been thinking about trying >>> > > to help with the postgres side of things during this time I have >>> > > 'free'. >>> > > >>> > > The pgsql head in git hasn't had a commit in 9 months... is this even >>> > > valid anymore? >>> > >>> > Well... So what is status of PostgreSQL in Spacewalk? >>> > Yes, no one touched it for 9 months. We had other priorities. >>> > >>> > But anyway, what we have now: >>> > We partially convert our initial schema. >>> > There is some tool called Chameleon: >>> > https://fedorahosted.org/chameleon >>> > which was written by Jeff Ortel specially for Spacewalk. Chameleon can >>> > translate Oracle schema to PostgreSQL schema. But it is far from >>> > perfect. First - it is completely undocumented. Second - it can not >>> > translate everything. Just look at schema/spacewalk/postgres/manual/* >>> > how many things are converted manually. >>> > And maintaing two sets of SQLs schemas is no way. This will not work. >>> >>> I understand the complexities of maintaining two schemas. Just to throw >>> this idea out there, assuming the postgres backend was good enough, why >>> bother with the oracle one at all? Redhat usually focuses pretty hard at >>> having their open source projects only depend on other open source >>> projects. Or at very least, only optionally depend on the closed ones. >>> The effort could be spent porting to postgres once and drop oracle >>> support instead of trying to constantly convert code written for the >>> closed source oracle's sql to postgres. >>> >>> Kevin >>> >>> >>> > So >>> > we need something that will be able to translate *everything*. If it >>> > will be enhanced Chameleon or we start from scratch (e.g. by writing >>> > rules for good old sed) - that is question... >>> > >>> > And we just focused on initial schema for now. No one looked on SQL >>> > queries in our code. How do we (automatically) translate it to >>> > postgresql? Some queries are separated from code (hbm.xml) some are >>> > still in middle of the code. How we will handle this? What is the best >>> > way? How this all affect speed of code? Then there are some >>> > infrastructural changes which should be probably done prior finishing Pg >>> > support. >>> > >>> > A lot of question. We should decide some design questions, before we >>> > start coding. >>> > >>> > If you really want to help. You can take a look on Chameleon and >>> > investigate if it is worth of continuing in it and write some >>> > documentation for it. >>> > >>> > Or you can start with some simple Spacewalk bugs and first get overview >>> > of Spacewalk internals, before you start with more complex task, which >>> > Pg support is for sure. >>> > >>> > Or you can do some review of Spacewalk packages for Fedora: >>> > https://bugzilla.redhat.com/show_bug.cgi?id=F-Spacewalk >>> > >>> > Or anything else. But jumping directly on Pg support as you first >>> > contribution is probably not good idea. >>> > >>> >>> >>> _______________________________________________ >>> Spacewalk-devel mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/spacewalk-devel >> >> _______________________________________________ >> Spacewalk-devel mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/spacewalk-devel >> > > _______________________________________________ > Spacewalk-devel mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/spacewalk-devel > -- RHCE#805007969328369 _______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel -------------------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for the sole use of the intended recipient. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Thank you for your cooperation. _______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel
