It is necessary to specify an empty array in the parameter Settings.Servers of API POST / commonserviceitem for GSLB.

related: #155

v2のドキュメントをdocsディレクトリ配下にまとめる

• os_typeへの追加
• ディスクの修正可否ロジックの修正(現状は修正可能と判定してしまう)

Sample(Low-Level API)の一部のコードが動作しないものを修正する。

実行環境

• macOS 10.12.3
• Go 1.7.4

現状

READMEに書かれているSample(Low-Level API)のコードの実行でコンパイルエラーがでる。

./main.go:81: cannot use hostName (type string) as type *string in assignment
./main.go:82: cannot use password (type string) as type *string in assignment
./main.go:84: cannot use script.Resource.ID (type int64) as type string in argument to diskConf.AddNote

解決案

変更前(81行~84行)

    diskConf.HostName = hostName
    diskConf.Password = password
    diskConf.SSHKey.PublicKey = sshPublicKey
    diskConf.AddNote(script.ID)

変更後(81行~84行)

    diskConf.HostName = &hostName
    diskConf.Password = &password
    diskConf.SSHKey.PublicKey = sshPublicKey
    diskConf.AddNote(string(script.ID))

変更による問題

実行すると83行目のdiskConf.SSHKey.PublicKey = sshPublicKeyで以下のエラーで落ちる

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x2a56]

この行に関係するものをコメントアウトして実行すると84行目のdiskConf.AddNote(string(script.ID))で以下のエラーで落ちる

panic: strconv.ParseInt: parsing "�": invalid syntax

この行に関係するものをコメントアウトして実行すると落ちることなく実行された。
最終的なコード Gist
そこでこれらの項目がきちんと動作するようにする。

TravisCI対応を行う

Overview

Background

現状のlibsacloudには次のような課題がある。

• データモデルの階層が深く、テストなどで手動でデータ生成するのが面倒
• sacloudパッケージのデータモデルで構造体リテラルが利用できない
• IaaS APIクライアントにてcontext/Contextを受け取れないなどGolangらしくない
• saklient互換のFluent APIを採用しているがGolangらしくなくテスト用のインターフェースが作成しにくい面がある
• NULL/空文字の区別がなく、値の未指定なのか空の値をセットしたいのか区別できないことがある

これらを解決するため、libsacloud v2として再設計/再実装する。

Design Goals

• saklient互換性を廃し、よりGolangらしいモダンなスタイルを採用
• Declarative approachにより網羅的な実装と柔軟性を両立させる
• クライアント側にIaaS APIデータモデルに依存しないフラットなデータモデルを提供する
• 現行のbuilderパッケージやutilsパッケージなどで提供している高レベル操作を引き続きサポートする
• API呼び出しで一貫したCRUD方針を採用/実現する(例: CREATE操作の冪等性の担保など)

Non-Goals

• 後方互換性の維持

Features

Layered Models

• モデル層をIaaSと1:1に対応する層(IaaS Layer)とクライアント側に公開するフラットな構造を持つ層(Core Domain Layer)の2層に分ける
• 両層を結ぶマッピングを実装し、相互に変換可能にする
• Core Domain LayerはIaaS Layerが持つモデルの属性に加え、クライアント側に公開すべき操作をメソッドとして実装する。
  (クライアント側が意識する必要のない部分については属性のみを提供する)
• 両層ともコード生成を駆使することでインターフェースレベルで互換性を持たせる

libsacloudのクライアントは基本的にCore Domain Layerのモデルを操作する。
ただし、例外的にIaaS Layerを直接操作する手段も提供する。

Declarative Approach

• モデルの定義にProtocol Buffersを採用し、コード生成でモデルの基本的な実装を行う
• 特に前述のモデル実装は同様のメソッドが多数のモデルに共通して必要となる場面が多いため、コード生成を基本とする
• 高レベル操作を手動で実装する部分もあるため、コード生成はGeneration Gapを考慮する

IaaS API

• リクエスト/レスポンス共にパラメータをDeclarative Approachで実装する
• CRUD操作それぞれのパラメータを個別に定義する
  (現行はIaaSのデータモデルを直接指定する必要があり、更新可否や必須の値の判断などが困難)
• CRUDでの冪等性のサポート
  https://github.com/Azure/azure-cli/blob/dev/doc/command_guidelines.md#standard-command-types
  • 現行のIaaS APIではslugが存在しないため、CREATE時はNameなどを擬似slugとして扱う

GET /auth-status APIコールで以下のエラーが発生する。

json: cannot unmarshal number into Go struct field Account.ID of type string

戻り値のデータ型が変更された可能性あり。

(a part of #155)

Overview

Declarative Approachの構成要素を検討する。

Goals

• どの部分を宣言的にするかを明確にする
• 使用するツール類を選択する
• 典型的な開発フローを確立する

Non-Goals

• 実行可能なレベルでの実装

Input/Output

• Input: #155
• Output: design/tools/配下にドキュメントを追加

Details

👉 Scope to use Declarative Approach

• IaaSレイヤのモデル定義
• IaaS APIクライアント
• Core Domainレイヤのモデル定義

🤔 How to implements

• Protocol Buffers + protoc + custom plugin
  (includes protoc-gen-swagger)
• JSON Schema + generator
• Goで実装した自前のDSL(like a usacloud's approach)

TODO

• ツール類の比較/選定
• ワークフロードキュメントの作成

レプリカ(slave)作成後、コピー中のまま作成が完了しない

golintでのエラーに全て対応する。
v1.0.0リリースに合わせ、後方互換をなくす変更になる可能性もあるが、対応する。

(from sacloud-archives/libsacloud-v2#37)

いくつかのデータ型がv1と互換性がなく、json.Unmarshalの失敗などが原因でv2で作成されたリソースをv1から参照できないことがある

例:

• sakuracloud_exporter
• usacloud
• terraform

v1/v2両面から対応を検討しておく。

API自体の基本的な使い方などはGodocで整備するつもりのため、
README.mdには簡単な概要説明や他プロジェクトへの組み込み方法などを中心に記載する。

Add /internet/:internetid/subnetAPIs(POST/PUT/DELETE) to the api.InternetAPI

see http://cloud-news.sakura.ad.jp/2016/10/06/vpcrouter-log/

Motivation

現在はbuilderパッケージ配下にFrom...のような関数群がぶら下がっているが、
builderパッケージの対象がサーバー/ディスク以外に拡大した場合に対応できない。

Proposal

操作対象のリソース名を関数名プレフィックスとする。
サーバーの場合Server...など。

現行の仕組みだと待ち時間の設定次第ではタイムアウト処理が発火しない。

src:

time.Tickとtime.Afterを組み合わせる方法に修正する。

未実装のAPIのうち、利用頻度が高そうなものを追加実装する

• GET/auth-status(認証状態の取得)
• GET/bill*(請求関連状態)

see http://cloud-news.sakura.ad.jp/webaccel/api/

タグを利用したメタデータの指定を行えるようにする。

利用イメージ:

	s := api.Server.Read(id)

	// メタデータの追加
	meta := &sacloud.Metadata{
		Namespace: "foo",
		Label:     "bar",
		Value:     "baz",
	}

	s.AddMetadata(meta)
	// s.Tags = ["foo:bar=baz"]

libsacloudクライアント側でテストを書く際にモデルの値の記載が行いにくい。
なるべく構造体リテラルで記載できるような方法を検討する。

スイッチを扱う例

As-Is:

sw := sacloud.Switch{}
sw.ID = 999
sw.Name = "dummy"

To-Be:

sw := sacloud.Switch {
    ID: 999,
    Name: "dummy",
}

Pullリクまで作れなくてごめんなさい。
Issueを立てさせていただきます。

2018/08/27 19:32:43 [libsacloud:Client#request] method : "PUT" , url : https://secure.sakura.ad.jp/cloud/zone/is1b/api/cloud/1.1/disk/<リソースID>/install ,
body : {
        "Description": "",
        "SourceArchive": {
                "ID": <アーカイブリソースID>,
                "Description": "",
                "Tags": null,
                "Icon": null
        },
        "Icon": null,
        "Tags": null,
        "Storage": {
                "DiskPlan": {
                        "Description": ""
                }
        }
}

以下の形式で渡す必要があると思います。

{"Disk":{"SourceArchive":{"ID":<アーカイブリソースID>}}}

渡しているjsonがDiskの中にある必要があると思われます。

このあたりで、適当な構造体でDiskが付くようにすれば
問題なくArchiveからのコピーが成功しました。
https://github.com/sacloud/usacloud/blob/master/vendor/github.com/sacloud/libsacloud/api/disk.go#L81

see http://cloud-news.sakura.ad.jp/2016/08/10/shared-network-dhcp/

(from sacloud-archives/libsacloud-v2#35)

現在のfakeドライバーはインメモリでデータを保持している。
このためプロセス終了時にデータは破棄される。

これをローカルファイルをバックエンドとした永続化に対応することによりusacloudやterraformなどでのユーザーによる開発/テストを容易にする。

usacloudやterraform-provider-sakuracloudから高レベル操作を切り出してlibsacloudに追加する。

for fix this issue

さくらのクラウドAPIが提供するモデルについては対応する構造体を用意する。

• サーバ関連
• ディスク関連
• スイッチ関連
• アーカイブ関連
• ISOイメージ(CDROM)関連
• ブリッジ関連
• ルーター関連
• インターフェース関連
• アプライアンス関連
  • ロードバランサ
  • VPCルータ
• 共通サービス契約関連
  • GSLB
  • さくらのDNS
  • シンプル監視
• アイコン関連
• スクリプト関連
• SSHキー関連
• 設備関連
• 商品関連
• ユーザー・アカウント関連

データ型の統合/整理

see http://cloud-news.sakura.ad.jp/2016/10/06/controlpanel_update-17/

低レベルAPI

• アーカイブ
• 認証情報(#205)
• 自動バックアップ(#225)
• 請求(#236)
• ブリッジ
• クーポン(#237)
• ISOイメージ
• データベースアプライアンス(#239)
• ディスク
• DNS(#227)
• GSLB
• アイコン(#233)
• インターフェース
• スイッチ+ルータ
• IPv4アドレス(#247)
• IPv6ネットワーク(#248)
• IPv6アドレス(#249)
• ライセンス(#242)
• ロードバランサ
• モバイルゲートウェイ(#253)
• ニュースフィード(メンテナンス情報)(#257)
• NFS
• スタートアップスクリプト
• パケットフィルタ
• 専有ホスト(#243)
• 商品関連(productXXX)(#243 , #244)
• 価格表(public/price)(#245)
• エンハンスドロードバランサ
• リージョン(#235)
• シンプル監視(#228)
• SIM(fakeドライバ)(#253)
• 公開鍵(#234)
• サーバ(#280など)
• サブネット
• スイッチ
• VPCルータ
• ゾーン
• ウェブアクセラレータ(#246)

高レベルAPI

• 検索ヘルパー(#264, #266)
• 既存パッケージ構造の見直し(builder, util)(#272, #278, #279, #281, #284, #288)

以下機能を含むMakefileを整備する。

• build関連( build / clean )
• godep関連(save / restore)
• Dockerコンテナでのビルド(USE_CONTAINER環境変数での切り替え)

以下コミットにて対応済み
71dd269

現象

石狩第1ゾーンのみ、スイッチを接続済みのブリッジをAPIで参照するとJSON変換エラーとなる。

原因

以下のようにbridge.Switches[0].IDが文字列となる模様。

{
    "Bridges": [
        {
            "ID": xxxxxxxxxxxx,
            "Info": {
                "HybridConnection": {
                    // 省略
                },
                "Switches": [
                    {
                        "ID": "xxxxxxxxxxxx",
                        // 省略
                    }
                ]
            },

現時点ではAPIを直接コールしても数値型となっているため、さくらのクラウド側の一時的な問題だったのかも。

see http://cloud-news.sakura.ad.jp/database/

PUTではなくDELETEが正しい

https://github.com/yamamoto-febc/libsacloud/blob/master/api/archive.go#L42