Hi Herb,
Personally, I have my TG applications managed by supervisord. Worth a
look!
(just google for "paster supervisord", and ask if you get stuck ;) )
Kind regards,
Jasper
On Nov 5, 9:49 pm, herb <[email protected]> wrote:
> Thanks, Diez.
>
> That was really good advice. There were downstream scripts that would
> have needed changing as well, so I ended up doing something
> different. But your comment was what pushed me over the top in
> understanding it.
>
> Basically, I had two problems. The second one was that once one of
> the TG applications started, it took control of the session and
> nothing more would run. So I had to make the TG applications run as
> background processes.
>
> What I ended up doing is to use my virtual environments, start the TG
> application in background, then deactivate the environment, and
> activate the other virtual environment. Run the second TG application
> in background. This seems to have worked fine. Thanks so much for
> your advice.
>
> Herb
>
> On Nov 4, 10:01 am, "Diez B. Roggisch" <[email protected]> wrote:
>
> > On Thursday, November 04, 2010 17:44:10 herb wrote:
> > > Hi, folks.
> > > I have been building an appliance in a virtual machine. I have one
> > > TG2 instance running on one port which is the master dashboard for all
> > > applications. I have a second instance that I want to run which will
> > > provide some RESTful functionality on another port. I have two
> > > virtual environments, one running the dashboard application and
> > > another application and the second running the new (second TG)
> > > instance. It all starts up from a script in init.d when the virtual
> > > machine is started (or at least it is supposed to).
>
> > > Now my real question is this. What is the best way to deploy the two
> > > TG instances? I can start one virtualenv in the setup script, but I
> > > get errors if I try to set up a second virtualenv. I still have to
> > > track down the nature of the errors, but the applications both run if
> > > I start them by hand in separate terminal sessions.
>
> > > This is what I am doing:
> > > Activate VirtualEnv1 (source path1_to_bin/activate)
> > > Start up applications from this virtualenv.
>
> > > Activate VirtualEnv2 (source path2_to_bin/activate)
> > > start up second TG instance.
>
> > > These are the alternatives I have thought to use:
> > > (1) deactivate the first VirtualEnv before activating the second
> > > (could be path issues)
> > > (2) Move everything around so that there is only one virtualEnv
> > > (3) Move everything out the virtualEnv.
>
> > > So, any strategic thoughts on how best to proceed?
>
> > You don't need no activation business. Activation is "only" for making your
> > current shell environment pick the proper commandline tools first.
>
> > Instead, use fully qualified paths to your paster-scripts (and/or python,
> > easy_install and so forth), and you're good.
>
> > We do that in a two-application mod_wsgi scenario (live/stage) with
> > completely
> > different VEenvs without a hitch.
>
> > Diez
--
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en.
