This is an experimental external BOSH CPI for OpenStack.

This is NOT presently a production ready CPI. This is a work in progress. It is suitable for experimentation and may not become supported in the future.

This is NOT an official BOSH OpenStack CPI, and it is NOT intended to be compatible with the official one (the cloud properties names differ).

The official and supported BOSH OpenStack CPI can be found at https://github.com/cloudfoundry/bosh/tree/master/bosh_openstack_cpi.

This CPI can be deployed using the BOSH OpenStack CPI release.

Using the standard go get:

$ go get github.com/frodenas/bosh-openstack-cpi/main

Create a configuration file:

{
  "openstack": {
    "identity_endpoint": "http://identity-endpoint.example.com/v2.0",
    "username": "username",
    "password": "password",
    "tenant_name": "tenant",
    "region": "region",
    "default_keypair": "keyname",
    "default_security_groups": [
      "security_group"
    ],
    "disable_config_drive": false,
    "disable_neutron": false,
    "ignore_server_availability_zone": false
  },
  "actions": {
    "agent": {
      "mbus": "https://mbus:[email protected]:6868",
      "ntp": [
        "0.north-america.pool.ntp.org"
      ],
      "blobstore": {
        "type": "local",
        "options": {}
      }
    },
    "registry": {
      "protocol": "http",
      "host": "127.0.0.1",
      "port": 25777,
      "username": "admin",
      "password": "admin",
      "tls": {
        "_comment": "TLS options only apply when using HTTPS protocol",
        "insecure_skip_verify": true,
        "certfile": "/path/to/public.pem",
        "keyfile": "/path/to/private.pem",
        "cacertfile": "/path/to/ca.pem"
      }
    }
  }
}

Run the cpi using the previously created configuration file:

$ echo "{\"method\": \"method_name\", \"arguments\": []}" | cpi -configFile="/path/to/configuration_file.json"

The BOSH OpenStack CPI supports these BOSH Networks Types:

These options are specified under cloud_properties at the networks section of a BOSH deployment manifest and are only valid for dynamic and manual networks:

These options are specified under cloud_properties at the resource_pools section of a BOSH deployment manifest:

These are the list of supported scheduler_hints options:

These options are specified under cloud_properties at the disk_pools section of a BOSH deployment manifest:

This is an example of how Google Compute Engine CPI specific properties are used in a BOSH deployment manifest:

---
name: example
director_uuid: 38ce80c3-e9e9-4aac-ba61-97c676631b91

...

networks:
  - name: private
    type: dynamic
    dns:
      - 8.8.8.8
      - 8.8.4.4
    cloud_properties:
      network: default
      security_groups:
        - bosh

  - name: public
    type: vip
    cloud_properties: {}
...

resource_pools:
  - name: vms
    network: private
    stemcell:
      name: bosh-openstack-kvm-ubuntu-trusty-go_agent
      version: latest
    cloud_properties:
      flavor: m1.medium
      availability_zone: az1
      keypair: bosh
      scheduler_hints:
        different_host:
          - a0cf03a5-d921-4877-bb5c-86d26cf818e1
          - 8c19174f-4220-44f0-824a-cd1eeef10287
...

disk_pools:
  - name: disks
    disk_size: 32_768
    cloud_properties:
      volume_type: ssd
      availability_zone: az1
...

In the spirit of free software, everyone is encouraged to help improve this project.

Here are some ways you can contribute:

• by using alpha, beta, and prerelease versions
• by reporting bugs
• by suggesting new features
• by writing or editing documentation
• by writing specifications
• by writing code (no patch is too small: fix typos, add comments, clean up inconsistent whitespace)
• by refactoring code
• by closing issues
• by reviewing patches

We use the GitHub issue tracker to track bugs and features. Before submitting a bug report or feature request, check to make sure it hasn't already been submitted. You can indicate support for an existing issue by voting it up. When submitting a bug report, please include a Gist that includes a stack trace and any details that may be necessary to reproduce the bug, including your gem version, Ruby version, and operating system. Ideally, a bug report should include a pull request with failing specs.

1. Fork the project.
2. Create a topic branch.
3. Implement your feature or bug fix.
4. Commit and push your changes.
5. Submit a pull request.

Copyright (c) 2015 Ferran Rodenas. See LICENSE for details.