>On Jan 30, 2008 11:17 AM, Feist, Jeffrey <[EMAIL PROTECTED]>
wrote:
>> 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'.
>
>Velocity has a 'toolbox' capability - ie the toollbox.xml under conf
>is the config for the velocity servlet.
>
>Would you even need to put these templates in visually different
>location in the gui?
No.
>
>The only reason we currently have the current File object is for
>apache head matter. Those pages and objects could just be reused,
>no?
Yes, we could reuse those objects but the pages would likely need a
rename. Simply switching 'File' to 'Template' is a minor task and can be
an afterthought.
>
>> 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.
>
>We have Pool -> worker -> server
>
>Why would you put the configuration for the 'head template' at the
>worker level, when we currently do it at the server level. Not that I
>am against it, but what's the pros of putting it there in your mind?
>
I would still want to keep the config for the head matter at the server
level, but would want to move the default virtualhost settings to the
worker level. Currently there is no place to define the directives in
the default virtualhost. If the default virtualhost was included in the
main template, a new template would be needed for every default
virtualhost that has different directives. Correct?
If so, there could be several templates with all of the same head matter
but different default virtualhosts. If something in the head matter
would need to be changed (a new module for example), it would need to be
changed in every one of these templates. If every worker was using the
same head matter with a different default vhost, the change would only
need to be made in one place.
>> >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?
>
>A virtualhost 'template' is currently in Lokahi defined as:
>
><Virtualhost <$IP>:80>
>$Vhostcontents
><ifmod mod_jk>
>$contexts
></ifmod>
></virtualhost>
>
>what are you intending to define that to?
>
I see that being one template. Instead of having the user type the same
location blocks and rewrite rules, they could provide their own
additional templates. (See bottom of email for example)
>
>> >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.
>
>and graceful which apache has and tomcat does not - but that could be
>accounted for somehow.
True. Maybe as a first approach move the build and deploy method from
the workers to a generic template class and then work on the specific
actions (restart, graceful, configtest, etc.) later.
>
>> 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
>>
>
>What's the difference between template 1 and 5. I'm failing to see
>what benefit you'd gain from not having it all in one template file,
>or a reason to have more than one vhost template.
>
If there are some common directives that are always used, wouldn't it
make sense to have these stored? For example, this could be vhost
template 1 (aka 'default')
<Virtualhost <$IP>:80>
$Vhostcontents
<ifmod mod_jk>
$contexts
</ifmod>
</virtualhost>
Vhost template 2 could then be:
<Virtualhost <$IP>:80>
<location /test>
SetHandler test-handler
</location>
$Vhostcontents
<ifmod mod_jk>
$contexts
</ifmod>
</virtualhost>
This gives the user the ability to choose a vhost template that fits
their needs without having to write the additional information. I agree
that the 'standard' template would still work but it would require the
user to provide the same information for every vhost. Maybe this could
be a phase 2 task for templating?
------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------
