fog-oneandone 1.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: 56d7c39794b25233e7aaa863d457f412a671af87
+  data.tar.gz: b2c478a22092ab58ad2ba8981cd28b317d83a611
+SHA512:
+  metadata.gz: a067ef076c2893ded4479444789baf5fd6cf9cd768d9d772a2f30e91c392c4d1e6c90a84c5544d62288e5b15d5e58db0638dbebd37c05eb1d3bb3482c2535dd1
+  data.tar.gz: 959e2eda82a1a0e56550fff4ad9020eb016c002c3e80af37cfef55db86e085e1b1bc870f27f6080bb52ddecfe280e7c4c28ddc05f1697a000f123d1b611ca344

data/.gitignore

@@ -0,0 +1,36 @@
+*.gem
+*.rbc
+/.config
+/coverage/
+/InstalledFiles
+/pkg/
+/spec/reports/
+/spec/examples.txt
+/test/tmp/
+/test/version_tmp/
+/tmp/
+
+## Specific to RubyMotion:
+.dat*
+.repl_history
+build/
+
+## Documentation cache and generated files:
+/.yardoc/
+/_yardoc/
+/doc/
+/rdoc/
+
+## Environment normalization:
+/.bundle/
+/vendor/bundle
+/lib/bundler/man/
+
+# for a library or gem, you might want to ignore these files since the code is
+# intended to run in multiple environments; otherwise, check them in:
+# Gemfile.lock
+# .ruby-version
+# .ruby-gemset
+
+# unless supporting rvm < 1.11.0 or doing something fancy, ignore this:
+.rvmrc

data/CONTRIBUTING.md

@@ -0,0 +1,276 @@
+# Getting Involved
+
+## Introduction
+
+First off, high five for coming to visit this page.  You are my new hero.
+
+New contributors are always welcome, when it doubt please ask questions. We strive to be an open and welcoming community. Please be nice to one another.
+
+### Coding
+
+* Pick a task:
+  * Offer feedback on open [pull requests](https://github.com/fog/fog/pulls).
+  * Review open [issues](https://github.com/fog/fog/issues) for things to help on.
+  * [Create an issue](https://github.com/fog/fog/issues/new) to start a discussion on additions or features.
+* Fork the project, add your changes and tests to cover them in a topic branch.
+* Commit your changes and rebase against `fog/fog` to ensure everything is up to date.
+* [Submit a pull request](https://github.com/fog/fog/compare/)
+
+### Non-Coding
+
+* Offer feedback on open [issues](https://github.com/fog/fog/issues).
+* Write and help edit [documentation](https://github.com/fog/fog.github.com).
+* Translate [documentation](https://github.com/fog/fog.github.com) in to other languages.
+* Organize or volunteer at events.
+* [Donate](https://www.gittip.com/geemus/)
+* Discuss other ideas for contribution with [geemus](mailto:geemus+fog@gmail.com).
+
+### Changes
+
+Before we go into more detail, please be aware that Fog is going through some growing pains right now.  A lot of things are moving right now, and things may not be documented as well as we would like.
+
+It might be wise to check out the [Roadmap](https://github.com/fog/fog/wiki/Roadmap) and [Design Document](https://github.com/fog/fog/wiki/fog-design-document) in the Wiki for more information.
+
+For right now, there are three major things in motion:
+
+#### Meta-gem movement
+
+Fog is moving from a monolithic gem structure to a meta-gem structure, where code for specific providers will be housed in `fog-provider` gems.  Extracting provider code is an ongoing process, and is also causing some performance issues.
+
+Relevant issues include:
+
+- General: [#1253](https://github.com/fog/fog/issues/1253), [#2602](https://github.com/fog/fog/issues/2602), [#2681](https://github.com/fog/fog/issues/2681), [#2877](https://github.com/fog/fog/issues/2877)
+- Performance: [#3430](https://github.com/fog/fog/issues/3430)
+
+#### Testing
+
+In the past, fog has used the [Shindo](https://github.com/geemus/shindo) test framework, but is moving toward using `minitest` instead.  Furthermore, the mocking structure fog has used to test in the past is undergoing some scrutiny and changes.
+
+Relevant issues include:
+
+- General: [#1266](https://github.com/fog/fog/issues/1266)
+- Shindo -> minitest: [#2630](https://github.com/fog/fog/issues/2630)
+- Mocking: [#1252](https://github.com/fog/fog/issues/1252), [#1266](https://github.com/fog/fog/issues/1266) starting about halfway down, [#1418](https://github.com/fog/fog/issues/1418), [#2629](https://github.com/fog/fog/issues/2629)
+
+## 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).
+* We support several rubies!  Make sure your changes will work for all the Rubies in `.travis.yml`
+* 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/aws/requests/compute](https://github.com/fog/fog/tree/master/tests/aws/requests/compute).
+
+### 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/CONTRIBUTORS.md

@@ -0,0 +1 @@
+* Tyler Burkhardt <tyler@stackpointcloud.com>

data/Gemfile

@@ -0,0 +1,4 @@
+source 'https://rubygems.org'
+
+# Specify your gem's dependencies in fog-oneandone.gemspec
+gemspec

data/LICENSE.md

@@ -0,0 +1,20 @@
+The MIT License (MIT)
+
+Copyright (c) 2009-2015 [CONTRIBUTORS.md](https://github.com/fog/fog/blob/master/CONTRIBUTORS.md)
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of
+this software and associated documentation files (the "Software"), to deal in
+the Software without restriction, including without limitation the rights to
+use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
+the Software, and to permit persons to whom the Software is furnished to do so,
+subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
+FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
+COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
+IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README.md

@@ -0,0 +1,317 @@
+# Fog-oneandone
+
+[![Build Status](https://travis-ci.org/tjb1019/fog.svg?branch=master)](https://travis-ci.org/tjb1019/fog)
+
+Fog is an open-source, community Ruby library used for interacting with popular cloud infrastructure providers through a single, unified API.
+
+This guide will show you how to programmatically use the 1&1 provider in Fog to perform common management tasks available in the 1&1 Cloud Panel.
+
+## Table of Contents
+
+- [Overview](#overview)
+- [Getting Started](#getting-started)
+  * [Installation](#installation)
+  * [Authentication](#authentication)
+- [Models](#models)
+  - [Creating a Server](#creating-a-server)
+  - [Updating Server Cores, Memory, and Disk](#updating-server-cores-memory-and-disk)
+  - [Deleting a Server](#deleting-a-server)
+- [Collections](#collections)
+- [Mocks](#mocks)
+- [Example App](#example-app)
+
+
+
+## Overview
+
+The Fog library wraps the <a href='https://cloudpanel-api.1and1.com/documentation/1and1/v1/en/documentation.html'>1&amp;1 REST API</a>. All API operations are performed over SSL and authenticated using your 1&amp;1 credentials. The API can be accessed within an instance running in 1&amp;1 or directly over the Internet from any application that can send an HTTPS request and receive an HTTPS response.
+
+The Fog library provides two methods of interacting with 1&amp;1. The first method utilizes an abstracted collection and model layer that is similar across all cloud providers within Fog.
+
+A collection is a group of similar resources such as servers, images, or firewalls and allows basic CRUD (create/read/update/delete) operations on collections and models. This guide will cover interactions with the 1&amp;1 environment solely using collections and models.
+
+While out of scope of this guide, the second Fog method provides direct request methods that specifically match provider API methods. In the case of the 1&amp;1 provider, the request methods map to the <a href='https://cloudpanel-api.1and1.com/documentation/1and1/v1/en/documentation.html'>1&amp;1 REST API</a> endpoints and parameters. More details on requests can be found at the <a href='http://fog.io'>Fog</a> website.
+
+
+## Getting Started
+
+Before you begin you will need to have signed-up for a 1&amp;1 account. The credentials you setup during sign-up will be used to authenticate against the API.
+
+
+### Installation
+
+You can install the latest stable version using:
+
+`$ gem install fog-oneandone`
+
+
+### Authentication
+
+Connecting to 1&amp;1 can be done by creating a compute connection with the provider.
+
+```ruby
+require 'fog-oneandone'
+
+compute = Fog::Compute::OneAndOne.new({
+  :oneandone_api_key => '<API-TOKEN>'
+})
+```
+
+Credentials can be specified as shown above or placed in a `.fog` file located in the home directory.
+
+```bash
+$ less ~/.fog
+default:
+  oneandone_api_key: <API-TOKEN>
+```
+
+
+## Models
+
+Models act as your interface for working with provider resources.  In the examples below, we will create a server, and perform various actions to that server using its model.  All models come equipped with the `wait_for` and `destroy` methods, as well as other methods that perform various `POST`, `PUT`, and `DELETE` actions.  These additional methods vary by model. 
+
+
+### Creating a Server
+
+The following example shows you how to create a new server in the Great Britain 
+data center with a fixed hardware configuration.
+
+The server can take time to provision. The `wait_for` server object method will wait until the server state is available before continuing, and returns a hash containing the method's execution duration. This is useful when chaining together requests that are dependent upon one another.
+
+A server "model" will be returned to the `my_server` variable.  You can use this model to access the server's attributes and perform further operations.
+```ruby
+compute = Fog::Compute::OneAndOne.new({
+  :oneandone_api_key => '<API-TOKEN>'
+})
+
+
+my_server = compute.servers.create(name: 'My Server',
+  fixed_instance_id: '65929629F35BBFBA63022008F773F3EB',
+  appliance_id: '6C902E5899CC6F7ED18595EBEB542EE1',
+  datacenter_id: '5091F6D8CBFEF9C26ACE957C652D5D49')
+
+puts my_server.wait_for { ready? }
+```
+
+If you would prefer to set your own custom hardware configuration, then simply replace `fixed_instance_id` with values for
+`vcore`, `ram`, `cores_per_processor`, and `hdds`, like so:
+
+```ruby
+hdd1 = {
+  'is_main' => true,
+  'size' => 60
+}
+
+hdds = [hdd1]
+
+my_server = compute.servers.create(name: 'My Server',
+  vcore: 1, ram: 1, cores_per_processor: 1, hdds: hdds
+  appliance_id: '6C902E5899CC6F7ED18595EBEB542EE1',
+  datacenter_id: '5091F6D8CBFEF9C26ACE957C652D5D49')
+  
+ puts my_server.wait_for { ready? }
+```
+
+### Updating Server Cores, Memory, and Disk
+
+Using our `my_server` model from above, we can easily update the server's hardware configuration, like so:
+
+```ruby
+my_server.update_hardware(vcore: 2, ram: 4)
+my_server.wait_for { ready? }
+
+puts my_server.hardware['vcore'] 
+>> 2
+
+puts my_server.hardware['ram']
+>> 4
+```
+
+Need extra storage?  Adding an additional HDD is easy:
+
+```ruby
+hdd2 = {
+ 'is_main' => false,
+ 'size' => 80
+}
+
+hdds = [hdd2]
+
+my_server.add_hdds(hdds: hdds)
+my_server.wait_for { ready? }
+
+puts my_server.hardware['hdds']
+>> [{'is_main' => true, 'size' => 60}, {'is_main' => false, 'size' => 80}]
+```
+
+Ready to downsize?  Deleting storage is easy too:
+
+```ruby
+hdd2_id = my_server.hardware['hdds'][1]['id']
+
+my_server.delete_hdd(hdd_id: hdd2_id)
+my_server.wait_for { ready? }
+
+puts my_server.hardware['hdds']
+>> [{'is_main' => true, 'size' => 60}]
+```
+
+
+### Deleting a Server
+
+When you are finished with your server, use the `destroy` method to permanently delete the resource from the provider.  The `destroy` method is available on all models.
+
+```ruby
+puts my_server.destroy
+>> true
+```
+
+
+## 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.
+
+```ruby
+compute = Fog::Compute::OneAndOne.new({
+  :oneandone_api_key => '<API-TOKEN>'
+})
+
+puts compute.collections
+>>
+servers
+images
+shared_storages
+firewalls
+load_balancers
+public_ips
+private_networks
+monitoring_policies
+vpns
+```
+
+Each collection comes equipped with the `create`, `all`, and `get` methods.  You've seen how the `create` method works in our server example above.  `all` will fetch every object of that type from the provider, and generate a model for each of those objects.  Here's an example:
+
+```ruby
+servers = compute.servers.all
+first_server = servers[0]
+
+puts first_server.name
+>> Test Server
+
+puts first_server.status['state']
+>> POWERED_ON
+
+puts first_server.destroy
+>> true
+```
+
+`get` will fetch a single object from the provider and generate a model for the specified object.
+
+```ruby
+bad_server = compute.servers.get('<BAD-SERVER-ID>')
+
+puts bad_server.destroy
+>> true
+```
+
+
+## Mocks
+
+As you might imagine, testing code using Fog can be slow and expensive, constantly turning on and shutting down instances. Mocking allows skipping this overhead by providing an in memory representation of resources as you make requests. Enabling mocking is easy to use: before you run other commands, simply run:
+
+```ruby
+Fog.mock!
+```
+
+Then, proceed as usual. If you run into unimplemented mocks, fog will raise an error.
+
+
+
+## Example App
+
+This simple app creates a load balancer, firewall policy, and server. It then adds the load balancer and firewall policy to the server's initial IP address. You can access a server's initial IP by using the `ips` attribute on the server model, as seen in the example below.
+
+The source code for the Example App can be found <a href='examples/example_app.rb'>here</a>.
+
+```ruby
+require 'fog-oneandone'
+
+compute = Fog::Compute::OneAndOne.new({
+  :oneandone_api_key => '<API-TOKEN>'
+})
+
+# Create Server
+my_server = compute.servers.create(name: 'Example App Server',
+  fixed_instance_id: '65929629F35BBFBA63022008F773F3EB',
+  appliance_id: '6C902E5899CC6F7ED18595EBEB542EE1',
+  datacenter_id: '5091F6D8CBFEF9C26ACE957C652D5D49')
+
+puts 'Creating server...'
+puts my_server.wait_for { ready? }
+
+
+# Create Firewall
+puts "----------"
+rule1 = {
+  'protocol' => 'TCP',
+  'port_from' => 80,
+  'port_to' => 80,
+  'source' => '0.0.0.0'
+}
+
+rules = [rule1]
+
+my_firewall = compute.firewalls.create(name: 'Example App Firewall',
+  rules: rules)
+puts 'Creating Firewall...'
+puts my_firewall.wait_for { ready? }
+
+
+# Create Load Balancer
+puts "----------"
+rule1 = {
+  'protocol' => 'TCP',
+  'port_balancer' => 80,
+  'port_server' => 80,
+  'source' => '0.0.0.0'
+}
+
+rules = [rule1]
+
+my_load_balancer = compute.load_balancers.create(name: 'Example App LB',
+  rules: rules, health_check_test: 'TCP', health_check_interval: 40,
+  persistence: true, persistence_time: 1200, method: 'ROUND_ROBIN',
+  datacenter_id: '5091F6D8CBFEF9C26ACE957C652D5D49')
+puts 'Creating Load Balancer...'
+puts my_load_balancer.wait_for { ready? }
+
+
+# Add Firewall to Server
+puts "----------"
+puts 'Adding Firewall to server IP...'
+my_server.add_firewall(ip_id: my_server.ips[0]['id'],
+  firewall_id: my_firewall.id)
+puts my_server.wait_for { ready? }
+
+
+# Add LB to Server
+puts "----------"
+puts 'Adding Load Balancer to server IP...'
+my_server.add_load_balancer(ip_id: my_server.ips[0]['id'],
+  load_balancer_id: my_load_balancer.id)
+puts my_server.wait_for { ready? }
+
+
+# Cleanup
+puts "----------"
+puts 'Destroying server...'
+puts my_server.destroy
+
+puts "----------"
+puts 'Destroying load balancer...'
+puts my_load_balancer.destroy
+
+puts "----------"
+puts 'Destroying firewall...'
+puts my_firewall.destroy
+```