Deprecate this project in favor of DrupalVM?

[cweagans]

http://www.drupalvm.com/ is really complete, and does everything Pubstack does and then some. There are even pre-packaged config options that make the box mimic Acquia Hosting: https://github.com/geerlingguy/drupal-vm/tree/master/examples/acquia

I've been using it locally for TVE development and it's been really painless.

Best of all, we don't have to find time to maintain DrupalVM, as it's already got a pretty large and active community around it. https://github.com/geerlingguy/drupal-vm for more info.

[scottrigby]

Yeah, we borrowed a lot from the individual Ansible sub projects that Jeff Geerling had written up to that point (he gave the talk that inspired us to do this in the first place a few DrupalCons ago), and now those same projects are inside drupal-vm.

When he moved to Acquia I thought we should partner with him on merging our work, because some of what we added were real improvements. I'm not sure the status of that now though… maybe drupal-vm has all of those improvements? My work on the branch for aws/centos support kind of stopped in it's tracks last year unfortunately… so i haven't checked in about that. Also @cweagans what about the test you made that fixed Windows support (provisioning within the vm ubuntu box itself)… is drupal-vm flexible enough to allow those kinds of improvements?

If the answer is yes (at least to most of the above question) then I'm all for it 😄

[cweagans]

@scottrigby It's definitely flexible enough to allow for the ansible_local provisioner. In fact, https://github.com/geerlingguy/drupal-vm/blob/master/Vagrantfile#L119-L125 -- it's broken in Vagrant 1.8.1, but as soon as the next release is tagged, he's planning to switch back. He already had some Windows users at one point.

I think the only thing that DrupalVM doesn't support that we'd want is New Relic, and that should be really straightforward to add if we want it.

[scottrigby]

@cweagans

• Re ansible_local/Windows support, that makes sense. Since pubstack doesn't have that now, that shouldn't impact our decision to deprecate in favor of drupal-vm.
• Re New Relic: I just added a PR New Relic support to drupal-vm (New Relic support, conditionally-installed geerlingguy/drupal-vm#587) I don't use NR in pubstack personally… if someone on our team who uses NR in pubstack can test this PR with drupal-vm that will get us one step closer.
• Another thing I just remembered pubstack has that drupal-vm doesn't: we added the ability for advanced users to extend the playbook with their own user.playbook.yml (85f867d). I just added a PR adding this to drupal-vm as well (Support an optional playbook override file (example use: adding custom roles) geerlingguy/drupal-vm#588), though I'm not sure if there's a better way to add custom roles. Any thoughts about that?

Anyway, once we know drupal-vm has parity with pubstack, I think I'd rather help contribute to drupal-vm than continuing this project. @ericduran I know you don't use pubstack anymore but do you have any thoughts? @conortm do you have an opinion about this?

[cweagans]

@scottrigby DrupalVM allows for extension via the Vagrantfile (https://github.com/geerlingguy/drupal-vm/blob/master/Vagrantfile#L160). You could very easily just toss your own provisioning logic in there and call it a day.

I don't think I ever used the custom playbook in pubstack, tbh, but I can see how it would be useful. I'd also suggest that the majority of what we'd use a custom playbook for is selectively enabling/disabling certain features (New Relic, mailcatcher, etc), but Drupal VMs config already allows for that. Is there something else that we might need to do with a custom playbook that Drupal VM doesn't already allow for?

[scottrigby]

@cweagans yeah, the custom playbook was handy for like, one project I lead at NBCU lol. But not really required. I agree using Vagrantfile.local could solve this, so I'm going to close that PR. I replied to your comments on the New Relic PR though 😄

[scottrigby]

@cweagans also closed that local playbook PR in favor of Vagrantfile.local like you suggested geerlingguy/drupal-vm#588 (comment). Since I would guess few (if any) people are using this feature in pubstack, I think this is sufficient feature parity. No there's nothing else I can think of that pubstack does that we can't do with drupal-vm using one of these methods (even now if someone wants to they can enable New Relic with a custom Vagrantfile.local). I'm sold. Let's wait for consensus though… maybe there are other things we're not thinking about.

[scottrigby]

Update: @conortm is fine with it, and @ericduran has only the concern that we don't leave people hanging who are currently using pubstack. @cweagans and I think an auto-migration script from pubstack 👉 drupal-vm would be an ideal way to simplify the move (although I think well written and simple instructions for migrating would be an MVP).

[cweagans]

I think well written and simple instructions for migrating would be an MVP

👍

[robcolburn]

Perhaps pubstack just becomes one long README.md?

[scottrigby]

One other missing ingredient in drupalvm is an equivalent patternlab role (in Ansible Galaxy) to have parity with the one in Pubstack. I literally never use this myself, so I overlooked it. If I have time, I may go ahead and create a galaxy role for that. Then we can include instructions in our epic README (As @robcolburn said) for this too.

[scottrigby]

Update: As it turns out, patternlab support does not really exist in pubstack at all. It must be set up manually. I didn't know this because I thought Conor or Eric or someone else must have added it into pubstack. But no.

So… Drupal VM has full parity with pubstack. There is no reason to maintain it now.

Now that I'm the only pubstack maintainer at NBCU, I'm going to officially deprecate it in favor of Drupal VM. I will keep the Slack #pubstack channel open as a forum to help anyone migrate their version of pubstack to Drupal VM (I have now done this for many people, on several brands who all use pubstack slightly differently).

Thanks everyone, pubstack has been a fun ride. On to bigger and better things!

[scottrigby]

• Add a deprecated GitHub topic (new GitHub feature)
• Change the repo name to include ⛔️ [DEPRECATED]
• Update README to reflect status, and link to Drupal VM
• Close issue 🍾

[cweagans]

wooooo!

[cweagans]

https://github.com/NBCUTechnology/pubstack-shell probably needs the same treatment, no?