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] [Comment Edited] (JCLOUDS-967) Client object doesn't populate public key
Date Mon, 27 Jul 2015 03:33:04 GMT

    [ 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:32 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 significant
amount of work to operate 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 (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?

> 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