Closed dixhuit closed 9 years ago
dixhuit
commented
9 years ago The galaxy branch now also uses a self published Galaxy role for ImageMagick to demonstrate how we'd refactor existing features of Vlad to use Galaxy roles (albeit a very simple demonstration - it's hardly the PHP role).
dixhuit
commented
9 years ago Sendmail has now been abstracted out into a Galaxy role.
PEAR & Phing have been removed from Vlad: Phing did nothing within Vlad, PEAR was just a dependency of Phing. This should speed up provisioning a bit.
Xdebug has been moved out of the PHP role and into its own role (still within Vlad for now).
dixhuit
commented
9 years ago Started trying to abstract drush from the drupal role but didn't end up moving anything to or installing anything from Ansible Galaxy. The resultant work is a sizeable overhaul of Drush in Vlad though and all commits went into the galaxy branch (with one bugfix being included in dev too).
Time to start thinking about strategy for merging this into dev and next steps.
dixhuit
commented
9 years ago This feels like it's stalled a bit, can we pick this back up? The galaxy branch is ready to be merged into dev and for docs to then be updated - it just needs some feedback first.
philipnorton42
commented
9 years ago Yeah, been a bit of a delay hasn't there? I can't believe that it's the 13th August already! I'll try and run a few tests this weekend. I think this is the right way to go though!
wizonesolutions
commented
9 years ago Have you figured out the --force issue? Depending on how you're running it (I'd assume with vagrant-triggers or local provisioning?), if you have access to Ruby you could parse for the Galaxy metadata and check that the version matches what you expect. And perhaps generate a galaxy.yml file to pass to ansible-galaxy install based on what's not already installed or isn't installed with the correct version?
dixhuit
commented
9 years ago Hadn't thought of that approach, I'll add that to the pile, thanks. My thoughts on this so far:
git task. Et voilà, idempotent Galaxy roles. It'll probably be a bit slower than it currently is but with each repo's depth set to 1 it shouldn't be too bad.philipnorton42
commented
9 years ago I'm just running some tests and realised that some of the stuff that's recently been fixed in dev is still broken in galaxy. So I've merged those changes in. Everything seems a bit healthier now :)
dixhuit
commented
9 years ago Aah, jolly good :) That's another reason I'm keen to get back on this - maintaining both branches is a bit of a pain.
dixhuit
commented
9 years ago If we have to roll something ourselves one idea I had was to write an additional playbook to run up front that can just read in the data from requirements.yml and use it with Ansible's very own git task. Et voilà, idempotent Galaxy roles. It'll probably be a bit slower than it currently is but with each repo's depth set to 1 it shouldn't be too bad.
The irony here is that this would actually make quite a handy Galaxy role. DOH!
wizonesolutions
commented
9 years ago Ansible Galaxy is actually getting love!? You mean things like Google searchability and something better than this crappy Angular app they've got going? Haha. Can't wait.
On Thu, Aug 13, 2015 at 2:44 PM, Dan Bohea notifications@github.com wrote:
If we have to roll something ourselves one idea I had was to write an additional playbook to run up front that can just read in the data from requirements.yml and use it with Ansible's very own git task. Et voilà, idempotent Galaxy roles. It'll probably be a bit slower than it currently is but with each repo's depth set to 1 it shouldn't be too bad.
The irony here is that this would actually make quite a handy Galaxy role. DOH!
— Reply to this email directly or view it on GitHub https://github.com/hashbangcode/vlad/issues/262#issuecomment-130656771.
philipnorton42
commented
9 years ago So I've been testing this over the past few days and everything appears to be in order. The --force issue doesn't seem to slow things down much, at least not with a few KB of data that currently comprises the galaxy based roles.
I think the next step is to start ensuring that the galaxy repos get some sort of version number so we can start using that instead of master. Then we can start moving some of the other roles into galaxy roles. I think munin is a prime candidate for this.
I actually like the Drush role that this branch has more than the current master branch as it allows for Drush 8 (and therefore Drupal 8) support. I've been using the box to test Drupal 8 installs and everything is working correctly. Top work Dan!
dixhuit
commented
9 years ago I think the next step is to start ensuring that the galaxy repos get some sort of version number so we can start using that instead of master.
Agreed. Just need to agree on how these role repos should be versioned before either of us can get started tagging. For simplicity and to maintain momentum, shall we just say that each of these Galaxy roles are now at v1.0?
Once these roles are tagged and the galaxy branch is updated to point at the specific versions, can we then consider merging into dev? I'm super conscious of the work involved in maintaining 2 development branches (3 if you count the npm branch too), plus I think we should get one more master release out the door before we start with the breaking changes that are around the corner, plus plus there are new features that are currently stuck in the galaxy branch that told me that they really want to be in the master branch (hosting cli tools, better drush support). Thoughts?
Then we can start moving some of the other roles into galaxy roles.
Absolutely. We'll need a plan here in order to minimise the number of releases that contain breaking changes. I think fewer releases with more breaking changes is always gonna be preferable to more releases with less (but still some) breaking changes - if that makes sense.
I actually like the Drush role that this branch has more than the current master branch as it allows for Drush 8 (and therefore Drupal 8) support. I've been using the box to test Drupal 8 installs and everything is working correctly. Top work Dan!
I can't take full credit here. I was toying with the idea of using Jeff Geerling's Drush role via Galaxy (that's what Galaxy's all about right?) but ended up having to amend it enough for it to make more sense to just borrow the best bits (it's only 4 tasks). Anyways, thanks Jeff! :) I did credit Jeff and list the amends I'd made.
dixhuit
commented
9 years ago Agreed. Just need to agree on how these role repos should be versioned before either of us can get started tagging. For simplicity and to maintain momentum, shall we just say that each of these Galaxy roles are now at v1.0?
I have an unexpected gap in my schedule this afternoon so I'm gonna get this sorted. I'll tag each repo with a beta version for now while we're still figuring this stuff out.
dixhuit
commented
9 years ago dixhuit
commented
9 years ago Apparently Ansible Galaxy updates tomorrow:
https://groups.google.com/forum/#!topic/ansible-announce/A17aWirkugA
I don't see any mention of changes to ansible-galaxy install but at least there's a public issue tracker for Galaxy now.
dixhuit
commented
9 years ago Have raised an issue regarding ansible-galaxy install:
dixhuit
commented
9 years ago @philipnorton42 So master & dev branches are pretty much in the same state now that v1.1.5 is out the door. Can we see about merging the galaxy branch into dev now? I'll happily do it - I'm just looking for agreement.
philipnorton42
commented
9 years ago Yeah, sounds like a good idea. Every time I've needed to set up a new machine I've used the galaxy branch just so that I can test things. Although I had a few bugs to start with everything seems stable now. I like the new approach to Drush integration as well :)
dixhuit
commented
9 years ago OK, cool. Shall I merge it or are you going to?
philipnorton42
commented
9 years ago All done :) Just one merge conflict on the .gitignore file as well.
dixhuit
commented
9 years ago Nice one. I'll close this issue then and we can track each role in its own issue.
A long time ago Vlad used to be a normal, living guy that very nearly changed his name to Dennis. Before this time and certainly before his transformation to undead superstar, the official but still half baked solution to sharing Ansible roles, Ansible Galaxy, didn't even exist.
Even in its current state, Galaxy is something that we should probably be making more use of in a project like Vlad. The full discussion regarding why is beyond the scope of this issue IMHO. @philipnorton42 & I have already discussed this at length and are generally in agreement. This issue is here to share the intention and track progress.
We have a new "galaxy" branch based on the current dev branch.
Right now the galaxy branch is a prototype for how external roles can be used within the project. To start with I've only added roles that cover functionality that was slated for inclusion in Vlad soon anyway. IMO, the sooner this can be folded into dev the better - this will pave the way to rolling the concept out on a larger scale.
Points of note:
vagrant up.ansible-galaxy installis really half baked, running it more than once will cause everything to fail (WTF? This is Ansible!) Currently, I'm using the--forceoption - this ensures that any existing downloaded external roles are overwritten every time. Despite this being utterly inefficient, while we're only using 2 very minimal external roles this is very fast (even on my sh*tty broadband). We may want to swap this for something more advanced when our requirements have grown (let's keep reviewing this aspect as we go).pantheon_cli_install>> becomes >>vlad_install_pantheon_cli. Obviously this will be a breaking change but namespacing is going to become more of a concern as we begin to fold in more external code.That's it for now. I'll await feedback and hopefully we can see this merged into dev real soon :)