jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Bravo (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCLOUDS-967) Client object doesn't populate public key
Date Mon, 27 Jul 2015 18:46:05 GMT

    [ https://issues.apache.org/jira/browse/JCLOUDS-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643206#comment-14643206
] 

Adrian Bravo commented on JCLOUDS-967:
--------------------------------------

Hi Ignasi,

I created an initial PR for discussion with the model update (https://github.com/jclouds/jclouds/pull/828).


Regarding the apiVersion, my point was that Chef Server 12 seems to respond with the same
attributes for the getClient call regardless of the apiVersion specified (tested 12.4.1, 11.12.8,
and 0.10.8), which is weird. Additionally, the tests pass regardless of not having a public
key defined as the model will simply ignore additional fields in the JSON response, so it
is theoretically possible that some other API calls are currently missing attributes. I guess
that what makes this a bit messy is the different behaviours with different apiVersions, but
I like the solution proposed in JCLOUDS-717.

The amount of work involved would come from implementing the new org and client endpoints,
but if those are implemented already in enterprisechef and it is a matter of moving them over,
then I guess that's a much smaller effort.

> Client object doesn't populate public key
> -----------------------------------------
>
>                 Key: JCLOUDS-967
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-967
>             Project: jclouds
>          Issue Type: Bug
>          Components: jclouds-chef
>    Affects Versions: 2.0.0, 1.9.0
>            Reporter: Adrian Bravo
>
> Chef's API for version 12 returns a different set of values that those shown on the chef
api documentation and expected by jclouds. For example, jclouds' ChefApi.getClient("chef-client.example.com")
produces the call below:
> {code}
> GET https://192.168.242.169:443/organizations/mytestorg/clients/chef-client.example.com
> {code}
> Returns the following:
> {code}
> {"public_key":"-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoNgWKe36NI0aLIaRxj2i\nF3OgVNnrW0A7I6x7IMo5MbKZQIU0WIMYUdNElOGI8EuSOvocSfetfOGAwTNTNOeB\ndWIv05/WeMzgMNxtdmsiKqW/1T45Z6Q+h3dxDJGr+PM9gQ56RGnytZ5IaJ7c/AJH\n+Vm1Loe8VFk4SZWOmrD0RxfIHMGDpkwfVhZsT76IdS9cDnm2bhxadHx0qiG6wyl5\nkheTFyObmiMl+KjEQi8Ws8+JlmFdrQhJRcvNeFR6CXuF+8sgr3euvBzFfl3GCdhM\n0jFMBp1GE6wpgz7BgMhMYFuUWLYqub094PgqcmAs5SUTzTK8NNNscp563Ol/2vMl\nPQIDAQAB\n-----END
PUBLIC KEY-----\n","name":"chef-client.example.com","clientname":"chef-client.example.com","validator":false,"orgname":"mytestorg","json_class":"Chef::ApiClient","chef_type":"client"}
> {code}
> Just for reference, this is the same call made by knife client show <client_name>
as shown below:
> {code}
> adrian.bravo@ABRAVO-01:~$ knife client show chef-client.example.com
> admin:      false
> chef_type:  client
> json_class: Chef::ApiClient
> name:       chef-client.example.com
> public_key: -----BEGIN PUBLIC KEY-----
> MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoNgWKe36NI0aLIaRxj2i
> F3OgVNnrW0A7I6x7IMo5MbKZQIU0WIMYUdNElOGI8EuSOvocSfetfOGAwTNTNOeB
> dWIv05/WeMzgMNxtdmsiKqW/1T45Z6Q+h3dxDJGr+PM9gQ56RGnytZ5IaJ7c/AJH
> +Vm1Loe8VFk4SZWOmrD0RxfIHMGDpkwfVhZsT76IdS9cDnm2bhxadHx0qiG6wyl5
> kheTFyObmiMl+KjEQi8Ws8+JlmFdrQhJRcvNeFR6CXuF+8sgr3euvBzFfl3GCdhM
> 0jFMBp1GE6wpgz7BgMhMYFuUWLYqub094PgqcmAs5SUTzTK8NNNscp563Ol/2vMl
> PQIDAQAB
> -----END PUBLIC KEY-----
> validator:  false
> {code}
> The code in jclouds Client class expects it to come back with a private key and a certificate
field instead. Those fields remain null after the call above, but there is no way to access
the public key.
> I've added the public key attribute to Client and updated the rest of the class accordingly
to be able to retrieve the public key after such a call without removing the private key and
certificate fields that are useful for other calls (and maybe older versions). The code works
and the current tests pass. I would like to submit a PR with the fix as soon as I have some
tests written. I would appreciate some help pointing out where those tests should live and
which type of tests are you expecting for a minor fix like this (added an attribute, a getter,
and adapted the class to take it into account).
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message