> Of course not, and it's not required with IPS today.

Now I'm confused; first you wrote that the service would have to be started 
upon reboot, then you write that it's not required. Which one is it?

> If you did want to be able to provision a new boot
> environment,
> it would be nice not to have to start Oracle as part
> of the
> postinstall script, though, wouldn't it?

Actually, that part has already been solved, namely (System V packages):

ABCDoracle-user
ABCDoracle-inventory
ABCDoracle-libs
ABCDoracle

That's the minimum required to install 32-bit Oracle on an i86pc system. All 
packages depend on ABCDoracle-user. ABCDoracle depends on ABCDoracle-inventory 
and ABCDoracle-libs.

ABCDoracle-user, ABCDoracle-inventory, and ABCDoracle-libs are perfectly 
installable with pkgadd -R.

However, ABCDoracle is NOT installable onto a non-live system, because as part 
of the init.ora configuration, some parameters, like "paralell_max_servers", 
whose formula is 4 x number of CPUs, must be calculated dynamically, since they 
are different for each system.

> IPS requires that all packages be able to be
> installed into a
> non-running image, so we do not support scripting as
> package
> developers never seem to understand that the software
> they're
> installing might not be able to run right now.

That is nothing more than a difference of personal opinion, and therein lies 
the problem.

Like I wrote before, your (Sun Microsystems') customers differ vehemently in 
that opinion.  I know this, simply because it is my job to know, and it put the 
bread on the table.

Now, the difference of opinion is: when the last package is installed, it 
"activates" the software. In my particular case, that last package is something 
like ABCDpowerdns-oracle-db, which creates the PowerDNS Oracle database, using 
the packages listed above.  In the postinstall phase, a specific 
initPOWERDNS.ora is created, modified to suit that particular database 
instance, then the SPFILE is crated, then the CREATE DATABASE statement is 
executed. Following that, standard $ORACLE_HOME/rdbms/admin/*.sql scripts are 
run, which generate the necessary Oracle structures inside of the database.
Finally, the POWERDNS schema is created and necessary privileges are assigned.
After that, the listener is configured and started.

The database is now up, running, and ready to accept and serve out data.

As you might have noticed, this all happens automatically. And it happens the 
same way each and every time, for each and every database. And it works on a 
live system which is in production.

These packages, together with this concept, have the capability to be deployed 
on a massive, unlimited number of live production systems.

It is consistently repeatable.

The only drawback is that it cannot be installed on a non-live system or a 
diskless or an AutoClient from the install server.

However, considering that for this tradeoff, I get databases, DNS, firewalls, 
mail, web and just about any other server at the mere push of a button, it's a 
small price to pay.

Main difference between your opinion and my experience is that you say: it must 
be installable on a non-running system, and I say: when I install it, it must 
run immediately and without any kind of manual intervention.

So soma packages are installable on a non-live system, while others must be 
installed on a running system, because

1. the server must not be rebooted under any circumstances
2. we need commands like psrinfo(1M) to run on that particular server in order 
to obtain information used to configure further (psrinfo(1M) is just one of the 
examples).

IPS, it seems does not offer the choice.  And it should. Judgding by what I saw 
and experienced, consistent repeatability is needed more than being able to 
install on a non-live system. I'm not asking that you start producing packages 
which break installing on a non-live system, just that IPS give me the option 
to choose in which way I will use it, concretely, I want to be able to execute 
arbitrary code, just like I'm able to do so in "preinstall", "postinstall", 
"preremove" and "postremove".

Another option would be, that I'm able to remotely svcadm enable SMF FMRIs.

For example, SD-UX has such capability, and has had it for the past twenty 
years or so. I see no reason why "the most advanced operating system on the 
planet" could not have it also.
-- 
This message posted from opensolaris.org
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss

Reply via email to