fkr

A while ago I started on adding support for the german IaaS-provider gridscale to the golang library libretto.

libretto is used to orchestrate various IaaS-solutions such as Azure, AWS, Google Cloud Platform, on-premise solutions such as OpenStack and others. For a complete list take a look at the README.

Until the support for gridscale has been accepted and merged upstream the most current version of the code is at my github page in the feature/add-basic-gridscale-support branch.

If you want to use it, make sure to import libretto from there (checkout via git, with switching to the correct branch in your $GOPATH). If that is too difficult for you, you can also grab the source from my gitea instance. The default branch there is set to the feature/add-basic-gridscale-support branch:

import (
	"https://g.hazardous.org/fkr/libretto"
)

Design of the gridscale API

The API of gridscale is nicely structured. The top-most elements are the ressources - servers (instances) being ressources themselves that can be combined with other ressources via relations.

A typical server looks in json like this. For the sake of not leaking infos I’m not quoting the object_uuids and such.

 "server": {
    "location_country": "de",
    "relations": {
      "networks": [
        {
		  "object_uuid": ...
		  [...]
        }
      ],
      "storages": [
        {
          "object_name": "contract-template Storage",
          "object_uuid": "2fb14084-588b-43da-88a2-240489c6f91a",
        }
      ],
      "isoimages": [],
      "public_ips": [
        {
          "object_uuid": "b3671913-12f4-4015-8357-2269edf3a4a8",
          "ip": "185.102.94.166",
        }
      ]
    },
    "location_uuid": "45ed677b-3702-4b36-be2a-a2eab9827950",
    "name": "name of server",
    "status": "active",
    "object_uuid": ...,
    "cores": 2,
    "power": true,
    "availability_zone": null,
    "usage_in_minutes_cores": 0,
    "usage_in_minutes_memory": 9396,
    "legacy": false,
    "auto_recovery": true,
    "labels": [],
    "memory": 4,
    "location_iata": "fra",
    "location_name": "de/fra",
  }

Each of the endpoints can be crawled and the endpoints below the resources all resemble the same design and methodology. That makes it quite easy to wip up some [generic code] to handle them. I chose the following approach:

• added generic endpoint crawler in util.go
• added specific functions to each of the corresponding elements, example: ip.go or storage.go.
• in storage.go one can see what kind of other functions can be added (GetStorageByUUID())

The README states on how to use them.