installation/unistallation process

[Mircea Toma <mi...@home.com>]

Peter,

Since I implemented some of the functionality of the
installation/unistallation process we have discussed, maybe you can give me
some feedback about what I did. More specifically what you think is good and
what is bad, what should be refactored, removed or added?

Mircea


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: installation/unistallation process

[Mircea Toma <mi...@home.com>]

Hi,

> DefaultDeploymentRecorder seems to expect that all applications will be
> installed in ../apps/<appname> because it will always look for install log
in
>
> ../apps/<appname>/install.log
>
> However if I run the following
>
> ./run --application /some/path/myapp.sar

I know about this. I just didn't implemented it yet.

>
> the above will not hold and thus install.log will not be generated.
Perhaps
> it would be better to have a separate directory
>
> ${phoenix.dir}/conf/install/
>
> in which is files like
>
> james-install.log
> myapp-install.log
> jo-install.log
> db-install.log
> etc.
>
> This would also keep the install log outside the application directory
(which
> would make it harder to accidently mess with it).
>
> Thoughts?

Yes, I thought using that approach too! I guess the only reason I did in
this way is to keep everything belonging to the app. in one directory.
I can change it no problem, since Paul gave his +1 on this too.

Mircea



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: installation/unistallation process

[Paul Hammant <Pa...@yahoo.com>]

>
>
>the above will not hold and thus install.log will not be generated. Perhaps 
>it would be better to have a separate directory
>
>${phoenix.dir}/conf/install/
>
>in which is files like
>
>james-install.log
>myapp-install.log
>jo-install.log
>db-install.log
>etc.
>
>This would also keep the install log outside the application directory (which 
>would make it harder to accidently mess with it).
>
>Thoughts?
>
+1



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: installation/unistallation process

[Peter Donald <do...@apache.org>]

On Fri, 2 Nov 2001 14:01, Mircea Toma wrote:
> Since I implemented some of the functionality of the
> installation/unistallation process we have discussed, maybe you can give me
> some feedback about what I did. More specifically what you think is good
> and what is bad, what should be refactored, removed or added?

Haven't looked at it yet - sorry ;)

Will try to have a look at it tomorrow. A few things I noticed. 
DefaultDeploymentRecorder seems to expect that all applications will be 
installed in ../apps/<appname> because it will always look for install log in

../apps/<appname>/install.log

However if I run the following

./run --application /some/path/myapp.sar

the above will not hold and thus install.log will not be generated. Perhaps 
it would be better to have a separate directory

${phoenix.dir}/conf/install/

in which is files like

james-install.log
myapp-install.log
jo-install.log
db-install.log
etc.

This would also keep the install log outside the application directory (which 
would make it harder to accidently mess with it).

Thoughts?

-- 
Cheers,

Pete

Duct tape is like the force.  It has a light side, and a dark side, and
it binds the universe together ...
                -- Carl Zwanzig

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: installation/unistallation process

[Peter Donald <do...@apache.org>]

On Tue, 13 Nov 2001 09:11, Mircea Toma wrote:
> Hi,
>
> > Got ome part bad news. I spoke to someone on the phone today who said
> > installation/uninstallation is evil ;) They managed to convince me that
> > in some circumstances it can be a real PITA and we should just fully
> > unzip
>
> .sar
>
> > on filesystem and rebuild "installation" each run.
>
> Ok. Although, I would like to know too what those circumstances may be?!


oops I forgot to explain things fully. Heres the basic rundown of the 
argument as I remember it.

In most cases avalon phoenix apps will be restricted to one machine. 90% of 
the time it will be developers who are deploying phoenix applications and 
running phoenix (as part of develope-test cycle). So in their case it has to 
be fast and easy. Directories are far easier than archives to work with in 
this. 

So when running a single instance of phoenix it ends up being of lower cost 
if you just extract extract everything onto filesystem. (or you don't even 
use archive at all).

In the cases where it is deployer adding an app there is little advantage 
either way. As we don't yet have a mechanism for easy upgrades there is no 
penalty for extracting full jar. You still have to hand manage upgrades. This 
will be even more the case when we have a management console that deployers 
can use to deploy apps from automagically.

> > Oh well - I still think we
> > need installation for when Phoenix is clusterable.
>
> Why?

Well I am not sure if the reason is legitimate but ... I think not extracting 
them is the *right* thing to do ;)

If you are going to do clustering of apps then it becomes less likely that 
developer needs will be same. (They will probably develope on one machine and 
then deploy to all ... the deploy step would of course require the .sar 
archive - hence no way to skip that step).
 
I guess it is mainly because it is the *right thing to do*. In the future 
when/if we have better update mechanims it will become more relevent but I 
guess less so now ;)

-- 
Cheers,

Pete

"The fact that a believer is happier than a skeptic is no more to the
 point than the fact that a drunken man is happier than a sober one.
 The happiness of credulity is a cheap and dangerous quality."
        -- George Bernard Shaw

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: installation/unistallation process

[Peter Donald <do...@apache.org>]

On Wed, 14 Nov 2001 11:12, Mircea Toma wrote:
> > I can come up are:
> >
> > a) "app-name", "app-name~", "app-name~~".....
> >
> > b) "app-name", "app-name-1", "app-name-3".....
> >
> > I prefer a) but, maybe there is a better one?!
>
> Ahh, I don't think this is right. If we change the name of the deployed
> application will make things more complicated. Let's suppose we have two
> applications having the same name "foo". When deploying the applications
> the result will be: first application (1) will be deployed in "apps/foo"
> directory and the second one (2) in "apps/foo~". Now if we reboot Phoenix
> and re-deploy only the application (2) the Deployer will deploy application
> (2) in application's (1) directory "apps/foo"!!!! Things get worse if we
> would use PersistentDeploymentRecorder (as you said already).
> So the simple solution would be to just print a message saying that an
> application with the same name is already deployed. We could also have an
> "--application-name" parameter passed at CLI.

urk. Starting to get complicated here. Couldn't we just use the full URI to 
application. ie the name would be

file:/some/file/location/phoenix/apps/blah.sar
file:/some/file/location/phoenix/another/apps/blah.sar

?

> Another problem is about "--application" parameter which I think is
> redundant. Its functionality could be achieved by starting Phoenix with a
> different deployment path using "--apps-path" (and having the .sar in that
> path).

hmm - I hadn't thought about that.

-- 
Cheers,

Pete

"The perfect way is only difficult for those who pick and choose.  Do not
like, do not dislike; all will then be clear.  Make a hairbreadth
difference and heaven and earth are set apart; if you want the truth to
stand clear before you, never be for or against." - Bruce Lee

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: installation/unistallation process

[Mircea Toma <mi...@home.com>]

Hi,

> > * secondly when we have two different apps that have the same name .sar,
> it
> > will not install the secon one. ie imagine there was a foo.sar in the
> > ${phoenix.home}/apps and we executed the following
> >
> > ./run.sh --application /some/other/dir/foo.sar
> >
> > This would not work because there is already an app named "foo". So we
> need
> > to think of a way to work around that.
>
> Yeah, I know! I guess we have to pick a re-naming convensions. The ones
that
> I can come up are:
>
> a) "app-name", "app-name~", "app-name~~".....
>
> b) "app-name", "app-name-1", "app-name-3".....
>
> I prefer a) but, maybe there is a better one?!


Ahh, I don't think this is right. If we change the name of the deployed
application will make things more complicated. Let's suppose we have two
applications having the same name "foo". When deploying the applications the
result will be: first application (1) will be deployed in "apps/foo"
directory and the second one (2) in "apps/foo~". Now if we reboot Phoenix
and re-deploy only the application (2) the Deployer will deploy application
(2) in application's (1) directory "apps/foo"!!!! Things get worse if we
would use PersistentDeploymentRecorder (as you said already).
So the simple solution would be to just print a message saying that an
application with the same name is already deployed. We could also have an
"--application-name" parameter passed at CLI.

Another problem is about "--application" parameter which I think is
redundant. Its functionality could be achieved by starting Phoenix with a
different deployment path using "--apps-path" (and having the .sar in that
path).

Mircea


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: installation/unistallation process

[Mircea Toma <mi...@home.com>]

Hi,

> Got ome part bad news. I spoke to someone on the phone today who said
> installation/uninstallation is evil ;) They managed to convince me that in
> some circumstances it can be a real PITA and we should just fully unzip
.sar
> on filesystem and rebuild "installation" each run.

Ok. Although, I would like to know too what those circumstances may be?!

> Oh well - I still think we
> need installation for when Phoenix is clusterable.

Why?

> So maybe we can add a CLI
> argument that turns on installation like it is now ;)

will do!

> The only issues with the current setup that I noticed were the following.
> * I don't like a storing it in directory named var/ as that is too unix
> specific and most people I know who are windows people and can get
confused
> with var/ and etc/ type names. So perhaps something simpler like
> installations/ or installs/ or conf/installs/ or similar. I think I like
> conf/installs the best.

Ok. No problem!

> * secondly when we have two different apps that have the same name .sar,
it
> will not install the secon one. ie imagine there was a foo.sar in the
> ${phoenix.home}/apps and we executed the following
>
> ./run.sh --application /some/other/dir/foo.sar
>
> This would not work because there is already an app named "foo". So we
need
> to think of a way to work around that.

Yeah, I know! I guess we have to pick a re-naming convensions. The ones that
I can come up are:

a) "app-name", "app-name~", "app-name~~".....

b) "app-name", "app-name-1", "app-name-3".....

I prefer a) but, maybe there is a better one?!

Mircea


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: installation/unistallation process

[Peter Donald <do...@apache.org>]

Hi,

Got ome part bad news. I spoke to someone on the phone today who said 
installation/uninstallation is evil ;) They managed to convince me that in 
some circumstances it can be a real PITA and we should just fully unzip .sar 
on filesystem and rebuild "installation" each run. Oh well - I still think we 
need installation for when Phoenix is clusterable. So maybe we can add a CLI 
argument that turns on installation like it is now ;) 

The only issues with the current setup that I noticed were the following.
* I don't like a storing it in directory named var/ as that is too unix 
specific and most people I know who are windows people and can get confused 
with var/ and etc/ type names. So perhaps something simpler like 
installations/ or installs/ or conf/installs/ or similar. I think I like 
conf/installs the best.
* secondly when we have two different apps that have the same name .sar, it 
will not install the secon one. ie imagine there was a foo.sar in the 
${phoenix.home}/apps and we executed the following

./run.sh --application /some/other/dir/foo.sar

This would not work because there is already an app named "foo". So we need 
to think of a way to work around that.

-- 
Cheers,

Pete

--------------------------------------------------------------
"Science is like sex: sometimes something useful comes out, 
but that is not the reason we are doing it" -- Richard Feynman
--------------------------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>