[
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)
