Configurable context/alias names

Actually, come to think of it, it'd be nice to provide front-end fields to allow user-specified aliases to be generated for all Aegir entities.

can we put an alias of an alias in an alias?

Yes... yes, we can. By moving to GROUPNAME.aliases.drushrc.php:

$ cat ../hostmaster.aliases.drushrc.php

$aliases['hostmaster'] = array (
  'context_type' => 'site',
  'platform' => '@platform_hostmaster',
  'server' => '@server_master',
  'db_server' => '@server_localhost',
  'uri' => 'aegir2.aegir2.local',
  'root' => '/var/aegir/hostmaster-6.x-2.x',
  'site_path' => '/var/aegir/hostmaster-6.x-2.x/sites/aegir2.aegir2.local',
  'site_enabled' => true,
  'language' => 'en',
  'client_name' => 'admin',
  'aliases' => 
  array (
  ),
  'redirection' => false,
  'cron_key' => '',
  'profile' => 'hostmaster',
);
$aliases['hm'] = array(
  'parent' => '@hostmaster',
);

We could generalize this, and add a '--drush-aliases' option to provision-save. We could then alter the template to iterate through such a list, adding arbitrary aliases. Down the road we could add a front-end field to allow #1057698: Configurable node title for hosting import (though the discussion in that issue appears to be about something else entirely.)

So, the first patch adds the ability to specify '--drush_aliases=foo,bar' during provision-save for sites, and has site aliases generated as alias groups. The second (pretty trivial) patch adds the 'hm' alias for hostmaster sites.

I suppose we could use the same template for both.

Now using the same template.

We need the new context in order to write to a new file name.

In IRC discussions, anarcat suggested moving to *.aliases.drushrc.php for platforms and servers too. We'll also need to clean up the old aliases. So bumping to 3.x

So, yeah... it looks like all *.aliases.drushrc.php files are included in every drush command, whereas only the named alias file is loaded.

We don't actually need the group alias functionality, per se. It is designed to run commands against lists of aliases. Perhaps we'd be better off generating additional *.alias.drushrc.php instead. Unfortunately, 'parent' won't work for that, so we'd need to replicate the whole alias in each file. Still, it should be pretty easy, as write_alias() could just iterate over the extra alias names using the same $properties.

I don't think I understand the suggestion. It's Drush that'll parse any and all *.aliases.drushrc.php files it can find...

oh, I see. That should work.

Actually, come to think of it, I'm not sure why we would do #14, instead of just writing out the alias anew with the alternate name. The attached patch does so, and as a result makes only very minimal changes. I guess we'd need to clean up these extra aliases too.

The provision-shorter_hm_alias-2031397-4.patch patch from #4 is still required for this to work with the hostmaster alias.

FWIW, I'd still like to squeeze this into 2.x, since I feel that its a significant CLI usability win, and an 'experimental' front-end feature should be pretty easy to write.

Here's a single patch that combines the one in #16 and the one from #4 that adds the '@hm' alias, along with cleanup of these new aliases.

There aren't any credentials in hostmaster.alias.drushrc.php...

Boy, it'd be nice to get this into 2.x... Just sayin'...

Well, 7.x-3.x is open for dev, so I'm going to look at merging this.

#1057698: Configurable node title for hosting import used to have this title, but I think it's more appropriate here. The general use-case and proposed solution would allow for any context to have additional aliases generated. Once the Provision component is in, I'll move this over to the Hosting queue for the addition of front-end and IPC components.

grr, title typo.

Merged the patch form #17 into Provision in dfc48d6. Yay, @hm!

If anyone wants to implement the front-end components to take advantage of this, be my guest.