Anybody using vault ?
Yes.
Decommissioning Otto
81–90 of 102 posts
Re: Decommissioning Otto
#82Does anybody _actually_ use the HashiCorp stack, besides Vagrant, for serious work? I tried and honestly found their products sorely, sorely lacking. Very shiny documentation, very incomplete, un-battled-tested tools, no examples given, little response from their devs other than the PR team. For a small example, I _still_ get +1 notifications on this critical issue nearly every day: https://github.com/mitchellh/packe…
Ouch! My feelings are hurt. :( Everyone has a different experience and perception I suppose. I agree we have a long way to go, but I disagree that our tooling is "very incomplete" OR "un-battle-tested". Ignoring Vagrant as you did, Consul is used at multi-thousand node (per datacenter) scale by dozens of companies and a couple specific companies are using it at an even larger scale. And that's ignoring the thousands…
We have been using Vagrant, Terraform, Packer, Vault etc from some time. While there are some issues(that's true for many tools), I find these tools helpful. Hack, I used terraform to provision my QA cluster right now :)
Thanks for these tools.
Re: Decommissioning Otto
#83Earlier quoted context omitted.
Ouch! My feelings are hurt. :( Everyone has a different experience and perception I suppose. I agree we have a long way to go, but I disagree that our tooling is "very incomplete" OR "un-battle-tested". Ignoring Vagrant as you did, Consul is used at multi-thousand node (per datacenter) scale by dozens of companies and a couple specific companies are using it at an even larger scale. And that's ignoring the thousands…
We have been using Vagrant, Terraform, Packer, Vault etc from some time. While there are some issues(that's true for many tools), I find these tools helpful. Hack, I used terraform to provision my QA cluster right now :) Thanks for these tools.
Also how can I forget Consul.
Re: Decommissioning Otto
#84Earlier quoted context omitted.
Heck I found the same to be true of vagrant. Big promises, short on delivery. While mostly usable, it's definitely not as seamless across various guests, providers, and provisioners as their docs might have you think. Stray off the beaten path even the tiniest bit and expect to spend hours looking at github issues for workarounds (submitted by other users not the dev team). My experience. Windows guests: buggy FreeBS…
Never used Windows or FreeBSD guests, but what's wrong with Ansible provisioning?
Debugging and extra vars are clunky, to pick a few.
Re: Decommissioning Otto
#85Earlier quoted context omitted.
Hey Mitchell, sorry for sneak dissing. I wasn't trying to hate on your efforts, which are greatly appreciated, I was more just trying to poll the community if people actually use the stack in production. Will follow-up in email.
It doesn't take an expert sleuth to find things like https://www.hashicorp.com/blog/tags/case-study.html , so your "does anybody _actually_ use the HashiCorp stack" comes across pretty clearly as sniping.
Vendor-published case studies are pretty worthless IMO. I've seen plenty where the vendor was absolutely despised by anybody working for the client who had to deal with them.
Re: Decommissioning Otto
#86Does anybody _actually_ use the HashiCorp stack, besides Vagrant, for serious work? I tried and honestly found their products sorely, sorely lacking. Very shiny documentation, very incomplete, un-battled-tested tools, no examples given, little response from their devs other than the PR team. For a small example, I _still_ get +1 notifications on this critical issue nearly every day: https://github.com/mitchellh/packe…
If you use vagrant heavily, you are almost forced to use packer at one point. There are certain things you simply have to put into a base image and packer is the best way to do that. However, I will say the support for vagrant seems fairly responsive, while packer seems basically unsupported.
Re: Decommissioning Otto
#87Does anybody _actually_ use the HashiCorp stack, besides Vagrant, for serious work? I tried and honestly found their products sorely, sorely lacking. Very shiny documentation, very incomplete, un-battled-tested tools, no examples given, little response from their devs other than the PR team. For a small example, I _still_ get +1 notifications on this critical issue nearly every day: https://github.com/mitchellh/packe…
Used Vagrant a few years ago, but almost completely moved to Docker, it doesn't make sense to have a massive VM image anymore.
Use Packer for all AMI building, probably one of the easiest tools to get started with.
Use Consul for service discovery with consul-template and envconsul, all work nicely together.
Terraform. I've been using for the past few months, but it has its problems. Modules use can be very tricky to manage, with no real guidelines on how to use them or TF itself. The isolation can be more complex than say, Cloudformation, which has its faults too. With CFN you have a concept of a infra stack, which will share common resources, with supplementary stacks providing additional resources. Unless you are happy to have a load of main.tf files in sub directories, which seems to be the pattern, you end up with a giant load of TF as one "stack". The benefit is never hard coding things, which you are probably going to do with CFN, plus you have a much better scope of changing resources in TF, but if you don't need that, TF can offer little over CFN with a language to generate it, like CFNDSL or troposphere.
We also regularly break though our AWS API limits for TF because it touches so many things, if you have TF in a single git repo with multiple hooks, your TF can take a long time to actually plan. Recently, I did a plan on 0.7 to see what the impact was for upgrading, without realising that it would overwrite the state file to comply with 0.7, making it impossible to switch back to 0.6. I did roll back to a previous version of the state, but even that caused some issues that I had to manually resolve.
Finally, Atlas. I would say that it is far from complete. There are a lot of things that UI is missing. The API for atlas is also non existent, so you have to use the UI constantly unless you want to auto deploy, which is probably fine for a dev environment, but not production. If you have a plan apply that needs manual intervention, it will sit there while commits pile up above it, so you either let apply and let atlas hit your account with massive amounts of API calls, or you cancel all the plans currently being blocked. It obviously works very different with say S3 and using TF from a CI, but i'm not sure how much focus there is on Atlas vs other products. Atlas also doesn't let you set up things like organisational access tokens, for Atlas itself and for Github. Right now, if we removed someone from our Github or Atlas org, stuff will simply break.
Re: Decommissioning Otto
#88Question for mitchellh or others at Hashicorp: Will "zero configuration" be a feature/goal in your next attempts at this abstraction? Was this one of the things that made building Otto so challenging? A few months ago when I tried Otto I found the "zero configuration" idea off-putting. In fact, I couldn't even get a basic Python app to work because there was no way for me to install libmysqlclient[0]. There really wa…
I'm still a big fan of minimal configuration through sane defaults, but not advocating "zero configuration" in that sense that you have no power to change those defaults.
One area I think we've done really well with this in the past year is the "-dev" flag on Vault, Consul, Nomad. It is a zero-configuration way to get a fully functional dev server up and running in one command though you can still specify a config if you wanted. For non-dev, I just don't want to set dozens of options just to get going, so we'll continue to strive for defaults that work where we can.
All that being said, they are defaults, so you can always change them.
Re: Decommissioning Otto
#89Does anybody _actually_ use the HashiCorp stack, besides Vagrant, for serious work? I tried and honestly found their products sorely, sorely lacking. Very shiny documentation, very incomplete, un-battled-tested tools, no examples given, little response from their devs other than the PR team. For a small example, I _still_ get +1 notifications on this critical issue nearly every day: https://github.com/mitchellh/packe…
Ouch! My feelings are hurt. :( Everyone has a different experience and perception I suppose. I agree we have a long way to go, but I disagree that our tooling is "very incomplete" OR "un-battle-tested". Ignoring Vagrant as you did, Consul is used at multi-thousand node (per datacenter) scale by dozens of companies and a couple specific companies are using it at an even larger scale. And that's ignoring the thousands…
I know the hashicorp stack fairly well as we run packer and terraform to provision our production environment and we've considered rolling out consul.
I'm so glad you're killing a product. My complaint has always been that hashicorp was doing so many different products it was unable to actually deliver any of them at high quality.
Packer is a reliable and trusty piece of tech for us, but terraform (which has so much potential) is also so rough around the edges we've wrapped it in a mess of our own tooling to make it somewhat usable.
I hope you can find a way to focus on one or two things and do them well.
Re: Decommissioning Otto
#90Earlier quoted context omitted.
Consul is probably one of the best pieces of software I've ever used and is the category leader for service discovery
I'd be interested in any data which backs this up. Things like ZooKeeper have been around a lot longer and are definitely also in widespread usage.
We've been using consul as well, it's just fantastic. Comparatively, zookeeper was a pain and didn't do all the things we wanted.