You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by "Adrian Bravo (JIRA)" <ji...@apache.org> on 2015/07/27 05:30:04 UTC

[jira] [Comment Edited] (JCLOUDS-967) Client object doesn't populate public key

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

Adrian Bravo edited comment on JCLOUDS-967 at 7/27/15 3:29 AM:
---------------------------------------------------------------

Looking a bit more into the problem it seems that the library specifies X-Chef-Version as 0.10.8 (see https://github.com/jclouds/jclouds/blob/master/apis/chef/src/main/java/org/jclouds/chef/ChefApiMetadata.java). 0.10.8 was released December 16, 2011, after that it came 10.x, 11.x, and then 12.x (https://rubygems.org/gems/chef/versions). In theory the chef server will respond with the format specified by the client in X-Chef-Version, but as far as I can test (shown in the examples above) it seems that the newer chef servers do not respond with the old format anymore. It looks like the library would need a major overhaul to work with the most recent versions of chef, that in addition to different response formats also come with new endpoints to access more data. Is there a formal statement regarding which versions of chef jclouds aims to support?


was (Author: adrianbn):
Looking a bit more into the problem it seems that the library specifies X-Chef-Version as 0.10.8! 0.10.8 was released December 16, 2011, after that it came 10.x, 11.x, and then 12.x (https://rubygems.org/gems/chef/versions). In theory the chef server will respond with the format specified by the client in X-Chef-Version, but as far as I can test (shown in the examples above) it seems that the newer chef servers do not respond with the old format anymore. It looks like the library would need a major overhaul to work with the most recent versions of chef, that in addition to different response formats also come with new endpoints to access more data. Is there a formal statement regarding which versions of chef jclouds aims to support?

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