This looks very cool!
Please consider adding a user agent string with a link to the repo or some Google-able name to your curl call, it can help site operators get in touch with you if it starts to misbehave somehow.
133 karma · joined June 5, 2013
Please consider adding a user agent string with a link to the repo or some Google-able name to your curl call, it can help site operators get in touch with you if it starts to misbehave somehow.
> Me: No, no, I'm sorry. Yeah one more time. I was just saying if the opportunity cost of Apollo is currently $20 million a year. And that's a yearly, apparently ongoing cost to you folks. If you want to rip that band-aid off once. And have Apollo quiet down, you know, six months. Beautiful deal. Again this is mostly a joke, I'm just saying if the opportunity cost is that high, and if that is something that could make it easier on you guys, that could happen too. As is, it's quite difficult.
> Reddit: Yeah, yeah, yeah, I hear you. I think it's… I don't know what you mean by quiet down. I find that to be-
> Me: No, no, sorry. I didn't mean that to-
> Reddit: I'm going to very straightforward to you too, it sounds like a threat. And I'm just like "Oh interesting". Because one of the things we're trying to do is say "You have been using our API free of cost for many, many years and we have absolutely sanctioned - you have not broken any rules." And now we're changing our perspective for what we're telling you - and I know you disagree with it. That hey, we want to operate on a thing that is financially, you know, footing. And so hopefully you mean something completely different from what I said when you say like "go quietly", I just want to make sure.
> Me: How did you take that, sorry? Could you elaborate?
> Reddit: Oh, like, because you were like, "Hey, if you want this to go away".
> Me: I said "If you want Apollo to go quiet". Like in terms of- I would say it's quite loud in terms of its API usage.
> Reddit: Oh, go quiet as in that. Okay, got it. Got it. Sorry.
> Me: Like it's a very-
> Reddit: Yeah, that's a complete misinterpretation on my end.
> Me: Yeah. No, no, it's all good.
> Reddit: I apologize. I apologize immediately.
> Me: No, no, no, it's all good.
> Reddit: Because what we're hearing in some conversations is folks are, you know, like in other- making threats, and we're like "Hey, that's not a conversation that we want to have". So I immediately apologize.
> Me: Oh, no, no, it's all good. I'm sorry if it sounded like that.
Link to audio: http://christianselig.com/apollo-end/reddit-third-call-may-3...
I agree, there should be a way to have the primary app be an image that doesn’t get built/pushed.
If we had gone down the k8s on-prem rabbit-hole, I suspect we would have required more folks to manage those components and complexity.
This tool covers our use cases so far, and is easy to reason about. Ergonomically, it's very similar to Capistrano, which we're all familiar with.
Where did anyone say we don't use other tools? Chef + Terraform are wonderful and still in use for us.
> Could you share the comparison chart of tools that you considered? What thought process led you to believe that this is an unsolved problem and requires a new tool? Genuinely interested.
Your phrasing here and in your previous quoted reply leads me to believe you're not genuinely interested. Our environment is not your environment, our experiences are not your experiences. No, I can't share a chart of other tools that were considered, but off the top of my head, Capistrano, various CI integrations, Github Actions, etc.
We're a rails shop. We're going to look at tools in that area. We're not going to go dig into dagger or garden.io or something that causes us to have to conform our dev/deploy environment to a mental model that adds more friction for our developers.
> How should I judge it by than? Reading the code? Figuring out how to hold it right myself?
It's not that complicated of code, only about 2k, total, IIRC? I mean, you could read it. I'm baffled that you're choosing to compare a structural design flaw like the iPhone antennae issue to the fact that a configuration example in a new tool used an IP address. Go off, king.
If you have an image that can run multiple things, like a rails app that can run the app process for web traffic by default, but it can also run job workers with the right command, you can provide the cmd in the mrsk config. You can see this in the jobs role in the example: https://github.com/mrsked/mrsk#using-different-roles-for-ser....
Which is the primary reason why we did investigate k8s on-prem. We had already done the work to k8s-ify the apps, let's not throw that away. But running k8s on-prem is different than running your own k8s in the cloud is different than running on managed k8s in the cloud.
Providing all of the bits k8s needs to really work was going to really stretch our team, but we figured with the right support from a vendor, we could make it work. We worked up a spike of harvester + rancher + longhorn and had something that we could use as if it were a cloud. It was pretty slick.
Then we got the pricing on support for all of that, and decided to spend that half million elsewhere.
We own our hardware, we rent cabs and pay for power & network. We've got a pretty simple pxeboot setup to provision hardware with a bare OS that we can use with chef to provide the common bits needed.
It's not 'ultimately flexible in every way', but it's 'flexible enough to meet the needs of our workloads'.
If we do decide to tie it in, it will be using the GH Deployment API to inform the local tool on CI status or something.
mrsk does require a ruby install on your machine, tho.
1. Moving our stuff out of the cloud without going back to static hosts. 2. Giving new rails devs a tool where they can deploy their application easily, in a modern fashion.
Both of these are not so large or complex that you must use hostnames in configs instead of IP addresses. I will note, that most of our internal configs, do in fact, use hostnames rather than IP's. But judging a tool because an example used an IP address seems shortsighted.
There are plenty of things in mrsk to discuss without fixating on that.
Please read the article. It's presented there, and not even hidden away.
The decision was made to not horizontally scale out the dumpster operations to match expected queue uptake. ;)
The thought there was to reduce toner usage, but printing the same thing reduces issues due to wind flipping the sheets over. +1
In this case, we're a paying customer of the provider, not the product.
Here's a link where folks have 'rediscovered' how to make real wootz/damascus. It's the most academically rigorous attempt I'm aware of, and I'd call it a success: