Deploying few Piers - options - smallwiki - INF Mailman

List overview All Threads
Download

Deploying few Piers - options

different description for "new"...

Build #514

Davorin Rusevljan

29 Apr 2011 29 Apr '11

4:50 p.m.

Hi, what would be suggested path if one wants to deploy few low traffic Piers? All Piers in one image or one image per Pier? Davorin Rusevljan http://www.cloud208.com/

Reply

Show replies by date

Reza Razavi

29 Apr 29 Apr

5:24 p.m.

Hi Davorin, It's technically possible to deploy one image with several distributions. I've already deployed a few ones. This reduces significantly the deployment costs. However, you may need to tweet parts of the code. However, as I've done this a few months ago, I unfortunately can't tell you where and what may exactly need changes. Cheers, Reza At 16:50 29/04/2011, Davorin Rusevljan wrote:

Hi, what would be suggested path if one wants to deploy few low traffic Piers? All Piers in one image or one image per Pier? Davorin Rusevljan http://www.cloud208.com/ _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Reply

Norbert Hartl

1 May 1 May

2:53 p.m.

Am 29.04.2011 um 16:50 schrieb Davorin Rusevljan:

Hi, what would be suggested path if one wants to deploy few low traffic Piers? All Piers in one image or one image per Pier?

If you are talking about low traffic this sounds like multiple kernels in one image is the easiest to do. You don't have multiple piers or pier distributions but multiple kernels that are attached two different paths via PRPierFrame. That is really easy to do and fast enough. Norbert

Reply

Reza Razavi

5:46 p.m.

The following would be a starting point (not tested): PRDistribution >> register: aString PRKernel reset. PRPierFrame registerAsApplication: aString kernel: self kernel PRDistribution register: 'pier1'. PRDistribution register: 'pier2'. PRDistribution register: 'pierN'. Each call to #register: (variant of exiting #register method) registers a different Pier distribution. But, as far as I remember, they share all by default the same 'files' folder. Hoping this helps, /Reza At 16:50 29/04/2011, you wrote:

Hi, what would be suggested path if one wants to deploy few low traffic Piers? All Piers in one image or one image per Pier? Davorin Rusevljan http://www.cloud208.com/ _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Reply

Norbert Hartl

2 May 2 May

9:45 a.m.

Am 01.05.2011 um 17:46 schrieb Reza Razavi:

The following would be a starting point (not tested): PRDistribution >> register: aString PRKernel reset. PRPierFrame registerAsApplication: aString kernel: self kernel PRDistribution register: 'pier1'. PRDistribution register: 'pier2'. PRDistribution register: 'pierN'. Each call to #register: (variant of exiting #register method) registers a different Pier distribution. But, as far as I remember, they share all by default the same 'files' folder.

Calling register this way is not advizable. As you can see it does 'PRKernel reset'. This will empty the instances on the PRKernel class side. You will end up having multiple kernels attached to PRPierframes as handler but only the last one will be attached to the instances of PRKernel. You're not able to e.g. select it from the configuration panel in seaside anymore. Using it without the reset is indeed a good idea. About the "files" folder. Pier uses Magritte and Magrittes MAExternalFileModel has a class side setting for the directory and path to use. So you are right, having all kernels in the same image means to share all files in the filesystem within the same directory. But I don't think this is a problem. You can easily divide them afterwards by having a visitor collecting the files for each kernel. I did this in my gemstone pier exporter utility: http://norbert.hartl.name/blog/pier-export-import-util-for-gemstone/ . Norbert

At 16:50 29/04/2011, you wrote:

Hi, what would be suggested path if one wants to deploy few low traffic Piers? All Piers in one image or one image per Pier? Davorin Rusevljan http://www.cloud208.com/ _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Reply

Reza Razavi

10:58 a.m.

Hi Norbert, I wanted just Davorin to have a pointer where to start with, and thanks for your additional precisions. So, to summarize, we have something like: PRDistribution >> register: aString PRPierFrame registerAsApplication: aString kernel: self kernel PRKernel reset. "to get ride of unwanted existing kernels" PRDistribution new register: 'pier1'. PRDistribution new register: 'pier2'. PRDistribution new register: 'pierN'. As mentioned before, I've not tested this script, since I actually use different objects (different distribution builder, kernel, and frame). Cheers, Reza

Reply

Davorin Rusevljan

11:03 a.m.

Thanks for all inputs! Are there any unexpected repercussions on persistence that I need to worry about? (I use ImageBased persistence currently) Davorin Rusevljan http://www.cloud208.com/

Reply

Norbert Hartl

11:30 a.m.

Am 02.05.2011 um 11:03 schrieb Davorin Rusevljan:

Thanks for all inputs! Are there any unexpected repercussions on persistence that I need to worry about? (I use ImageBased persistence currently)

You need to think about your persistence strategy. A image based persistence is tied to a kernel and every write to a kernel will trigger its image based persistence. But it will save the whole image. If you have a lot of kernels than all of them might try to write the image to disk. If you have low traffic than you might have even lower writes in your pier kernel. Thus making the problem a rather theoretical one. But you might want to think of it. Norbert

Reply

Reza Razavi

11:38 a.m.

At 11:03 02/05/2011, Davorin Rusevljan wrote:

Are there any unexpected repercussions on persistence that I need to worry about? (I use ImageBased persistence currently)

Nothing special to report, as far as I can remember now, but does not means zero risk. Basically, the (Debian) server contains: - one image and associated files, including the 'files' folder. - several virtual host configurations, one per distribution (in my configurations), which redirect http requests to the corresponding seaside/pier distribution/application. The image is automatically saved, each time one of the distributions is modified. This works technically fine, but the risk is to save your image with corrupted objects. For example, I had troubles with the search widget (on pages that contain text copied from a word document). All in all, AFAIK, this method is less frequently used for deploying Pier distributions. So, I'd recommend the follwoings: - double check some critical routines, including persistence, - configure both your server and image for a remote (emergency) access via VNC, and - backup regularly your image + files Hoping this helps, Cheers, Reza

Reply

4750

days inactive

4753

days old

smallwiki@list.inf.unibe.ch

Manage subscription

8 comments

3 participants

tags (0)

participants (3)

Davorin Rusevljan
Norbert Hartl
Reza Razavi