Thanks Jim!
I'll review the PR today/tomorrow.
Meanwhile, I've sent you a patch that fixes the build and checkstyle
violations. Feel free to add it to the PR! :)
On 30 October 2017 at 22:36, Jim Spring wrote:
> Added PR —
>
> https://github.com/jclouds/jclouds-labs/pull/416
>
> Currently failing
Added PR —
https://github.com/jclouds/jclouds-labs/pull/416
Currently failing with no violations listed —
https://jclouds.ci.cloudbees.com/job/jclouds-labs-pull-requests/1850/org.apache.jclouds.labs$azurecompute-arm/violations/
I’ve added notes regarding the status in the PR and a couple of thi
Thanks Jim. The plan LGTM.
For the tests in (3), we could do it in two steps. A first impl that
relies on an existing storage account, and then we can see if we
really need to add the functionality to create the storage accounts
dynamically. (Is there any planned ETA for the storage account APIs t
An update —
I’ll probably finish mock tests tomorrow and issue the PR outlined in (1).
That said, there are two API calls that will be stubbed out in tests:
- Update Certificate Policy based off of a certificate version
- Azure is giving an error that modifying the policy of a versioned
certifica
Sounds like a good plan.
Regarding the tests, yes, mock tests are important. The implement "the
contract" between jclouds and the "provider API docs". They are very
useful to early detect incorrect json mappings, serialization issues,
verify pagination, redirections, authentication, and other stuf
@Ignasi, @Andrea -
Here is my proposal - the PR should be done in sections. I would propose
three:
1. A PR implementing Vault, Key, Secret, and Certificate operations.
2. A PR implementing decrypt/encrypt/wrap/unwrap/sign/verify operations.
3. A PR implementing Storage Account and SAS operati
FYI Jim has already started fixing some issue at
https://github.com/andreaturli/jclouds-labs/pull/9/files
I'd suggest to get my implementation in my andreaturli:feature/vault-api
branch and open a PR against jclouds/jclouds-labs.
Andrea
On Mon, Oct 23, 2017 at 10:18 AM, Ignasi Barrera wrote:
>
> How much of the KeyVault api should we implement? I’ve started creating
> actual tests for the Key operations and will be prioritizing the list in
> order that I’ll be adding them.
I don't know how complex the API is, but it is quite straightforward
to implement APIs in jclouds once you have
One more question -
How much of the KeyVault api should we implement? I’ve started creating actual
tests for the Key operations and will be prioritizing the list in order that
I’ll be adding them.
I’ll try and do a PR per set (if you don’t mind Andrea).
I’ll try and catch you guys on IRC to
Andrea -
Take a look at the PR I did against your feature/vault-api branch. I’m
extending the tests now.
I’ll do a PR once I get all the key tests implemented.
Would it make sense to find some time to chat? Or are you ok with me
moving forward on extending things?
-jim
On October 17, 2017 a
Thanks Jim!
An additional property makes sense for liveTests as well.
Direct use of Azure AD GraphApi looks a bit hard to me, so let's make
jclouds accept an extra parameter that will allow at least to specify an
already existing objectID.
wdyt?
On Tue, Oct 17, 2017 at 10:33 AM, Ignasi Barrera w
Thanks Jim!
I think it makes sense for the live tests to get the value configured
as a property.
If someone wants to directly use the KeyVault API, I think it makes
sense to have the objectId as a required parameter (as it is now). I
don't see an immediate need to auto-discover it or to have it
c
Andrea -
A PR is present plumbing in the ObjectID. I’ll be looking at fleshing out
the tests more today.
-jim
On October 16, 2017 at 9:48:39 AM, Jim Spring (jmspr...@gmail.com) wrote:
Andrea, Ignasi -
I’ve managed to figure out the authentication issue Andrea was running into
with his KeyVau
13 matches
Mail list logo
