MMmmcclellan·Oct 3, 2015
Note to self: don't describe strider (https://github.com/mpdehaan/strider) as Vagrant for humans.
In Schedule – Python job scheduling for humansmpdehaan
strider
HISTORICAL RECORD2015–2015
mpdehaan / strider · Not publicly available
strider
Discover this repository through its Hacker News conversations.
2Distinct people
4Mentions
0Explicit recommenders
What to know before exploring
What it is
A public description has not been verified.
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by week4 dated mentions
Observed mentions: 2015-08-18 11:55:52 UTC to 2015-10-03 16:17:06 UTC. Weeks start Monday, UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Aug 17 | 2015-08-17 00:00:00 UTC | 2015-08-24 00:00:00 UTC | 2 | 1 | 1 |
| Aug 24 | 2015-08-24 00:00:00 UTC | 2015-08-31 00:00:00 UTC | 0 | 0 | 0 |
| Aug 31 | 2015-08-31 00:00:00 UTC | 2015-09-07 00:00:00 UTC | 0 | 0 | 0 |
| Sep 7 | 2015-09-07 00:00:00 UTC | 2015-09-14 00:00:00 UTC | 0 | 0 | 0 |
| Sep 14 | 2015-09-14 00:00:00 UTC | 2015-09-21 00:00:00 UTC | 0 | 0 | 0 |
| Sep 21 | 2015-09-21 00:00:00 UTC | 2015-09-28 00:00:00 UTC | 0 | 0 | 0 |
| Sep 28 | 2015-09-28 00:00:00 UTC | 2015-10-05 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
4 sourcesI'm kind of glad to see this, as I wrote https://github.com/mpdehaan/strider for the reason that Packer and Vagrant used different config files.
This appears to address that.
OTOH, it says it's executing Vagrant and Packer under the covers, so I really need some of the Packer limitations I have (like https://github.com/mitchellh/packer/issues/409
) addressed more than I want glue on top.
Anyway, if people want to hack on Strider, pull requests are welcome.
I'm not using it actively (yet), but it's a very very tiny amount of code to supply both. All the work gets done by boto.
Back to otto - I am curious what otto means when it says it's going to start to talk to infrastructure and means that it's going ot be more of a workflow engine that can also invoke terraform or what.
The DSL changes appear to maybe be a step in that direction?
Wou
Read the rest
ld probably benefit from more than one liners on the homepage, to show what is really involved more quickly.
Show HN: Strider – test deployments and bake AMIs from Python
1 points · Open discussion(disclaimer: I wrote Ansible)
These are some pretty clean playbooks and probably the most coherent example of using the ec2 modules together I've ever seen.
Alternative approach for consideration -- currently, I am working for a company who has a very nice deployment setup that mostly just uses mostly just the Ansible ec2_tag and ec2_facts, and has an Immutable Systems (Packer) stack deployed by CloudFormation and Asgard APIs. In other words, the ansible cloud modules are not heavily utilized, but it's nice because in CF we have access to all the knobs and services. Asgard handles rolling updates across ELBs, where CF defines the infrastructure.
It's a pretty good setup! Ansible cloud modules are more or less serially executed, but don't know about each other. I do think it's important that Cloud Formation and other solutions understan
Read the rest
d the relationships between the resources.
For this reason, Terraform is super interesting conceptually, and it may be a good answer to some quirks in CF (one being it's a little hard to read/write!). Though I haven't had much direct experience to try it out, I look forward to having some time in the future.
Aside: Troposphere is an interesting project but doesn't have a lot of AWS service coverage yet - https://github.com/cloudtools/troposphere
Organizations attempting "multiple-cloud providers" have more challenges than ones attempting to just pick AWS (or another), that's for sure - as they are really different in the end, and I sort of have this question in the back of my mind whether cloud abstractions are really a good idea in the end, or you really really need to know the differences between Cloud X and Y (especially to expose all the constituent services accurately).
Anyway, yeah, I think building Packer images with Ansible and deploying with something like Terraform is where I would consider starting if I had a green field infrastructure.
Don't live-manage your AWS boxen if you can help it, as you miss most of the advantages of being able to deploy AMIs. A packer.json in the example would be a good idea, and you'll get faster deploys that are a bit more predictable. Then you can use something like Vagrant to test the packer config.
I wrote a very lightweight Vagrant clone here this weekend for exactly that purpose - https://github.com/mpdehaan/strider