Simplifying hosting services (aka "breaking up the monolith")

[Raymond Toy]

I support whatever changes you want to make that make your life easier.

I'll do whatever I need to do to make sure my stuff works with the new
scheme.  Just let me know (and give me a bit of time if it requires some
non-trivial effort on my part.)

On Tue, Jan 11, 2022 at 11:25 AM Erik Huelsmann <ehuels at gmail.com> wrote:

> Hi,
>
>
> In 2021, common-lisp.net has had two types of service interruptions:
> (1) mailing lists were not functioning correctly [while regular mail
> traffic seemed to be] an (2) deployment of project sites wasn't
> working. The latter only came to light recently, but seems to have
> existed for some time.
>
> Since I can remember (probably since the creation of the service) has
> common-lisp.net hosted its project webpages on its main domain in a
> sub directory, which at times has been called /project/, or /projects/
> or even /p/. This setup mixes project hosting with hosting for the
> main site itself and restricts the tooling we can use to host the
> projects' websites. The reason for the sites not deploying well is
> that I've implemented a workaround in the past to be able to deploy
> projects using GitLab Pages while our deployment model (deploying to
> the /project/ subdirectory on the main domain) is out of line with
> what GitLab Pages were designed for.
> At the same time, our configuration is running with extensive sets of
> rewrite rules to keep historic URLs "working" and redirected to
> (hopefully) existing current URLs, which also extremely complicates
> our setup.
>
> In order to simplify our setup (and eliminate the deployment problems
> we're experiencing) and at the same time add support for requests like
> those from Marco who wants to be able to deploy sites for multiple
> projects under the same umbrella, I've decided I want to move
> projects' sites to their own (sub)domains. In the past I thought this
> would need to be subdomains along the lines of
> https://<project>.project.common-lisp.net/. Although that's a
> deployment model that would work with GitLab Pages, I've decided
> against it. I'll move the hosted projects to:
>
>    https://<project>.common-lisp.dev/
>
> (I acquired common-lisp.dev for this purpose this morning.)
>
> The setup I'm proposing is that we have a good look at the tons of
> rewrite rules we have currently in place and clean up the rewrite
> rules that we don't need anymore. Then, we create rewrite rules for
> the current project namespaces at
> https://common-lisp.net/project/<project>/ to map to
> https://<project>.common-lisp.dev/. There are a few projects which
> aren't using GitLab Pages to deploy their websites yet, mostly because
> they have no active maintainers. These projects will keep being served
> from their current locations on the filesystem of the common-lisp.net
> host, but their content will be available through the new
> <project>.common-lisp.dev URL space.
>
>
> Further change proposals in order to separate the mail flow for the
> mailing lists from the regular mail flow (and thereby further reducing
> integration between components) are upcoming, but I'll need to address
> one thing at a time (due to time constraints).
>
>
> Are there any comments, remarks, additions, things you want me to take
> into account with respect to the above?
>
>
> --
> Bye,
>
> Erik.
>
> http://efficito.com -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
>
>

-- 
Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clo-devel/attachments/20220111/158b4e9c/attachment.html>