>Actually there's even less than that needed if we were to use a
>velocity template even perhaps stored as a file object in the
>database, $serverRoot is always defined as
>$apacheworker.getApache().getServerRoot(), I'm guessing we'd need to
>allow access to the apache worker, and maybe a collection or two to
>put stuff in and get it from. Although assuming we go down the
>velocity route we can look at adding in a 'toolbox' for the apache
>config or the tomcat config.
I think we are talking about the same thing, but I want to clarify my
thoughts to make sure. I imagined a velocity template file stored in the
database that has variables such as $serverRoot in it. These files would
be created and updated within the GUI by a user (similar to the way
files are maintained now). When a new worker is created, the server,
apache and template(s) would be selected. When the worker's config files
are deployed, it would build them from the template(s) selected and
deploy them.
By 'toolbox' are you referring to a location in Location where all of
these templates are maintained? I was thinking within the Administration
under something like 'Manage Templates'.
>Default vhost is created as part of the ApacheWorkerModel.buildConf()
>method, so assuming we're completely replacing that, the default vhost
>if desired, could be assumed to be included in the template.
I had in mind breaking this default virtualhost out of the apache head
matter (everything above the virtualhosts). This way, we share the same
configurations in the file while allow different default virtualhosts.
Something like the user would choose a head matter for their apache
instance and then choose the default virtualhost to go with it. This
would need to be done at the worker level. It reduces the need to
maintain several of the same head matters when the only difference in
the default virtualhost. This would make it easy to make a change in one
place and propagate the changes to all servers that use it.
>What different virtualhost templates did you have in mind? I don't
>see a use case where Virtualhost.buildVhostEntry() and
>Virtualhost.buildFullEntry() couldn't be replaced by something in the
>singular attached to an Apache Server template, assuming they should
>be as there's mod_jk stuff in there that really shouldn't be...
I figured different virtualhosts may have different rewrite rules or
location blocks. These vitrualhosts could vary even though they stay in
the same conf file. When a virtualhost is created, this template would
need to be selected. Do you have thoughts on how to handle different
virtualhost blocks within a single conf file?
>Another thought would be trying to find a solution where more than one
>file can be generated from the template. For example create the
>workers.properties and the httpd configuration file from the same
>template. Or the main part of the apache configuration file and each
>virtualhost in separate files.
That would be nice, but if this functionality were to be added, I think
it would be good to allow the user to choose which templates to use for
the full deployment. It sounds similar to a Hosting Pool where a
"hosting template" would be made up of one or more templates to deploy.
Eg: "Server 1 Template" would deploy "worker.properties_1" and
"httpd.conf_3". (see below)
>Here's thing - we do this right and it makes it real easy to add
>support for other App servers. It might even make the ApacheWorker
>and TomcatWorker classes obsolete, if we can reconcile the differences
>easily.
I like the idea of removing the ApacheWorker and TomcatWorker classes.
The true only difference between the two is the file that is deployed.
Perhaps replace them with a Worker class that has the functions build
and deploy configs. The contents of the file would be read from the
template.
It's starting to sounds like some sort of template builder would be
beneficial to have. First start by building the template of a file that
should be deployed and then add all of the files that should be deployed
to the main template. I made a quick example of how I think it would be
done below. 'Server 1 Template' would be deployed which would build and
deploy the rest of the files it contains.
Server 1 Template
- worker.properties_1
- httpd.conf_3
- head matter 2
- default virtualhost 1
- virtualhost a
- vhost template 1
- virtualhost b
- vhost template 5
- virtualhost c
- vhost template 1
-Jeff
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve
Toback
Sent: Tuesday, January 29, 2008 8:15 PM
To: [email protected]
Subject: Re: Templating configuration files
The offending method
org.apache.lokahi.httpd.api.worker.ApacheWorkerModel.buildConf(ApacheWor
ker
aw) (for httpd conf) certainly makes a few assumptions that may not be
true.
From a Lokahi perspective, the workers.properties should be optional...
On Jan 29, 2008 2:27 PM, Feist, Jeffrey <[EMAIL PROTECTED]> wrote:
> Hello. I am looking to making Lokahi's configuration files templated
> instead of the current hard coding approach. The goal would be to
allow
> any of the configuration files (server.xml, httpsd.conf, etc.) to be
> created from a template that is defined by a user. This would allow
> updates of the templates without requiring updated coding and
restarts.
> More info can be found here:
> https://issues.apache.org/jira/browse/LOKAHI-4
>
> I like Ludovic's approach using a factory, however it looks like it
> would still require a restart to load the additional template
> implementations into memory. Please correct me if I am wrong.
It's a great start, however it doesn't allow more than one class to
act as a vehicle for building the file at any given point, which makes
the tool expandable, but not to have a built in template.
> Another approach to consider is using velocity templates. Here we can
> have a variable in the template be populated with a value entered by
the
> user. Example: In the apache conf file, $serverRoot would be filled in
> with the apache.getServerRoot(); Using this approach, additional
> templates can be added at run time by users and can be updated if
> needed.
Actually there's even less than that needed if we were to use a
velocity template even perhaps stored as a file object in the
database, $serverRoot is always defined as
$apacheworker.getApache().getServerRoot(), I'm guessing we'd need to
allow access to the apache worker, and maybe a collection or two to
put stuff in and get it from. Although assuming we go down the
velocity route we can look at adding in a 'toolbox' for the apache
config or the tomcat config.
> Virtualhost blocks (including the default virtualhost) would also need
> the ability to be templated. I'm not sure the best way to have a user
> select which template they would want to use for their virtualhost. A
> single apache conf file may be using several different virtualhost
> templates at a time so my guess is that the template would need to be
> selected when the virtualhost is created.
Default vhost is created as part of the ApacheWorkerModel.buildConf()
method, so assuming we're completely replacing that, the default vhost
if desired, could be assumed to be included in the template.
What different virtualhost templates did you have in mind? I don't
see a use case where Virtualhost.buildVhostEntry() and
Virtualhost.buildFullEntry() couldn't be replaced by something in the
singular attached to an Apache Server template, assuming they should
be as there's mod_jk stuff in there that really shouldn't be...
Another thought would be trying to find a solution where more than one
file can be generated from the template. For example create the
workers.properties and the httpd configuration file from the same
template. Or the main part of the apache configuration file and each
virtualhost in separate files.
Here's thing - we do this right and it makes it real easy to add
support for other App servers. It might even make the ApacheWorker
and TomcatWorker classes obsolete, if we can reconcile the differences
easily.
Steve
------------------------------------------------------------------------------
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates (which may be known
outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD
and in Japan, as Banyu - direct contact information for affiliates is
available at http://www.merck.com/contact/contacts.html) that may be
confidential, proprietary copyrighted and/or legally privileged. It is
intended solely for the use of the individual or entity named on this
message. If you are not the intended recipient, and have received this
message in error, please notify us immediately by reply e-mail and then
delete it from your system.
------------------------------------------------------------------------------
