Simplify the Demo/Example Vagrant situation

[RothAndrew]

What/Why

• We should not have arbitrary "vagrant entrypoints" that do similar things (root and examples)
  • It's confusing
  • We should have meaningful and well defined boundaries (local dev vs demos, different kinds of demos) but there should be a unified method of getting into those environments
• We should not specify other OSes if we aren't investing in making sure they are supported. Let's slim down to just Ubuntu for now, then add new OSes one at a time as we want to support them
  • Existence implies support, which isn't true right now for several of the OSes in the root Vagrantfile
• Since existence implies support, we should make sure all OSes that are specified as available options work with the examples and demos without additional manual configuration or documentation
• When doing demos/examples we want to be as DRY as we can. If different examples want different vagrant configurations we should utilize a "master" vagrantfile and make small overrides vs having fully separate vagrantfiles for each example
• We want to be able to run multiple examples at a time during a demo.
• We should still be able to sync files in mounted folders back and forth for local development

Co-authored with @btlghrants

[jeff-mccoy]

The multi os statement is incorrect. I regularly test the other OS’s and our prime customer isn’t using ubuntu, it’s just handy for dev. We should just add some e2e to cover other OS’s. In fact the e2e runs on amazon linux 2 right now.

I have no problem consolidating vagrant files if we need to but am opposed to vagrant for dev. It’s needless complexity to save installing golang. Debug would be harder and it would slow performance.

[RothAndrew]

Copy on the OSes. Will update.

[RothAndrew]

@btlghrants thoughts on the other comment about vagrant for dev? I know that's how you really like to operate, and I'm definitely in agreement that it would be pretty valuable for getting new devs spun up quickly. If we said "here's a way you can use Vagrant to do dev of this thing if you want to, but nobody's requiring any particular method" would that make everyone happy?

[btlghrants]

"here's a way you can use Vagrant to do dev of this thing if you want to, but nobody's requiring any particular method"

I think this would be viable / helpful.

Seems like its a matter of what we're willing to support really, so if we don't want to take that on as part of this project then so be it. As you said, though, it's how I plan to operate personally (because I like the isolation) but we don't have to "officially" adopt it if I'm the only one... but it'd be a shame to "waste" the code I'm going to write to make it possible for myself, wouldn't it?

I do happen to think it's very helpful to have around for new devs / product evaluators, though. I am not much a fan of requiring people to install just-the-right-version of a programming language runtime when they're, 1) just getting started with a language, or 2) just want to experiment a bit to see if they like a project. Personally, I see making a smoother "on-ramp" as being more-than-worth whatever performance hit we'd take.

[jeff-mccoy]

Yeah I'm going to 500% disagree with this. The only way what your stating would be viable is if you actually did your entire dev inside of the VM, i.e. your IDE / tooling as well because golang needs to be installed with the language server to do dev anyway. The only dependency I'm tracking you must have to dev is golang, which your IDE would need to do anything anyway. As far as all your dev inside a VM, tbh, I've never met anyone besides my friend @btlghrants that actually does this. I say this as someone that has 0 lines of code on either system I work on, it's all through remote systems.

[btlghrants]

So, if we left the development environment out then, we're saying that Vagrantfiles in Zarf:

1. intended for disposable demo environments (if we even want to keep that?), and
2. should/should not support other hypervisors?

[jeff-mccoy]

It's a tough call. For demo-like things it's highly valuable, and good for some dev/testing in isolation. The testing will become more fluid with the native K8s apply work as you will be able to test against any cluster for everything but zarf init. As far as multiple hybervisors, I think we'd just need data to explain why. It's more to support of course, but also I think we'd need to verify the same boxes/version are available and are consistent between the hypervisors. In particular, some dev things rely on VBox folder sync to function

[RothAndrew]

Keep in mind this issue is just for simplification of the Demo/Example vagrant stuff. The dev environment stuff is #84 and the hypervisor stuff is #86.

I'll modify the bullet incorrectly stating that Ubuntu is the only supported OS, then I propose we work this issue separately from #84 and #86 while we work through any differences there.

[jeff-mccoy]

Yeah sorry, issue-jacking, saw multiple come in at the same time on my phone

[RothAndrew]

Updated original description per discussion re OS support

[RothAndrew]

I think #237 will significantly change how this is able to be accomplished, likely by being able to eliminate Vagrant entirely other than specific testing scenarios that involve distros like K3s. Moving back to Planned for now until after #237 is merged

[jeff-mccoy]

Yeah I think there will always be a need for vagrant or similar for testing, but my hope is that all early evaluation/demo/dev stuff can just use the local cluster of your choice.

[jeff-mccoy]

closing vagrant issues as we move towards more non-vm testing/examples.