CloudForms 4.1 – Setting up SmartProxy (fleecing) correctly

The docs totally don’t tell you that you’ll need more space to use the SmartProxy function.  But I will. 🙂  They do make it easy, though.

As a bit of background:  To run a SmartProxy analysis (“fleecing,”) CloudForms take a snapshot of the running VM (if the VM is indeed running), and copies that snapshot over to the CloudForms VM.  It then mounts that image and processes it.  So, you’ll need plenty of disk space for processing.

First, make yourself a nice mountable volume somewhere that the VM can see.  I created a cinder volume of 100GB and use nova volume-attach to attach it to my running CloudForms VM.

Then ssh into the CloudForms machine and run the “appliance_console.”

There’s an option to “expand temporary space.”   It’ll discover the volume you’ve just attached to your VM.   You don’t need to restart anything.

Next time you run the SmartProxy analysis, it will have enough disk space for one or two concurrent analysis tasks.


Mayfiles and Dinosaurs – Metamorphosis and Epigenetics in Devops

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.

Continue reading “Mayfiles and Dinosaurs – Metamorphosis and Epigenetics in Devops”

FuncOps: Orchestration and The Mothership Connection

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!

Continue reading “FuncOps: Orchestration and The Mothership Connection”

If you’re not using an Object Store, you’re not writing cloud software

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.