This issue proposes that we do away with our use of node id's to refer to objects wherever possible, and instead generate a unique text based ID to refer to the object. Each server, platform and site would have an identifier, which will be used to refer to it from the command line.

This on it's own, will allow us to simplify and extend our command line access api for the hosting front end.

Specifically, it would allow us to do things such as :
"drush hosting-add-site url.com --platform=platform_name --db_server=server_name" , instead of having to force the user to look up the relevant node id's.

This functionality is very closely aligned with the new drush 3.0 feature for "site aliases". I've discovered that they are actually poorly named. You can generate an alias for a platform, or a server. To be more accurate, these site aliases are a way to provide a different set of defaults, or could be considered an elegant way of specifying --config=configfile.

The way they are currently implemented requires them to be deeply nested arrays stored in your drushrc.php. While I don't necessarily agree with this, I have decided to not fight the current implementation , and instead in the near future modify drush so that i can directly influence which configuration files Drush will load, so that my required functionality can be contained inside provision.

What I want to do with this nifty tech, is modify Aegir so that the backend generates an 'alias' for each server, platform and site on the network in the $AEGIR_CONFIG directory. So all hostmaster needs to call is drush sitealias provision-migrate platformalias

This becomes interesting when multi-server becomes involved, because sitealias could be a site on one server, and platformalias could be a platform on another.

I intend to manage server aliases on remote servers too. For example, if you configure a database server called 'dbcluser'. There should be a matching serveralias on each of the web servers that need to be able to install sites on it. Hence, when you run the command drush remoteplatform provision-install domain.com --db_server=dbcluster, it will be able to connect from that server to the database cluster.

This conditional loading and configuration management also provides the correct solution to our problem here
#712016: Provision-intsall fails due to db_host defaulting to localhost, FQDN expected , and is a critical piece to having the server verify task work satisfactorily.

Furthermore , this will become important with cross server site migration, as it provides an agreed up mechanism for referring to resources in the network.

Comments

greg.1.anderson’s picture

greg.1.anderson commented

You are right that "site aliases" have grown into something more than the originally started out to be. It does beg the question, should they be renamed to something else?

Regarding storing aliases in individual files, I'm not opposed to that, but I think that your idea to enhance Drush configuration file loading is an even better idea. I for one am on-board with the direction that you want to take these features.

greg.1.anderson’s picture

greg.1.anderson commented

Related issues in the drush queue:

For the last, perhaps 'site-sync' needs to become 'provision-migrate' (that is, the former goes away in favor of the later), but I have some notes on some of my goals in that issue.

adrian’s picture

adrian commented

I just wrote a small patch which builds on some of the drush changes happening here #733256: Aliases should be loaded from a central location rather than drushrc.php

It generates a ~/.drush/aliases/$url.alias.drushrc.php , for each site that is managed in aegir.

At this point you can run any drush command on any site by simply typing -
drush @mysite.com status

This was just a quick hack to test out the API : #736686: Helper function to generate an alias record for the specified site: drush alias-add @aliasname

What needs to happen on the front end side of Aegir for this, is we need a new table , something like "hosting_entity".

The format is something like : 

  shortname   |  type  | oid
 ------------------------------
  somesite.com| site | 5
  myplatform | platform | 120

Then we will add a required field on all the managed entity forms (ie: site, platform, server .. maaaaybe client).

The important thing to note here is that they will be using a shared namespace, so we will need to somehow
ensure that they can't tread on one another.

We _could_ at the moment introduce a system such as $entity_$nid , ie : server_2 , platform_120. But i believe
that it is wrong to give the internal data storage on the front end have any special meaning in the backend.

drumm’s picture

drumm
he/him
Location NY, US
commented

@adrian - any code for this we can see?

adrian’s picture

adrian commented

no work on this yet, as ive been focussing on the backend mostly, and what it comes down to is that this is a front end change.

adrian’s picture

adrian commented
Status: Active » Needs work

i added some of this to the dev-services branch last night, namely that it keeps a 'hosting_context' table, based on the node title.

drumm’s picture

drumm
he/him
Location NY, US
commented

Context is a bit of a loaded word in Drupal. Should we use something more direct, like 'drush_alias'? Are more columns planned.

At the servers level, I've been coding one alias per-service. A web/db server would get two aliases. Is this OK? A site backed by a web/db for db and a separate web would get confused if the aliases are piled together.

Currently, aliases are written at provision verify exit. I'm not sure that is the right place. For example, we could potentially do aliases from the start and use them for verify.

adrian’s picture

adrian commented

it was determined that "site aliases" aren't the correct terminology, and they will be changed in drush 4.0 to be turned into "named contexts", and also merged and integrated with the drush_context api.

adrian’s picture

adrian commented

This has been in for a while.

what can we do to finalize this ?

adrian’s picture

adrian commented
Status: Needs work » Fixed

This is in master now.

Status: Fixed » Closed (fixed)
Issue tags: -aegir-0.4, -multi-server

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue tags: +aegir-0.4, +multi-server

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.

  • Commit dc43560 on 6.x-2.x, 7.x-3.x, dev-ssl-ip-allocation-refactor, dev-sni, dev-helmo-3.x by adrian: 
    Added hosting_context table and the upgrade path for shortnames from #...

  • Commit dc43560 on 6.x-2.x, 7.x-3.x, dev-ssl-ip-allocation-refactor, dev-sni, dev-helmo-3.x by adrian: 
    Added hosting_context table and the upgrade path for shortnames from #...