It's hidden right now but if you'd like to search for boxes use https://atlas.hashicorp.com/boxes/search
Atlas by Hashicorp
51–57 of 57 posts
Re: Atlas by Hashicorp
#52Atlas as a project name seems very popular these days (Facebook Atlas API, o'Reilly Atlas platform, etc).
Re: Atlas by Hashicorp
#53Earlier quoted context omitted.
They really need to rewrite it in go. Ruby has been a disaster for this particular project. Don't even get me started on the Nokogiri issues. Everything they've written in go has functioned better IMHO.
Are you using their all in one package or do you install from rubygems? The former should give you no problems. If you are doing the latter... well... you shouldn't.
It was much more stable for me when I was installing it through rubygems and managing our middleware's dependencies with bundler directly. We've switched to the embedded ruby and it's a struggle but we deal with it since it's probably MUCH less work to support now that it's standardized across all vagrant installs.
Re: Atlas by Hashicorp
#54Vagrant has so many bugs in development (network issues, file syncing issues) that I switched to manually building my own VMs to save time . I would never use it or any tech built on top of it in development, let alone production.
For all of the issues I have been facing, most of them were actually triggered by virtualbox. Those issues can be quite annoying but can be solved quite easily if you don't have other VB VMs. Usually, resetting the vbox subnets (I had major issues with those) does the job. On the other side, Vagrant has got some minor issues but let's face it: doing what Vagrant does manually is huge and I prefer composing with those…
I would consider using it again if I really had to for more than just quickly testing a VM, but to be honest, after wasting days with problems (which the vagrant team is aware of) and then having it fail again and again, I'm not very inclined to. I can see why vagrant encourages a workflow where one destroys the VMs regularly as that would likely avoid a ton of issues at the expense of time wasted.
My VMWare machines have been problem free for many months (as well as my manual VBox ones for years) and the only way I'd even consider using it daily again by choice again is to try out their VMWare support ... which is unfortunately paid so I doubt that will happen. On the other hand, using vagrant did point out some severe weaknesses in VirtualBox itself, especially the file syncing support, and made me realize VMWare is worth the money for that alone. I still use vagrant once in awhile if I only need to test a project out for an hour or two.
As far as deployment, I could see the potential time savings when dealing with multiple VMs but those would only be realized if they're not offset by a longer time spent dealing with bugs. Still, I may give it another shot in that context when the need arises next.
Re: Atlas by Hashicorp
#55I wonder if there will still be a free tier, a place to drop decent base nodes or images demoing open source and so on.
There will, across all the features.
Re: Atlas by Hashicorp
#56What is a node in terms of pricing? Kinda/sorta feels like a stranglehold to have this remaining piece of the Hashicorp puzzle be free and then to start charging for it. :(
Unlike our open source projects, Atlas is not shipping any foundational new functionality; it is unifying our open source projects into a single solution with a UI, security (ACLs, audits), workflow, etc. This differentiates it in being a commercial product and we feel this is a really clean way to do it. We've avoided any open core awkwardness and our business model is clear.
To put it another way, we use an analogy internally here at HashiCorp: our open source are our "nuts and bolts" that you can grab off the shelf and be very successful with in building robust systems, but Atlas is the complete car or house (built up from these nuts and bolts) that you can purchase.
Re: Atlas by Hashicorp
#57Earlier quoted context omitted.
Are you using their all in one package or do you install from rubygems? The former should give you no problems. If you are doing the latter... well... you shouldn't.
Even if you use their all-in-one package, you can still have dependency problems installing vagrant plugins. https://github.com/mitchellh/vagrant/issues/3769 https://github.com/mitchellh/vagrant/issues/4278
Yeah but those are plugins, the Vagrant author can't do anything about what third parties do. You mentioned Go as a better language, but Go does not solve that problem it does not support loadable modules at all. If Vagrant were written in Go it wouldn't have supported plugins at all.