Dynamic Aliases #5225
Comments
|
See discussion at uselagoon/lagoon#147 |
|
See that discussion for what? As far as I can tell, that discussion was left in limbo with no resolution to the issue of creating dynamic aliases. I'd already read that. Is there something I'm missing here? I did stumble upon SiteAliasAlterCommands.php, but all it does is modify existing aliases which isnt useful in this context. I tried to get it to work and it didnt function anyway. The method never gets called. However even if I did get it running, it wouldnt be what I need anyway :/ And trying to use wildcards defeats the purpose of dynamic aliases because you still need 1 file per alias according to greg anderson (because first piece of the alias name itself is part of the alias filename and cant be overriden) and for our purposes that would be adding 5500+ files and growing rapidly. Dynamic aliases is the only option. 1 ring to rule them all :D What's needed is close in SiteAliasAlterCommands.php but it doesnt allow creation of new aliases. It needs to have a method for creation (along with docs on how to use it all, current docs wrong and/or not clear enough). If that already exists, then the docs dont make it clear at all. I'd need an example. Is there truly no way to create aliases programmatically like there was in previous versions of Drush short of re-inventing the wheel and recoding drush itself the way it should have been in the first place? That would be quite the massive regression :/ The previous drush method of handling aliases was far superior and was not slower by any stretch of the imagination. We had 5500+ dynamic aliases without any noticeable performance degradation. I did see Greg anderson's comment that he said the new alias system was faster or something. IMO it's a moot point when it's not a noticeable difference. It might be faster, but it's certainly not superior. Speed isnt everything. Fighter Jets are faster than airline jets. But are you going to fly a figher 3000 miles with 100 passengers on board or buy 100 fighters and fly them at the same time? The airliner makes more sense, as did the previous alias system until dynamic aliases can be created somehow in Drush 10 without having to patch the hell out of it or use disgusting workarounds such as env vars. As far as I can see the only hope using current code is to create 1 alias file per environment (local, dev, staging, prod) and then use something to modify environment variables before drush has a chance to load aliases (which is probably going to be a pain in itself) and then use the resulting environment variables in the yaml files to do the replacement which is an utterly disgusting hack. This would result in an alias like this: drush @dev.clientname status rather than @clientname.dev which makes more logical sense to me. dev.clientname just seems backwards. And it still requires 4 files as opposed to previous drush alias system which only required 1 file. That's a 400% increase in the amount of files necessary to do the same task. |
|
Feature is not planned. |
|
Note that wildcard aliases might provide some assistance in this matter, as they allow you to define one entry for each different environment of the same site. Removing dynamic aliases in Drush 9 gave a pretty big performance improvement to the bootstrapping of every command. We're not likely to bring them back. |
|
@greg-1-anderson Did anyone consider using modular design to support this feature set? For example, for those of us that want dynamic aliases, a simple config option can be added called "support dynamic aliases". If the option is checked, then the dynamic alias code blocks will then run. For those that dont want it, those code blocks and all the logic within them that cause any performance issues are completely ignored, thus eliminating the "performance" issue. I would not be opposed to having it disabled by default since those of us looking for it would likely be far fewer than those that could care less. This type of software design is pretty common place in most modern apps. Performance shouldnt really be a reasoning to cut an app's feature set short when designed properly. If performance is the reasoning, then the software design is the problem, not the feature itself. I've learned over the years if I find myself saying, it's because of performa..... that the problem is the software design, not the feature and improving the software design is always the right answer, not cutting out features. Currently I'm having to reverse how aliases work. I have to use 1 alias per environment, of which I have 4 (local, staging, dev, prod). Then a wildcard for the client name, IE: drush @dev.clientname status instead of drush @clientname.dev status. I then use a SUPER hackish hook to manipulate the OS Environment variables before the alias code runs and inject them into the aliases via the yaml files and ${env.VarName}. It works, but I'm not satisfied with it as it's logically backwards, requires extra files that really arent necessary, and has a very disgusting hack using env variables to do the replacements. |
|
Drush 8 (and earlier) tried to do everything. This became unmaintainable and unsupportable. Now we prefer to rely on external commands to provide functions that used to be core, e.g. gnu parallel instead of the parallel execution code in backend invoke. Folks who are on Pantheon can run I am sure that you will understand that your impassioned argument and disdain for your chosen solution does not give OSS maintainers more time to support more features. Perhaps you could consider a wrapper command as an alternative solution. |
|
Our provider is Acquia, we are their 3rd largest client for site factory.
They do not have a terminus equivalent. They do have acli, but its nothing
like terminus in that its mostly only a wrapper for their own API and a
little bit of cloudflares api, its not a wrapper for 3rd party console apps
such as drush. In speaking with the devs their argument is that its the
3rd part apps issue (in this case drush). So what we are left with is both
sides pointing at the other with us left in the middle holding the bag.
In my own opinion if the argument is that other 3rd party apps provide
such a feature yet there is none, then such an excuse/argument can't really
be made or defended. However this seems to have changed from your previous
argument that it was a performance argument.
Are you saying that terminus would work on acquia or any other host? Or
are you saying there is already a wrapper that does this. If so, whats
its name/git repo? I have already created a wrapper which I describe but
its completely disgusting because of how drush is developed currently. My
hope and goal is to provide arguments that this specific feature should NOT
need a wrapper of any kind in that it can and should be implemented in such
a way that doesn't affect performance, scalability or maintainability. If
I had the time I could provide PRs to do this but it sounds to me like it
would be a waste of time anyway as I am feeling like there's no interest in
improving the current state of drush as far as aliases are concerned.
And again, that was if I had the time which isn't the situation. We are
only now discovering this problem because we are transitioning from D7 to
D9 for a 1500+ site platform and this alias issue is a very massive problem
for us that came completely out of left field unexpectedly. Its a major
regression that we couldn't possibly find time to fix because of other
migration tasks. We are only a small team of 4 which lots of tasks ahead
of us for the next 2yrs.
Anyway thanks for the debate/discussion. Hopefully it changes some minds
in our favor. We would certainly be greatful.
…On Sun, Sep 11, 2022, 10:26 AM Greg Anderson ***@***.***> wrote:
Drush 8 (and earlier) tried to do everything. This became unmaintainable
and unsupportable. Now we prefer to rely on external commands to provide
functions that used to be core, e.g. gnu parallel
<https://www.gnu.org/software/parallel/> instead of the parallel
execution code in backend invoke. Folks who are on Pantheon can run terminus
drush SITE.ENV -- <drush options>, and Terminus will pass the appropriate
options to Drush to bootstrap the requested Drupal site.
I am sure that you will understand that your impassioned argument and
disdain for your chosen solution does not give OSS maintainers more time to
support more features. Perhaps you could consider a wrapper command as an
alternative solution.
—
Reply to this email directly, view it on GitHub
<#5225 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB4GRRRQXD7YU3NZM6JQYPDV5XTXXANCNFSM6AAAAAAQHIWMYM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Describe the bug
In Drush 8 and D7, it was very possible to create dynamic aliases. However with the change from php files to yaml files in Drush 9/10, it's no longer possible to do this as far as I can see. Here is an example from Acquia
drush8 @clientname.dev status <-- This was possible with D7+Drush 8 due to aliases being PHP files
drush8 @clientname.test status
drush8 @clientname.prod status
drush8 @clientname.local status
The above is what our aliases looked like in D7 + Drush 8. "clientname"'s alias data is determined via PHP code (based on whatever is provided for 'clientname' and the 'env' which can be one of 4 values) rather than listing 1500 aliases in a MASSIVE file or thousands of single files per client name. This also made accessing all the different envs and 1000s of sites from 1 location super easy without having to know every single client's domain name, stack ID (of which we have 100s), etc etc.
Now with Drush10 we have to have a massive yaml file or thousands of yaml files just for the aliases. Thats a maint and administrative nightmare as well has losing the ability to use small and concise drush commands. Consider the below aliases. They are massive and a pain to type. All of the data comes from an alias yaml file (provided by acquia).
drush10 @OurAccountNameHere.01dev --uri=http://ClientNameHere1.dev-ApplicationNameHere.acsitefactory.com status
drush10 @OurAccountNameHere.01test --uri=http://ClientNameHere1.test-ApplicationNameHere.acsitefactory.com status
drush10 @OurAccountNameHere.01live --uri=https://clientsDomain.com status
drush10 @..... there isnt even a local alias possible to compare to the above [email protected] status
I'll take the drush8 versions of these aliases every single day and twice on Sundays. How can we hook into Drush and create aliases dynamically using PHP? Is that even possible?
The text was updated successfully, but these errors were encountered: