luxolus
/
open-vault
2
0
Fork 0
Code Issues 1 Pull Requests Releases Activity
open-vault/vendor/github.com/joyent/triton-go/CHANGELOG.md

101 lines
4.0 KiB
Markdown
Raw Normal View History

Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
## Unreleased
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
## 1.3.1 (April 27 2018)
Update triton version
2018-02-12 23:27:18 +00:00
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
- client: Fixing an issue where private Triton installations were marked as invalid DC [#152]
## 1.3.0 (April 17 2018)
- identity/roles: Add support for SetRoleTags [#112]
- Add support for Triton Service Groups endpoint [#148]
## 1.2.0 (March 20 2018)
- compute/instance: Instance Deletion status now included in the GET instance response [#138]
## 1.1.1 (March 13 2018)
- client: Adding the rbac user support to the SSHAgentSigner [BUG!]
## 1.1.0 (March 13 2018)
- client: Add support for Manta RBAC http signatures
## 1.0.0 (February 28 2018)
- client: Add support for querystring in client/ExecuteRequestRaw [#121]
- client: Introduce SetHeader for overriding API request header [#125]
- compute/instances: Add support for passing a list of tags to filter List instances [#116]
- compute/instances: Add support for getting a count of current instances from the CloudAPI [#119]
- compute/instances: Add ability to support name-prefix [#129]
- compute/instances: Add support for Instance Deletion Protection [#131]
- identity/user: Add support for ChangeUserPassword [#111]
- expose GetTritonEnv as a root level func [#126]
## 0.9.0 (January 23 2018)
Update triton version
2018-02-12 23:27:18 +00:00
**Please Note:** This is a precursor release to marking triton-go as 1.0.0. We are going to wait and fix any bugs that occur from this large set of changes that has happened since 0.5.2
- Add support for managing volumes in Triton [#100]
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
- identity/policies: Add support for managing policies in Triton [#86]
Update triton version
2018-02-12 23:27:18 +00:00
- addition of triton-go errors package to expose unwrapping of internal errors
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
- Migration from hashicorp/errwrap to pkg/errors
- Using path.Join() for URL structures rather than fmt.Sprintf()
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
## 0.5.2 (December 28 2017)
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
- Standardise the API SSH Signers input casing and naming
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
## 0.5.1 (December 28 2017)
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
- Include leading '/' when working with SSH Agent signers
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
## 0.5.0 (December 28 2017)
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
- Add support for RBAC in triton-go [#82]
This is a breaking change. No longer do we pass individual parameters to the SSH Signer funcs, but we now pass an input Struct. This will guard from from additional parameter changes in the future.
We also now add support for using `SDC_*` and `TRITON_*` env vars when working with the Default agent signer
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
## 0.4.2 (December 22 2017)
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
- Fixing a panic when the user loses network connectivity when making a GET request to instance [#81]
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
## 0.4.1 (December 15 2017)
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
- Clean up the handling of directory sanitization. Use abs paths everywhere [#79]
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
## 0.4.0 (December 15 2017)
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
- Fix an issue where Manta HEAD requests do not return an error resp body [#77]
- Add support for recursively creating child directories [#78]
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
## 0.3.0 (December 14 2017)
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
- Introduce CloudAPI's ListRulesMachines under networking
- Enable HTTP KeepAlives by default in the client. 15s idle timeout, 2x
connections per host, total of 10x connections per client.
- Expose an optional Headers attribute to clients to allow them to customize
HTTP headers when making Object requests.
- Fix a bug in Directory ListIndex [#69](https://github.com/joyent/issues/69)
- Inputs to Object inputs have been relaxed to `io.Reader` (formerly a
`io.ReadSeeker`) [#73](https://github.com/joyent/issues/73).
- Add support for ForceDelete of all children of a directory [#71](https://github.com/joyent/issues/71)
- storage: Introduce `Objects.GetInfo` and `Objects.IsDir` using HEAD requests [#74](https://github.com/joyent/triton-go/issues/74)
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
## 0.2.1 (November 8 2017)
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
- Fixing a bug where CreateUser and UpdateUser didn't return the UserID
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
## 0.2.0 (November 7 2017)
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
- Introduce CloudAPI's Ping under compute
- Introduce CloudAPI's RebootMachine under compute instances
- Introduce CloudAPI's ListUsers, GetUser, CreateUser, UpdateUser and DeleteUser under identity package
- Introduce CloudAPI's ListMachineSnapshots, GetMachineSnapshot, CreateSnapshot, DeleteMachineSnapshot and StartMachineFromSnapshot under compute package
- tools: Introduce unit testing and scripts for linting, etc.
- bug: Fix the `compute.ListMachineRules` endpoint
Bump Deps (#4868) * bump deps * revert script changes * adding govendor miss
2018-07-06 16:09:34 +00:00
## 0.1.0 (November 2 2017)
Adding Manta Storage Backend (#3720) This PR adds a new Storage Backend for Triton's Object Storage - Manta ``` make testacc TEST=./physical/manta ==> Checking that code complies with gofmt requirements... ==> Checking that build is using go version >= 1.9.1... go generate VAULT_ACC=1 go test -tags='vault' ./physical/manta -v -timeout 45m === RUN TestMantaBackend --- PASS: TestMantaBackend (61.18s) PASS ok github.com/hashicorp/vault/physical/manta 61.210s ``` Manta behaves differently to how S3 works - it has no such concepts of Buckets - it is merely a filesystem style object store Therefore, we have chosen the approach of when writing a secret `foo` it will actually map (on disk) as foo/.vault_value The reason for this is because if we write the secret `foo/bar` and then try and Delete a key using the name `foo` then Manta will complain that the folder is not empty because `foo/bar` exists. Therefore, `foo/bar` is written as `foo/bar/.vault_value` The value of the key is *always* written to a directory tree of the name and put in a `.vault_value` file.
2018-02-12 23:22:41 +00:00
- Initial release of a versioned SDK