I'd echo this sentiment. Having worked on a number of large corporate Satellite
installations, I can't think of a single client who wouldn't jump at the chance
of ditching the extra Oracle licenses involved.
Maintaining support for an Oracle back end may be a requirement, but from my own
experience, moving to PostgreSQL as the primary development effort would not
raise any eyebrows in corporate-land. It would also help broaden the appeal of
Spacewalk amongst the open source development community as coders for other
distros will likely (IMO) view the Oracle dependency as a blocker to them
investing their time. Opening the path for other distros to develop Spacewalk
as their management tool can only be a good thing I reckon.
Cheers
Duncan
On 03 May 2010 at 17:01 "Hooker, Jonathan" <[email protected]> wrote:
> 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
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
