Re: Simplifying hosting services (aka "breaking up the monolith")
Raymond Toy <[email protected]>
| Newsgroups | gmane.lisp.common-lisp-net.devel |
|---|---|
| Message-ID | <CAG14z1GaBr_oC6-37X1S698F8=X6iuSyKrAQ0aTVKu+dvsqKRg@mail.gmail.com> |
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 <[email protected]> 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