Open jonpugh opened 6 years ago
When you chip away the essential properties of a platform, I see an issue coming up later add additional sites. For a third site do you get publish_path from site 1 or 2? Or will there be a 'primary' site that holds such information?
In OO fashion why not let the site class extend the platform class/interface? Then the platform level remains responsible, and the site has the info.
In OO fashion why not let the site class extend the platform class/interface? Then the platform level remains responsible, and the site has the info.
That's a decent idea, since the site would need all of the platform properties.
I'm not saying a site will represent a platform, I'm saying if we have a site with a publish path, makefile/gitrepo we can use those bits of info to create a platform.
Thanks for the tip, @helmo !
Inheriting PlatformContext was the key to making this a quick change. See PR at #32 and #30.
SiteContext has all platform properties now. If a --platform is specified on provision save
, it will populate the options from the platform as if you passed them from the command line (like --root
).
Works great!... Please move discussion specific to platform conversion to #30
User Experience
The user should not be expected to have any sysadmin knowledge.
The CLI will walk the user through every step of the way, explaining how things work when needed, being careful to not overwhelm the user with information.
Tasks should display a clean, clear summary of what is happening, but show no output by default, unless asked for with
--verbose
.The voice of Provision should friendly and helpful, always anticipating the users needs and communicating things as clearly as possible.
Self Setup
Provision should be able to install everything by itself.
The tool will detect what is already running on the system and offer to integrate with it. (Started this in d4596f993eead717403e28d13ab0f8aa4a433a39). Provision now checks to see if it's configuration is active in apache.
The tool will know how to install additional services if they do not yet exist.
Redefine "Platform".
In Aegir, "Platforms" were treated as primary entities, separate from sites, but required to install a site.
One problem with this is that some of the most important information for a site, like it's root path, and what web server it should be running on were associated with the platform, not the site itself.
In Provision 4, I propose we make Platforms optional. Platforms are like site templates. They allow for automating the site creation by storing default information like path and code-base. Let's treat Platforms less like a primary entity and more like a way to create a site template.
We must redesign the system so that the ServerContext sets itself up, and all you have to do to get a site is add a site.
Here's how we can remove the requirement of creating the platform first:
SiteContext
.ContextSubscriber
andContextProvider
, and just haveServerContext
andSiteContext
.PlatformContext
to not have a relationship to services at all.Developer Experience
composer global require
(or cgr) to add additional Service plugins.ExampleServiceClass::verify_site()
ExampleServiceClass::verify_platform()
ExampleServiceClass::verify_server()
More to come...