[
https://issues.apache.org/jira/browse/JCLOUDS-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14642294#comment-14642294
]
Ignasi Barrera commented on JCLOUDS-967:
----------------------------------------
AFAIK the new endpoints are those that previously were only a available in
Hosted Chef. For that legacy reason they exist in the
"providers/enterprisechef" provider. Now that there is a single product both
chef and enterprisechef could be joined in a single api. There is JCLOUDS-717
to track this. (Note that there is partial organizarion and user support but
not ACLs, etc, because that is still not documented).
Regarding Chef 12, all live tests are executed on a weekly basis against a
Hosted Chef instance, so I'd say the current api works pretty well with Chef
12. Sure there will be model changes to be done to be 100% compatible, but not
a major refactor I hope.
We could definitely update the default version (users can change that at
runtime using the {{apiVersion}} method of the ContextBuilder when building the
context). Mind changing it in a separate commit (but in the same pull request)
so I can cherry-pick only the model change to the 1.9 branch? This way we keep
our api backward compatible in 1.9 but change the default in 2.0.
Thanks for taking care of this!
> 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)
