Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Decommissioning Otto

hashicorp.com

Post reply on HN
Print view View original

71–80 of 102 posts

Re: Decommissioning Otto

#71

Post by superswordfish »

Mizza wrote: post #56
mitchellh wrote: post #25

Earlier 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…

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.

Re: Decommissioning Otto

#72

Post by ivarrian »

mitchellh wrote: post #25
Mizza wrote: post #8

Does 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…

Thanks Mitchell. We have used Vagrant in the past, Packer currently and are considering Consul in the near future.

Re: Decommissioning Otto

#73

Post by seanp2k2 »

eropple wrote: post #65
Mizza wrote: post #8

Does 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…

Speaking for myself, I've put enough tooling around Packer to make it tolerable in my build pipeline and I haven't found a better tool that does what it does (suggestions welcome!). I would be using Vault, except it's just on the far edge of usable for me (particularly around the aws-ec2 provider) and I am repelled sufficiently by Go that I'm not driven to hack it to suit my needs until I exhaust my other alternative…

Ever try https://github.com/Netflix/aminator/blob/master/README.rst ? Should work with Ubuntu as well.

Re: Decommissioning Otto

#75

Post by jacques_chester »

apparentlymart wrote: post #42
apparentlymart wrote: post #39

Earlier quoted context omitted.

At work we use Packer, Terraform and Consul across all of our apps, and little smatterings of other stuff in some places. A little on each: - Packer: Not my favorite, honestly. I can't argue that it's doing the job, but it feels inflexible and hard to integrate into a coherent workflow. It seems that Hashicorp Atlas can smooth this over in principle; we don't use it, because it didn't seem to fit with our use of Terr…

Realized I missed a key point on Terraform: I advise anyone using Terraform in production to wrap it up in some sort of automation. Hashicorp would of course like you to use Atlas :D but you can get a long way with CI/automation tools like Jenkins, Rundeck, ... We have a wrapper script which: - configures the remote state in a predictable way (setting up remote state properly is one of the more fiddly parts of Terraf…

I'd rather use BOSH, which has an explicit compare-and-repair model.

On the other hand, Terraform is much easier to get started with and much less opinionated.

Disclosure: I work for Pivotal, we donate the majority of engineering on BOSH.

Re: Decommissioning Otto

#76

Post by jacques_chester »

adamb wrote: post #45

Kudos to HashiCorp for realizing that the complexity of the project was getting away from them and for having the guts to pull the plug in such a public way.

Hear hear.

I work for Pivotal on the fringes of Cloud Foundry. Between us and other Cloud Foundry Foundation members there are around 200 full time engineers working on it.

Featuresome, robust, industrial-grade cloud platforms are hard.

Re: Decommissioning Otto

#77

Post by jacques_chester »

lstamour wrote: post #43
newsat13 wrote: post #32

Earlier quoted context omitted.

Thanks for your comment/insight. I understand what a PaaS is but what does the 'masterless' qualifier mean?

Well, in Heroku proper, you feed its git repos an app, it figures out what type of app it is, and applies the right build pack and hosting environment for it. Keeping build packs up to date, keeping all the scripts running, and making sure an app has associated dependencies, etc--I imagine that's the difference between an independent setup you can self-host quickly and easily and one that's very dependent on an ecosy…

> Keeping build packs up to date, keeping all the scripts running, and making sure an app has associated dependencies, etc--I imagine that's the difference between an independent setup you can self-host quickly and easily and one that's very dependent on an ecosystem of Heroku maintainers, tooling and existing server infrastructure...

I work for Pivotal on the Cloud Foundry buildpacks team. 4 of our buildpacks (Ruby, Python, Go, NodeJS) are downstream forks of Heroku's.

We merge from upstream approximately weekly, but the pace has definitely dropped.

We build all the runtime binaries we ship with our buildpacks. We also build the rootfs it all runs on. Some of these pipelines are now fully automated. For example, when a NodeJS tag lands, our pipeline will build the binary, add it to a buildpack and put it through our battery of test suites. Our product manager can make a release with a few keystrokes and a button press.

The difficulty of engineering really comes down to the nature of the ecosystem you're turning into a buildpack. We did an article on writing buildpacks[0], taking Rust as our example. It was a doddle, because of Cargo. Meanwhile our PHP buildpack performs incredible gymnastics to make a 12-factor cloud platform look like a shared host circa 1999.

[0] http://engineering.pivotal.io/post/creating-a-custom-buildpa...

Re: Decommissioning Otto

#78

Post by Terretta »

mitchellh wrote: post #25
Mizza wrote: post #8

Does 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 only don't mention specific names because I don't have explicit permission, but you'll just have to trust I don't intend to lie here.

It's true, he doesn't have permission.

But at least one company in fintech is willing to admit appreciation of Hashicorp tooling.

Anyone curious come chat with Joel in Napa in a couple weeks.

https://www.hashiconf.com/talks/managing-vault-in-a-federate...

And if you're into distributed systems, talk to us seriously:

"From a values perspective, we're trying to understand the way the world works — that's what our business is — and so we're really interested in people that have a sort of deep curiosity, people that have the patience to understand deep and complex systems," Kreiter said. "Now, whether those are biological systems, or economic systems, or political systems, it doesn't really matter. Somebody who has an interest in and an ability to understand that deeply is interesting to us."

And that's why we like Mitchell.

Re: Decommissioning Otto

#79

Post by DannoHung »

mitchellh wrote: post #25
Mizza wrote: post #8

Does 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…

Consul's documentation needs a couple passes. Great product, but I have to do experiments every time to figure out exactly how to use it correctly.

Re: Decommissioning Otto

#80

Post by apeace »

Question 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 was no way to configure anything in Otto.

FWIW, we ended up using Convox[1] and loved it.

[0] https://webcache.googleusercontent.com/search?q=cache:9QfCNX...

[1] https://convox.com/

Post reply on HN