Oh man, was I suffering from a slow Motorola Droid 4. Switching between apps took MINUTES. It was awful. I’m running Verizon supplied Android 4.1.2. I was blaming it on Waze or Facebook or not enough RAM. Then I did some searching and boy was I wrong.
All you gotta do is:
“Settings” -> “Developer Options” and set all the “animations” to off. For good measure I limited background apps to 3 in number.
Now my phone is fast and wonderful. It’s great! If this helps you too, leave a shoutout!
I love RunDeck. It’s just enough orchestration to get many jobs done in such an easy way. I can take whatever’s working for me, wrap it up in RunDeck and give it to someone. I wrote a long writeup on hooking it to your Active Directory, through OpenLDAP. I’m old school. But all I’ve ever wanted is a composable RunDeck. To bring inter-tool composition right into my face.
So then I fell in love with Chef and Puppet as they grabbed the very necessary spotlight. Suddenly, arising from the past of CFEngine, I could now code my infrastructure! Different parts of the system worked predictably, across platforms, and with such clarity and simplicity. Chef saves me thousands of lines of code, and helps me reason about my systems on a whole other level.
But these two worlds never really fit together very well. I want my “just enough orchestration,” but with the little bit of smarts necessary to interact intelligently with the abstract resources.
I was thinking, “Yeah, sure, it runs. But how does it all fit together? I want to compose!” OMG, then all sorts of other little tools that control other things came around, and I wanted to wrap them up in a big hug. A big smart hug, that knows just how they like to be hugged.
Crowbar 1.x originally only hugged Chef. And even only hugging Chef, it did MORE than Razor and Cobbler do (still today) combined. And it did it all in a way that’s not “enterprisey” and is just clear and makes sense. But it didn’t get all the way to that “composable RunDeck” thing that I was looking for.
So we wrote OpenCrowbar. And now it does.
Yes, this is hysterically historical. I’m keeping it here for safe keeping.
Control Tier Authentication and Authorization: Files, OpenLDAP, and Pass Through to Active Directory
You want to enable flexible authentication and authorization schemes for your Control Tier server.
*# Control Tier first checks the “fileRealm” files for usernames, passwords and roles.
*# On failure, Control Tier then checks against an OpenLDAP server which is setup to acts as a proxy for the corporate Active Directory, while also providing it’s own branches for Control Tier roles (and any other apps.)
Control Tier --> files -> OpenLDAP --> Active Directory
(users (roles) (users)
ou=roles,dc=corp,dc=example,dc=net <-- OpenLDAP
ou=people,dc=corp,dc=example,dc=net <-- Active Directory
Well, I guess it had to come to this. Rob Hirschfeld brought up the wonderfully preposterous notion of puppies growing up to be dinosaurs. And as a good scientist, and a profound thinker in DevOps, Rob’s statement is based upon his direct observation. He states that our most beloved pets can become tyrants (Tyrannosaurus Rex, aptly named) in our lives in operations.
I hack on Crowbar a lot. And here’s how I run my show:
1) dev/build box running ubuntu-12.04
2) Crowbar Admin box running whatever latest stuff i just built – and mostly works
3) a test node box, where I used Crowbar to deploy whatever I’m working on
4) another test node box, where I’ve used crowbar to deploy what I’ve been working on.
Here’s a few paragraphs of my thoughts about Functional Operations. By Functional Operations I mean that which emerges out of the meeting of “golden images” (delicately crafted base images that once deployed need config management) and “config management” (the config data and rules for applying it to a live golden image.)
As the “golden” image itself becomes integrated into the config management, it changes just like any other variable in the config management database. What’s changed in our toolkit? What benefits do we get?
It’s going to take some time to understand and articulate the full awesomeness of Crowbar 2’s approach to DevOps. One of the ways is to envision “Functional Operations,” similar to “Functional Programming”… this is early, but it’s a peek at our thinking. Paraphrasing Parliament Funcadelic: “Make my Func the FuncOps, I want to get FuncOps.”
What Erlang teaches us about orchestration.
Erlang’s design allows for intergalactic scalability and concurrency. Let’s riff off of a great design!
As tools like Docker eliminate much of the slowness and immutability of “golden images” and more robust config managers like Enterprise Chef reach further out across the datacenter, three thoughts come to mind:
Implicit roles must exist on a node to satisfy the dependency, while Automatic roles must exist somewhere in the deployment to satisfy the dependency.
As I listen to my esteemed colleagues in the OpenStack world, and the DevOps and Cloud world in general, say that there is no demand for Object Storage, I get all sad. Why? Because that means that they’re mounting volumes. It means they’re mounting volumes and storing their precious there. That means that the cloud platform is most likely doing something complicated and expensive to replicate this data. That means that Amazon’s S3 didn’t really change anything and we’re just developing enterprise software again.
The great limitation of Object Storage is doing seek operations on files. Seeks break down into reads and writes.
Reads include the CDNs aplenty that have solved this problem, but it’s a read-only solution for jumping around in video. I don’t have a problem with that, as it’s an API based service that is easily implemented and accessed.
However, the other big use case is writes, and the culprit is SQL (and some NoSQL) Database Files. Seeks through those files are critical to their operation.
I’m interested in what other requirements are driving the mounting of block devices, and what’s distracting app developers from the great awesomeness of Object Stores like Swift.