RubyGems - brightbox-cli - Versions diffs - 0.13.0 - Mend

brightbox-cli 0.13.0

Files changed (1716) hide show

data/lib/brightbox-cli/vendor/fog/docs/_config.yml ADDED Viewed

@@ -0,0 +1,39 @@
+safe:        false
+auto:        false
+server:      false
+server_port: 4000
+source:      .
+destination: ./_site
+plugins:     ./_plugins
+future:      true
+lsi:         false
+pygments:    false
+markdown:    maruku
+permalink:   none
+maruku:
+  use_tex:    false
+  use_divs:   false
+  png_engine: blahtex
+  png_dir:    images/latex
+  png_url:    /images/latex
+rdiscount:
+  extensions: []
+kramdown:
+  auto_ids: true,
+  footnote_nr: 1
+  entity_output: as_char
+  toc_levels: 1..6
+  use_coderay: false
+  coderay:
+    coderay_wrap: div
+    coderay_line_numbers: inline
+    coderay_line_numbers_start: 1
+    coderay_tab_width: 4
+    coderay_bold_every: 10
+    coderay_css: style

data/lib/brightbox-cli/vendor/fog/docs/_layouts/default.html ADDED Viewed

@@ -0,0 +1,111 @@
+<!doctype html>
+<!--[if lt IE 7 ]> <html lang="en" class="no-js ie6"> <![endif]-->
+<!--[if IE 7 ]>    <html lang="en" class="no-js ie7"> <![endif]-->
+<!--[if IE 8 ]>    <html lang="en" class="no-js ie8"> <![endif]-->
+<!--[if IE 9 ]>    <html lang="en" class="no-js ie9"> <![endif]-->
+<!--[if (gt IE 9)|!(IE)]><!--> <html lang="en" class="no-js"> <!--<![endif]-->
+<head>
+  <meta charset="utf-8">
+  <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
+  <title>fog - {{ page.title }}</title>
+  <meta name="description" content="">
+  <meta name="author" content="">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <!--
+    <link rel="shortcut icon" href="/public/favicon.ico">
+    <link rel="apple-touch-icon" href="/public/apple-touch-icon.png">
+  -->
+  <link rel="stylesheet" href="/public/css/style.css?v=2">
+  <link rel="stylesheet" href="/public/css/fog.css?v=2">
+  <script src="/public/js/libs/modernizr-1.6.min.js"></script>
+</head>
+<body>
+  <div id="container">
+    <header>
+      <a href="/"><img src="/public/images/fog.png" title="fog" /></a>
+      <h1>{{ page.title }}</h1>
+      <dl>
+        <dt>version</dt><dd>vX.Y.Z</dd>
+        <dt>install</dt><dd><code>gem install fog</code></dd>
+        <dt>source</dt><dd><a href="http://github.com/geemus/fog">geemus/fog</a></dd>
+      </dl>
+    </header>
+    <div id="main">
+      {{ content }}
+      <h2>Services</h2>
+      <ul>
+        <li><a href="/cdn">CDN</a></li>
+        <li><a href="/compute">Compute</a></li>
+        <li><a href="/dns">DNS</a></li>
+        <li><a href="/storage">Storage</a></li>
+        {% for post in site.posts %}
+        <li><a href="{{ post.url }}">{{ post.title }}</a></li>
+        {% endfor %}
+      </ul>
+      <h2>About</h2>
+      <ul>
+        <li><a href="/">Home</a></li>
+        <li><a href="/about/contributing.html">Contributing</a></li>
+        <li><a href="/about/getting_started.html">Getting Started</a></li>
+        <li><a href="/about/press.html">Press</a></li>
+        <li><a href="/about/structure.html">Structure</a></li>
+        <li><a href="/about/supported_services.html">Supported Services</a></li>
+        <li><a href="/about/users.html">Users</a></li>
+      </ul>
+    </div>
+    <footer>
+      sponsored by
+      <img height="20px" src="public/images/engineyard.png" title="engineyard" />
+    </footer>
+  </div> <!-- end of #container -->
+  <script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js"></script>
+  <script>!window.jQuery && document.write(unescape('%3Cscript src="public/js/libs/jquery-1.4.2.js"%3E%3C/script%3E'))</script>
+  <!-- scripts concatenated and minified via ant build script-->
+  <script src="public/js/plugins.js"></script>
+  <script src="public/js/script.js"></script>
+  <!-- end concatenated and minified scripts-->
+  <!--[if lt IE 7 ]>
+    <script src="public/js/libs/dd_belatedpng.js"></script>
+    <script> DD_belatedPNG.fix('img, .png_bg'); </script>
+  <![endif]-->
+  <!-- yui profiler and profileviewer - remove for production -->
+  <script src="public/js/profiling/yahoo-profiling.min.js"></script>
+  <script src="public/js/profiling/config.js"></script>
+  <!-- end profiling code -->
+  <!-- change the UA-XXXXX-X to be your site's ID -->
+  <script>
+   var _gaq = [['_setAccount', 'UA-301159-7'], ['_trackPageview']];
+   (function(d, t) {
+    var g = d.createElement(t),
+        s = d.getElementsByTagName(t)[0];
+    g.async = true;
+    g.src = ('https:' == location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
+    s.parentNode.insertBefore(g, s);
+   })(document, 'script');
+  </script>
+</body>
+</html>

data/lib/brightbox-cli/vendor/fog/docs/about/contributing.markdown ADDED Viewed

@@ -0,0 +1,228 @@
+---
+layout: default
+title:  Contributing
+---
+First off, high five for coming to visit this page.  You are my new hero.
+## Overview
+* Organize your patches by keeping all related changes together in a topic branch.
+* Rebase your branch against master before submitting a pull request (and squish any 'oops' or work in progress commits).
+* Submit changes as pull requests describing what the changes should cover and referencing issues (if any).
+* Use 'tags' in your commits to indicate the scope, so things like '\[aws|compute\] fixed something'.
+* Write and run tests.  Tests should follow through usage workflows and ought to pass both with mocking on and off.
+## Deep dive
+Now then, some of the what makes it tick and why. For simplicity let's pretend you want to implement a new service, from scratch. I will walk through the requisite pieces and important things to keep in mind as you go.
+But, before I dive too deep, I'll leave you with an out.  Other great ways to contribute are fixing bugs, writing documentation or helping port other projects to use fog. That way everybody wins!
+## The Service
+First and foremost you'll need to create a service, which should start from something like:
+    module Fog
+      class TheService < Fog::Service
+        requires :necessary_credential
+        model_path 'path/to/models'
+        collection 'name_of_collection'
+        model 'name_of_model'
+        request_path 'path/to/requests'
+        request 'name_of_request'
+        class Mock
+          include Collections
+        end
+        class Real
+          include Collections
+        end
+      end
+    end
+### Highlights:
+* we segregate between real and mock so it is easier to add stuff to one or the other later.
+* this is where any shared stuff will go, like making/signing requests
+## Requests
+The next thing to bite off are the requests. fog is all about making cloud services easier to use and move between, but requests are not where this happens. Requests should map closely to the actual api requests (you should be able to directly reference the api docs and vice versa). In particular, try to keep the output of any data parsing as close to the actual format as possible. This makes implementation and maintenance much easier and provides a solid foundation for models to build nice things on top of. I generally end up working on stuff to get/list details first and then filling in create/destroy pairs and other requests.
+You start with something like this:
+<pre>
+module Fog
+  class TheService
+    class Real
+      def request(*args)
+      end
+    end
+    class Mock
+      def request(*args)
+        Fog::Mock.not_implemented
+      end
+    end
+  end
+end
+</pre>
+### Highlights:
+* You should define the method twice, once for the real implementation and once for mocked (they should take the same arguments).
+* The mock versions should just start out by raising a not implemented error, you can come back and fill this in later.
+* The real version should make a request, probably by a method defined on the real class in the service you defined earlier.
+* Each request should either return an Excon::Response (with a parsed body where appropriate) or raise an error.
+## Tests
+Now would be a good time to write some tests to make sure what you have written works (and will continue to). I've tried a couple variations on testing in the past, but have settled on consolidated lifetime testing. These vary enough that its hard to give a single simple example, but you can see many examples in "tests/compute/requests/aws":https://github.com/geemus/fog/tree/master/tests/compute/requests/aws/.
+### Highlights:
+* Reuse the same objects and take them through their whole life cycle (this is much faster, and most of the time if one portion fails the others would anyway).
+* Test the format of the output to ensure parsers match expectations (check the provider's api docs) and that mocks return matching data.
+* Test common failure cases and their behavior, you'll need to know how the service acts in these cases to make better mocks.
+## Models
+You could also skip to the mocks here if you wanted, but I usually find the more time I spend working with the service the easier it is to build mocks. The models are the real pay dirt, you have slogged through low level requests that map to the provider api and now you want a nice interface. This is where models and collections come in. Collections provide access to lists of data on the provider and for creating new objects. Models represent the individual objects.
+If you know which object you'd like to represent you should start with the collection. When naming, please refer to the names that have been chosen for other services. I haven't standardized all nouns yet, but a few are already shared (Flavor, Image, Server)
+An example servers collection:
+    require 'fog/collection'
+    require 'fog/theservice/models/server'
+    module Fog
+      class TheService
+        class Servers < Fog::Collection
+          model Fog::TheService::Server
+          def all
+            # get list of servers
+            load(data) # data is an array of attribute hashes
+          end
+          def get(identity)
+            # get server matching id
+            new(data) # data is an attribute hash
+          rescue Excon::Errors::NotFound
+            nil
+          end
+        end
+      end
+    end
+### Highlights
+* First make an accessor in the Collections model so it will be included in Real and Mock.
+* `#model` will take a reference to the class that will be instantiated to represent individual objects.
+* `#all` should get a list of servers from the provider and pass an array of attribute hashes, one per server, to load.
+* `#get` should take an identity reference and instantiate a new model object with an attribute hash returned from the remote server, or return nil of no such object exists.
+Models handle remapping attributes into friendlier names and providing the rest of the interface.
+An example model:
+    require 'fog/model'
+    module Fog
+      module TheService
+        class Server << Fog::Model
+          identity  :id
+          attribute :state, 'StatusValue'
+          def destroy
+            requires :identity
+            connection.destroy_server(identity)
+            true
+          end
+          def ready?
+            state == 'running'
+          end
+          def save
+            requires ...
+            connection.create_server(options)
+            true
+          end
+        end
+      end
+    end
+### Highlights
+* `#identity` captures the id/name that the objects are identified by and takes the same arguments as attribute.
+* `#attribute` takes the name to make a variable available as and one or more aliases that parsers/requests will return this value as.
+* `#destroy` will require the identity of the model and should destroy it and return true.
+* `#ready?` should return whether the object has finished being initialized (where appropriate).
+* `#save` should take any required objects and instantiate the object on the provider's service.
+* These models just rely on underlying collections and requests, so it should not be necessary at this level to distinguish between Real and Mock methods.
+## Mocks
+Mocks provide a powerful tool for users of fog to experiment with their implementations much more quickly and without incurring costs. I usually save these for last, as implementing the requests and models provide some necessary context to finally put the mocks together. Your services mock class should have a data method that will return mocked data like so:
+    module Fog
+      module TheService
+        class Mock
+          def self.data
+            @data ||= Hash.new do |hash, key|
+              hash[key] = {}
+            end
+          end
+        end
+      end
+    end
+The keys in this hash should represent a unique identifier of the user accessing the data and the value assigned should contain any default data that a new user might have. Any implemented mock requests should then return data retrieved from here or raise an error.
+For instance:
+    module Fog
+      module TheService
+        class Mock
+          def destroy_server(server_identity)
+            if data = self.data[:servers].delete(server_identity)
+              response = Excon::Response.new
+              response.status = 202
+              response.body   = data
+              response
+            else
+              raise Fog::TheService::NotFound
+            end
+          end
+        end
+      end
+    end
+### Highlights
+* Mock requests should return the same type of data as an already parsed real response or should return the same error as a real problem.
+* By mocking at this low level, higher level functions are automatically mocked out for you.
+* The extra rigorous tests related to output formatting and error messages should help keep you honest, and each should pass in both mocked and unmocked modes.
+## Summary
+That provides a lot more detail than you will probably need right away, but hopefully you can refer back to different sections as you need them. If you have any questions send me a github message or email me (address is on my profile). You should always start development by creating your own fork. When you feel confident about your fork, send me a pull request. Be forewarned that I may edit some things before it gets to master, but I'll do my best to take care of this in a timely manner.
+Thanks again for your interest and let me know if there is anything else I can do to help.

data/lib/brightbox-cli/vendor/fog/docs/about/getting_started.markdown ADDED Viewed

@@ -0,0 +1,83 @@
+---
+layout: default
+title:  Getting Started
+---
+First off, install the gem:
+    $ gem install fog
+## Setting Up Local Storage
+We will be using Local storage in the example.  Local storage provides the same api that cloud storage services in fog do, but without the bother of needing to signup for stuff or pay extra money.
+First, make a local directory to hold your data.
+    $ mkdir ~/fog
+Now we can start writing our script, first off we should require fog.
+    require 'rubygems'
+    require 'fog'
+Now in order to play with our data we need to setup a storage connection.
+    storage = Fog::Storage.new({
+      :local_root => '~/fog',
+      :provider   => 'Local',
+    })
+`storage` will now contain our storage object, configured to use the Local provider from our specified directory.
+## Storing Data
+Now that you have cleared the preliminaries you are ready to start storing data. Storage providers in fog segregate files into `directories` to make it easier to organize things. So lets create a directory so we can see that in action.
+    directory = Fog::Storage.directories.create(
+      :key => 'data'
+    )
+To make sure it was created you can always check in your filesystem, but we can also check from inside fog.
+    storage.directories
+Progress! Now it is time to actually create a file inside our new directory.
+    file = directory.files.create(
+      :body => 'Hello World!',
+      :key  => 'hello_world.txt'
+    )
+We should now have our file, first we can open it up and make sure we are on the right track.
+    $ open ~/fog/hello_world.txt
+It is much more likely that you will want to see what files you have from inside fog though.
+    directory.files
+Now that we have run through all the basics, lets clean up our mess.
+    file.destroy
+    directory.destroy
+After that you should be able to check your directory list in fog or your filesystem and see you are safely back to square one.
+## Next Steps
+Using the same interface you can also practice working against a real provider (such as Amazon S3).  Rather than worrying about signing up for an account right away though, we can use mocks to simulate S3 while we practice.
+This time we will turn on mocking and then, just like before, we will need to make a connection.
+    Fog.mock!
+    storage = Fog::Storage.new({
+      :aws_access_key_id      => 'fake_access_key_id',
+      :aws_secret_access_key  => 'fake_secret_access_key',
+      :provider               => 'AWS'
+    })
+You may notice that we used bogus credentials, this is fine since we are just simulating things.  To use real S3 you can simply omit `Fog.mock!` and swap in your real credentials.
+Once you have your connection you can go through all the steps you did before, only now you will be working against a real cloud service (or at least a simulated one).
+Congratulations and welcome to the cloud!  Continue your journey at [fog.io](http://fog.io)

data/lib/brightbox-cli/vendor/fog/docs/about/press.markdown ADDED Viewed

@@ -0,0 +1,48 @@
+---
+layout: default
+title:  Press
+---
+Mentions and blog posts from elsewhere in reverse chronological order by day (and alphasorted for same days).
+**August 1st, 2011**
+* [Using EBS Snapshots with Fog](http://www.mediamolecule.com/lab/article/using_ebs_snapshots_with_fog/)
+**June 21st, 2011**
+* [Mocking fog When Using It With Carrierwave](http://www.engineyard.com/blog/2011/mocking-fog-when-using-it-with-carrierwave/)
+**June 14th, 2011**
+* [Backing Up Your Data With Fog](http://larrywright.me/blog/articles/221-backing-up-your-data-with-fog)
+**April 7th, 2011**
+* [Testing multipart Uploads to S3 with Threads](http://blog.vicecity.co.uk/post/4425574978/multipart-uploads-fog-threads-win)
+**March 9th, 2011**
+* [Offsite Backups with fog](http://www.engineyard.com/blog/2011/offsite-backups-with-fog/)
+**March 2nd, 2011**
+* [Better AWS Access Control with IAM and Fog](http://blog.zerosum.org/2011/03/02/better-aws-access-control-with-iam-and-fog.html)
+* [Using Amazon's CloudFormation, cloud-init, chef and fog to automate infrastructure](http://allanfeid.com/content/using-amazons-cloudformation-cloud-init-chef-and-fog-automate-infrastructure)
+**January 6th, 2011**
+* [Happy New Year (and 0.4.0) from fog!](http://www.engineyard.com/blog/2011/happy-new-year-and-0-4-0-from-fog/)
+**November 30th, 2010**
+* [Getting Hired: fog Edition](http://www.engineyard.com/blog/2010/getting-hired-fog-edition/)
+**October 13, 2010**
+* [Engine Yard Announces Formal Support for ‘fog’ to Ensure Application Portability in the Cloud](http://www.engineyard.com/company/press/2010-10-13-engine-yard-announces-formal-support-for-%E2%80%98fog%E2%80%99-to-ensure-application-portability-in-the-cloud)
+* [Wesley Beary and fog Promoted to the Engine Yard Open Source Program](http://www.engineyard.com/blog/2010/wesley-beary-and-fog-promoted-to-the-engine-yard-open-source-program/)
+**September 28, 2010**
+* [The Curious Tale of the Humble Micro](http://www.engineyard.com/blog/2010/the-curious-tale-of-the-humble-micro/)

data/lib/brightbox-cli/vendor/fog/docs/about/structure.markdown ADDED Viewed

@@ -0,0 +1,78 @@
+---
+layout: default
+title:  Structure
+---
+fog is the Ruby cloud computing library, top to bottom:
+* Collections provide a simplified interface, making clouds easier to work with and switch between.
+* Requests allow power users to get the most out of the features of each individual cloud.
+* Mocks make testing and integrating a breeze.
+## Collections
+A high level interface to each cloud is provided through collections, such as `images` and `servers`.
+You can see a list of available collections by calling `collections` on the connection object. You can try it out using the `fog` command:
+    >> AWS.collections
+    [:addresses, :directories, ..., :volumes, :zones]
+Some collections are available across multiple providers:
+* compute providers have `flavors`, `images` and `servers`
+* dns providers have `zones` and `records`
+* storage providers have `directories` and `files`
+Collections share basic CRUD type operations, such as:
+* `all` - fetch every object of that type from the provider.
+* `create` - initialize a new record locally and a remote resource with the provider.
+* `get` - fetch a single object by it's identity from the provider.
+* `new` - initialize a new record locally, but do not create a remote resource with the provider.
+As an example, we'll try initializing and persisting a Rackspace Cloud server:
+    require 'fog'
+    compute = Fog::Compute.new({
+      :provider           => 'Rackspace',
+      :rackspace_api_key  => key,
+      :rackspace_username => username
+    })
+    # boot a gentoo server (flavor 1 = 256, image 3 = gentoo 2008.0)
+    server = compute.servers.create(:flavor_id => 1, :image_id => 3, :name => 'my_server')
+    server.wait_for { ready? } # give server time to boot
+    # DO STUFF
+    server.destroy # cleanup after yourself or regret it, trust me
+## Models
+Many of the collection methods return individual objects, which also provide common methods:
+* `destroy` - will destroy the persisted object from the provider
+* `save` - persist the object to the provider
+* `wait_for` - takes a block and waits for either the block to return true for the object or for a timeout (defaults to 10 minutes)
+## Requests
+Requests allow you to dive deeper when the models just can't cut it.
+You can see a list of available requests by calling #requests on the connection object.
+For instance, ec2 provides methods related to reserved instances that don't have any models (yet). Here is how you can lookup your reserved instances:
+    $ fog
+    >> AWS[:ec2].describe_reserved_instances
+    #<Excon::Response [...]>
+It will return an [excon](http://github.com/geemus/excon) response, which has `body`, `headers` and `status`. Both return nice hashes.
+## Mocks
+As you might imagine, testing code using Fog can be slow and expensive, constantly turning on and and shutting down instances.
+Mocking allows skipping this overhead by providing an in memory representation resources as you make requests.
+Enabling mocking easy to use, before you run other commands, simply run:
+    Fog.mock!
+Then proceed as usual, if you run into unimplemented mocks fog will raise an error and as always contributions are welcome!

data/lib/brightbox-cli/vendor/fog/docs/about/users.markdown ADDED Viewed

@@ -0,0 +1,33 @@
+---
+layout: default
+title:  Users
+---
+Here lies a listing of projects and products that are using fog.
+Please feel free to add your own, just please follow these rules for consistency and readability.
+1. Listings should be in alphabetical order and should have a link and list of services used.
+2. Projects that are open source should link to where the source code can be found.
+3. Products that are not open source should link to where more information about the product can be found.
+Thanks for following these rules to keep the quality high and and the content useful!
+## Projects
+* [carrierwave](http://github.com/jnicklas/carrierwave) = AWS => Storage
+* [chef](http://github.com/opscode/chef) = AWS => Compute, Slicehost => Compute, Terremark => vCloud, Rackspace => Compute
+* [deckard](http://github.com/joewilliams/deckard) = AWS => Compute
+* [gaff](http://github.com/joewilliams/gaff) = AWS => Compute, Slicehost => Compute
+* [gemcutter](http://github.com/rubygems/gemcutter) = AWS => Storage
+* [plover](http://github.com/railsmachine/plover) = AWS => Compute
+## Products
+* [DevStructure](http://devstructure.com/) = AWS => Compute, Rackspace => Compute, Slicehost => Compute
+* [Engine Yard AppCloud](http://www.engineyard.com/cloud) = AWS => \[Compute, Storage\]
+* [iSwifter](http://iswifter.youwebinc.com/) = BlueBox => Compute
+* [OpenFeint](http://openfeint.com) = BlueBox => Compute
+* [PHPFog](https://phpfog.com) = AWS => Compute
+* [RowFeeder](https://rowfeeder.com) = Blue Box Group => Compute
+* [Viximo](http://viximo.com) = AWS => Compute