I propose that we make every attempt to use virtual hosts and explicit DNS for services that we provide. This document will outline the proposal and why I think this is important for us in the future.
As Jason pointed out, some search engines penalize certain layouts. As evidenced by the "Subversion is 403 right now" thread, monkeypatching with rewrites can have unintended consequences and eventually get downright impossible to track through and maintain. For an organization as multifaceted as we are, I do not think that mere rewriting is a long term solution.
Our experience on Collabnet showed us that a massive proliferation of DNS-bound services can be a large burden. Knowing where you are and what you were dealing with was tiring and tedious. On the other hand, explicit separation of either projects or services will provide us flexibility in the future. I propose that we choose one -- separate based on services or separate based on project -- for things like Trac, Subversion, Buildbot, and Web hosting. CN's approach was ok except for the fact that it proliferated so many "projects" that things got crazy. Right now, we have all of our eggs in this bucket, but in the future we may want to spread a few around.
Some virtues of this approach include:
- Our ability to offload this service from the existing single machine to someplace else when and if we need to without much service disruption and minimal migration (URL relocation pain).
- Guess-able and non-redundant URLs, once we establish a pattern and stick to it.
- Fat-fingering a setting in one virtual host doesn't hose everyone else. If we're to distribute the administration load, it is important that changes be as localized as possible.
Thoughts or comments? Project based or service based (makes no difference to me, as long as we choose one)? When we come to agreement on how to proceed, I'll write up a "policy doc" for the wiki that we can follow when adding new services/projects.
This all makes sense to me. There is increasing need for web hosting with vhosts, it seems, as more projects move over to this new infrastructure. I prefer the project-based names but could argue either way.
Tyler
On 22-Jan-07, at 12:53 PM, Howard Butler wrote:
All,
I propose that we make every attempt to use virtual hosts and explicit DNS for services that we provide. This document will outline the proposal and why I think this is important for us in the future.
As Jason pointed out, some search engines penalize certain layouts. As evidenced by the "Subversion is 403 right now" thread, monkeypatching with rewrites can have unintended consequences and eventually get downright impossible to track through and maintain. For an organization as multifaceted as we are, I do not think that mere rewriting is a long term solution.
Our experience on Collabnet showed us that a massive proliferation of DNS-bound services can be a large burden. Knowing where you are and what you were dealing with was tiring and tedious. On the other hand, explicit separation of either projects or services will provide us flexibility in the future. I propose that we choose one -- separate based on services or separate based on project -- for things like Trac, Subversion, Buildbot, and Web hosting. CN's approach was ok except for the fact that it proliferated so many "projects" that things got crazy. Right now, we have all of our eggs in this bucket, but in the future we may want to spread a few around.
Some virtues of this approach include:
- Our ability to offload this service from the existing single machine to someplace else when and if we need to without much service disruption and minimal migration (URL relocation pain).
- Guess-able and non-redundant URLs, once we establish a pattern and stick to it.
- Fat-fingering a setting in one virtual host doesn't hose everyone else. If we're to distribute the administration load, it is important that changes be as localized as possible.
Thoughts or comments? Project based or service based (makes no difference to me, as long as we choose one)? When we come to agreement on how to proceed, I'll write up a "policy doc" for the wiki that we can follow when adding new services/projects.
Thoughts or comments? Project based or service based (makes no
difference to me, as long as we choose one)? When we come to
agreement on how to proceed, I'll write up a "policy doc" for the
wiki that we can follow when adding new services/projects.
I don't have any thoughts to this, but if virtual hosts subject has been
taken up, I'd like to ask for including Buildbot to the overall strategy.
Thoughts or comments? Project based or service based (makes no difference to me, as long as we choose one)? When we come to agreement on how to proceed, I'll write up a "policy doc" for the wiki that we can follow when adding new services/projects.
Howard,
I am in favor of your suggestion, and I think a virtual server "per service"
with subdirectories for each project addressed seems like it would be
easiest to maintain.
I'm a bit leery about changing svn urls now that some usage has been
built around the http://svn.osgeo.org/svn/gdal even though it is redundant.
Note that we already have download.osgeo.org and buildbot.osgeo.org
at telascience in addition to svn.osgeo.org on the new machine.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
Thoughts or comments? Project based or service based (makes no difference to me, as long as we choose one)? When we come to agreement on how to proceed, I'll write up a "policy doc" for the wiki that we can follow when adding new services/projects.
Howard,
I am in favor of your suggestion, and I think a virtual server "per service"
with subdirectories for each project addressed seems like it would be
easiest to maintain.
I'm a bit leery about changing svn urls now that some usage has been
built around the http://svn.osgeo.org/svn/gdal even though it is redundant.
Moving to a different location is trivial client-side with an 'svn switch' command as long as the old URL sticks around for a little while.
Note that we already have download.osgeo.org and buildbot.osgeo.org
at telascience in addition to svn.osgeo.org on the new machine.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org Sac Info Page
Thoughts or comments? Project based or service based (makes no difference to me, as long as we choose one)?
I think I'd go with service-based because that allows moving specific services to separate machines without changing the URLs. As traffic to our sites increase, we will inevitably need to move services to separate boxes, so we might as well plan for that now.
When we come to agreement on how to proceed, I'll write up a "policy doc" for the wiki that we can follow when adding new services/projects.
+10 for the policy doc. Glad to see that I'm not the only one to think that we need to set some rules in order to keep things organized.
1. Services have their own domains, e.g. svn.osgeo.org, trac.osgeo.org, etc. For the reason already mentioned, the ability to offload services.
2. Hosted projects have their own domain, e.g. mapguide.osgeo.org. This keeps them out of the www namespace and gives the root www project and software projects more flexibility in content, navigation, and presentation.
Bob
Daniel Morissette wrote:
Howard Butler wrote:
Thoughts or comments? Project based or service based (makes no difference to me, as long as we choose one)?
I think I'd go with service-based because that allows moving specific services to separate machines without changing the URLs. As traffic to our sites increase, we will inevitably need to move services to separate boxes, so we might as well plan for that now.
When we come to agreement on how to proceed, I'll write up a "policy doc" for the wiki that we can follow when adding new services/projects.
+10 for the policy doc. Glad to see that I'm not the only one to think that we need to set some rules in order to keep things organized.
I propose that we make every attempt to use virtual hosts and explicit DNS for services that we provide. This document will outline the proposal and why I think this is important for us in the future.
As Jason pointed out, some search engines penalize certain layouts. As evidenced by the "Subversion is 403 right now" thread, monkeypatching with rewrites can have unintended consequences and eventually get downright impossible to track through and maintain. For an organization as multifaceted as we are, I do not think that mere rewriting is a long term solution.
Our experience on Collabnet showed us that a massive proliferation of DNS-bound services can be a large burden. Knowing where you are and what you were dealing with was tiring and tedious. On the other hand, explicit separation of either projects or services will provide us flexibility in the future. I propose that we choose one -- separate based on services or separate based on project -- for things like Trac, Subversion, Buildbot, and Web hosting. CN's approach was ok except for the fact that it proliferated so many "projects" that things got crazy. Right now, we have all of our eggs in this bucket, but in the future we may want to spread a few around.
Some virtues of this approach include:
- Our ability to offload this service from the existing single machine to someplace else when and if we need to without much service disruption and minimal migration (URL relocation pain).
- Guess-able and non-redundant URLs, once we establish a pattern and stick to it.
- Fat-fingering a setting in one virtual host doesn't hose everyone else. If we're to distribute the administration load, it is important that changes be as localized as possible.
Thoughts or comments? Project based or service based (makes no difference to me, as long as we choose one)? When we come to agreement on how to proceed, I'll write up a "policy doc" for the wiki that we can follow when adding new services/projects.
I propose that we make every attempt to use virtual hosts and
explicit DNS for services that we provide. This document
will outline the proposal and why I think this is important
for us in the future.
I propose that we choose one -- separate based
on services or separate based on project -- for things like
Trac, Subversion, Buildbot, and Web hosting. CN's approach
was ok except for the fact that it proliferated so many
"projects" that things got crazy. Right now, we have all of
our eggs in this bucket, but in the future we may want to
spread a few around.
We seem to have consensus for service-based URLs. A few more questions:
1) Does are accepting and implementing a policy affect other OSGeo groups that we aren't immediately thinking about? geodata, wiki, education, etc? Do we need their input?
2) How should we go about implementing? Do so immediately and point people to the new URLs with a transition period supported by rewrites?
We seem to have consensus for service-based URLs. A few more questions:
1) Does are accepting and implementing a policy affect other OSGeo groups that we aren't immediately thinking about? geodata, wiki, education, etc? Do we need their input?
Just for background, during migration we did not recreate all the vhosts that CN project sites had since so many of them were nothing more than a single page.
As a result, project-based URLs are not being used very much at the moment, as we didn't port over more than Mapbender, MapGuide and FDO projects. I think it will be easiest from the Drupal admin point of view to have the www face for projects use project-based URLs - where there is 1 vhost per drupal instance. But put up the other services up as service-based URLs.
2) How should we go about implementing? Do so immediately and point people to the new URLs with a transition period supported by rewrites?
You will see a bunch of rewrites already, at least for the www stuff, to help emulate the past vhost-style setup and forward it to osgeo.org/<project>. This has worked fine except that now certain projects (geodata, local chapters) need to manage the whole content for their site and not just a few pages - so it seems like there is increasing need to stand up more drupal instances.
You will see a bunch of rewrites already, at least for the www stuff, to help emulate the past vhost-style setup and forward it to osgeo.org/<project>. This has worked fine except that now certain projects (geodata, local chapters) need to manage the whole content for their site and not just a few pages - so it seems like there is increasing need to stand up more drupal instances.
Tyler,
I can understand wanting distinct drupal instances for projects like
MapGuide, FDO and Mapbender (assuming they don't prefer to stay wiki
based), but do committees like geodata and local chapters actually
require distinct drupal instances? Perhaps an ambitious local chapter
that wants an extensive amount of material might want it's own
instance, but for the amounts of material currently living in the
Wiki this doesn't seem critical.
I guess my point is that I'd prefer avoiding a proliferation of
Drupal instances if there isn't pressing need. Amoung other things
we reduce the benefit of the built in drupal search stuff as we
split things into many instances.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
I agree and was arguing that point earlier - I'd personally rather see fewer drupal instances, that's for sure.
On 23-Jan-07, at 8:16 AM, Frank Warmerdam wrote:
Tyler Mitchell wrote:
You will see a bunch of rewrites already, at least for the www stuff, to help emulate the past vhost-style setup and forward it to osgeo.org/<project>. This has worked fine except that now certain projects (geodata, local chapters) need to manage the whole content for their site and not just a few pages - so it seems like there is increasing need to stand up more drupal instances.
Tyler,
I can understand wanting distinct drupal instances for projects like
MapGuide, FDO and Mapbender (assuming they don't prefer to stay wiki
based), but do committees like geodata and local chapters actually
require distinct drupal instances? Perhaps an ambitious local chapter
that wants an extensive amount of material might want it's own
instance, but for the amounts of material currently living in the
Wiki this doesn't seem critical.
I guess my point is that I'd prefer avoiding a proliferation of
Drupal instances if there isn't pressing need. Amoung other things
we reduce the benefit of the built in drupal search stuff as we
split things into many instances.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
