You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Andrey Rusev <a....@mishmash.io> on 2018/02/25 11:00:53 UTC
Assist with new cloud provider API
Hello all,
We did a very quick implementation of a cloud provider we use ( https://www.hetzner.com/cloud ) and I thought we might share it so that other people can use it too. And then I thought we better do it properly. As none of us is really an expert on jclouds internals, plans, etc I'd like some help with figuring out what would be the right way to plug it in, use all available abstractions so that the api is as transparent as any other and so on.
For example - at the moment we have a ComputeServiceAdapter that only does the basics, but it feels to me a lot of functionality is left out. Unless you unwrap() the lower-level API or add some metadata key-values (that might 'brake' comparators or something else?).
If anyone is happy to help with some guidance please let me know!
Also - where do I share the code? Load it somewhere on github? Or with a link to download?
Cheers,
Andrey
Re: Assist with new cloud provider API
Posted by Andrey Rusev <a....@mishmash.io>.
Cool, thanks Valentin! :)
Just did a veeery quick share, plus, added some of the issues to the README:
https://github.com/mishmash-io/jclouds-labs/tree/master/hetzner
I think it's kind of too early to submit a pull request though...
---- On Sun, 25 Feb 2018 13:21:20 +0200 Valentin AItken <va...@nalisbg.com> wrote ----
> Hi Andrey,
>
> Glad to see more contributors in jclouds!
>
> You did successfully the "0." step from the contribution guide [1]
>
> Regarding reviewing and discussing the code, I suggest you commit it in
> jclouds-labs [2], fork it, push it and submit a Pull Request.
> I find PR discussions very benefitial.
>
> Valentin.
>
> [1] https://cwiki.apache.org/confluence/display/JCLOUDS/How+to+Contribu
> te
> [2] https://github.com/jclouds/jclouds-labs
>
>
> В 13:00 +0200 на 25.02.2018 (нд), Andrey Rusev написа:
> > Hello all,
> >
> > We did a very quick implementation of a cloud provider we use ( https
> > ://www.hetzner.com/cloud ) and I thought we might share it so that
> > other people can use it too. And then I thought we better do it
> > properly. As none of us is really an expert on jclouds internals,
> > plans, etc I'd like some help with figuring out what would be the
> > right way to plug it in, use all available abstractions so that the
> > api is as transparent as any other and so on.
> >
> > For example - at the moment we have a ComputeServiceAdapter that only
> > does the basics, but it feels to me a lot of functionality is left
> > out. Unless you unwrap() the lower-level API or add some metadata
> > key-values (that might 'brake' comparators or something else?).
> >
> > If anyone is happy to help with some guidance please let me know!
> >
> > Also - where do I share the code? Load it somewhere on github? Or
> > with a link to download?
> >
> > Cheers,
> > Andrey
> >
> >
> >
> >
>
Re: Assist with new cloud provider API
Posted by Valentin AItken <va...@nalisbg.com>.
Hi Andrey,
Glad to see more contributors in jclouds!
You did successfully the "0." step from the contribution guide [1]
Regarding reviewing and discussing the code, I suggest you commit it in
jclouds-labs [2], fork it, push it and submit a Pull Request.
I find PR discussions very benefitial.
Valentin.
[1] https://cwiki.apache.org/confluence/display/JCLOUDS/How+to+Contribu
te
[2] https://github.com/jclouds/jclouds-labs
В 13:00 +0200 на 25.02.2018 (нд), Andrey Rusev написа:
> Hello all,
>
> We did a very quick implementation of a cloud provider we use ( https
> ://www.hetzner.com/cloud ) and I thought we might share it so that
> other people can use it too. And then I thought we better do it
> properly. As none of us is really an expert on jclouds internals,
> plans, etc I'd like some help with figuring out what would be the
> right way to plug it in, use all available abstractions so that the
> api is as transparent as any other and so on.
>
> For example - at the moment we have a ComputeServiceAdapter that only
> does the basics, but it feels to me a lot of functionality is left
> out. Unless you unwrap() the lower-level API or add some metadata
> key-values (that might 'brake' comparators or something else?).
>
> If anyone is happy to help with some guidance please let me know!
>
> Also - where do I share the code? Load it somewhere on github? Or
> with a link to download?
>
> Cheers,
> Andrey
>
>
>
>
Re: Assist with new cloud provider API
Posted by Andrea Turli <an...@gmail.com>.
Andrey,
I think you got the idea!
Have a look at https://github.com/jclouds/jclouds-labs/commits/2.0.x/packet
particularly at Commits on Feb 2, 2017: those are a good example of
what Ignasi was explaining to you before.
HTH,
Andrea
On Tue, Feb 27, 2018 at 7:43 AM, Andrey Rusev <a....@mishmashio.com> wrote:
> OK, I think I got, let me just check - even though we have a lot of code already, I can break it into smaller parts and introduce it gradually. Starting from the provider's side and moving towards jclouds abstractions. And a new PR at every step. Even though the code, initially, will be compilable and testable, but not really useful beyond that. Correct?
>
> ---- On Mon, 26 Feb 2018 08:42:38 +0200 nacx@apache.org wrote ----
>
> As Valentin suggested the best way to contribute is to open a PR to the
> jclouds-labs repo.
>
> The code does not need to be complete. Actually it is better to submit
> small PRs to facilitate the reviews and to allow you to build a solid
> foundation on top of which you can build the portable abstractions.
>
> I'd recommend to open a PR early. A good path of PRs for quicker and
> smoother merges (but not mandatory, feel free to open the PRs you want):
>
> * Metadata classes, basic error/retry handlers and one initial smal API,
> with mock and live tests.
> * Other APIs with tests (the bigger the PR the more it takes to review and
> fix).
> * Compute skeleton and the transformation functions from the provider model
> to the jclouds one.
> * Basic implementation of the adapter and provider-specific option classes.
> * Details and implementatiom of the compute service live tests (our
> contract for all providers).
>
>
> I'll be happy to help and provide guidance on the jclouds code to get the
> PRs merged. Feel free to also join the IRC or Slack channel and talk to us
> there: http://jclouds.apache.org/community/
>
>
> I.
>
>
> On Feb 25, 2018 1:24 PM, "Andrey Rusev" <a....@mishmash.io> wrote:
>
> Cool, thanks Valentin! :)
>
> Just did a veeery quick share, plus, added some of the issues to the README:
>
> https://github.com/mishmash-io/jclouds-labs/tree/master/hetzner
>
> I think it's kind of too early to submit a pull request though...
>
>
> ---- On Sun, 25 Feb 2018 13:21:20 +0200 Valentin AItken <
> valentin@nalisbg.com> wrote ----
>> Hi Andrey,
>>
>> Glad to see more contributors in jclouds!
>>
>> You did successfully the "0." step from the contribution guide [1]
>>
>> Regarding reviewing and discussing the code, I suggest you commit it in
>> jclouds-labs [2], fork it, push it and submit a Pull Request.
>> I find PR discussions very benefitial.
>>
>> Valentin.
>>
>> [1] https://cwiki.apache.org/confluence/display/JCLOUDS/How+to+Contribu
>> te
>> [2] https://github.com/jclouds/jclouds-labs
>>
>>
>> В 13:00 +0200 на 25.02.2018 (нд), Andrey Rusev написа:
>> > Hello all,
>> >
>> > We did a very quick implementation of a cloud provider we use ( https
>> > ://www.hetzner.com/cloud ) and I thought we might share it so that
>> > other people can use it too. And then I thought we better do it
>> > properly. As none of us is really an expert on jclouds internals,
>> > plans, etc I'd like some help with figuring out what would be the
>> > right way to plug it in, use all available abstractions so that the
>> > api is as transparent as any other and so on.
>> >
>> > For example - at the moment we have a ComputeServiceAdapter that only
>> > does the basics, but it feels to me a lot of functionality is left
>> > out. Unless you unwrap() the lower-level API or add some metadata
>> > key-values (that might 'brake' comparators or something else?).
>> >
>> > If anyone is happy to help with some guidance please let me know!
>> >
>> > Also - where do I share the code? Load it somewhere on github? Or
>> > with a link to download?
>> >
>> > Cheers,
>> > Andrey
>> >
>> >
>> >
>> >
>>
Re: Assist with new cloud provider API
Posted by Andrey Rusev <a....@mishmashio.com>.
OK, I think I got, let me just check - even though we have a lot of code already, I can break it into smaller parts and introduce it gradually. Starting from the provider's side and moving towards jclouds abstractions. And a new PR at every step. Even though the code, initially, will be compilable and testable, but not really useful beyond that. Correct?
---- On Mon, 26 Feb 2018 08:42:38 +0200 nacx@apache.org wrote ----
As Valentin suggested the best way to contribute is to open a PR to the
jclouds-labs repo.
The code does not need to be complete. Actually it is better to submit
small PRs to facilitate the reviews and to allow you to build a solid
foundation on top of which you can build the portable abstractions.
I'd recommend to open a PR early. A good path of PRs for quicker and
smoother merges (but not mandatory, feel free to open the PRs you want):
* Metadata classes, basic error/retry handlers and one initial smal API,
with mock and live tests.
* Other APIs with tests (the bigger the PR the more it takes to review and
fix).
* Compute skeleton and the transformation functions from the provider model
to the jclouds one.
* Basic implementation of the adapter and provider-specific option classes.
* Details and implementatiom of the compute service live tests (our
contract for all providers).
I'll be happy to help and provide guidance on the jclouds code to get the
PRs merged. Feel free to also join the IRC or Slack channel and talk to us
there: http://jclouds.apache.org/community/
I.
On Feb 25, 2018 1:24 PM, "Andrey Rusev" <a....@mishmash.io> wrote:
Cool, thanks Valentin! :)
Just did a veeery quick share, plus, added some of the issues to the README:
https://github.com/mishmash-io/jclouds-labs/tree/master/hetzner
I think it's kind of too early to submit a pull request though...
---- On Sun, 25 Feb 2018 13:21:20 +0200 Valentin AItken <
valentin@nalisbg.com> wrote ----
> Hi Andrey,
>
> Glad to see more contributors in jclouds!
>
> You did successfully the "0." step from the contribution guide [1]
>
> Regarding reviewing and discussing the code, I suggest you commit it in
> jclouds-labs [2], fork it, push it and submit a Pull Request.
> I find PR discussions very benefitial.
>
> Valentin.
>
> [1] https://cwiki.apache.org/confluence/display/JCLOUDS/How+to+Contribu
> te
> [2] https://github.com/jclouds/jclouds-labs
>
>
> В 13:00 +0200 на 25.02.2018 (нд), Andrey Rusev написа:
> > Hello all,
> >
> > We did a very quick implementation of a cloud provider we use ( https
> > ://www.hetzner.com/cloud ) and I thought we might share it so that
> > other people can use it too. And then I thought we better do it
> > properly. As none of us is really an expert on jclouds internals,
> > plans, etc I'd like some help with figuring out what would be the
> > right way to plug it in, use all available abstractions so that the
> > api is as transparent as any other and so on.
> >
> > For example - at the moment we have a ComputeServiceAdapter that only
> > does the basics, but it feels to me a lot of functionality is left
> > out. Unless you unwrap() the lower-level API or add some metadata
> > key-values (that might 'brake' comparators or something else?).
> >
> > If anyone is happy to help with some guidance please let me know!
> >
> > Also - where do I share the code? Load it somewhere on github? Or
> > with a link to download?
> >
> > Cheers,
> > Andrey
> >
> >
> >
> >
>
Re: Assist with new cloud provider API
Posted by Ignasi Barrera <na...@apache.org>.
As Valentin suggested the best way to contribute is to open a PR to the
jclouds-labs repo.
The code does not need to be complete. Actually it is better to submit
small PRs to facilitate the reviews and to allow you to build a solid
foundation on top of which you can build the portable abstractions.
I'd recommend to open a PR early. A good path of PRs for quicker and
smoother merges (but not mandatory, feel free to open the PRs you want):
* Metadata classes, basic error/retry handlers and one initial smal API,
with mock and live tests.
* Other APIs with tests (the bigger the PR the more it takes to review and
fix).
* Compute skeleton and the transformation functions from the provider model
to the jclouds one.
* Basic implementation of the adapter and provider-specific option classes.
* Details and implementatiom of the compute service live tests (our
contract for all providers).
I'll be happy to help and provide guidance on the jclouds code to get the
PRs merged. Feel free to also join the IRC or Slack channel and talk to us
there: http://jclouds.apache.org/community/
I.
On Feb 25, 2018 1:24 PM, "Andrey Rusev" <a....@mishmash.io> wrote:
Cool, thanks Valentin! :)
Just did a veeery quick share, plus, added some of the issues to the README:
https://github.com/mishmash-io/jclouds-labs/tree/master/hetzner
I think it's kind of too early to submit a pull request though...
---- On Sun, 25 Feb 2018 13:21:20 +0200 Valentin AItken <
valentin@nalisbg.com> wrote ----
> Hi Andrey,
>
> Glad to see more contributors in jclouds!
>
> You did successfully the "0." step from the contribution guide [1]
>
> Regarding reviewing and discussing the code, I suggest you commit it in
> jclouds-labs [2], fork it, push it and submit a Pull Request.
> I find PR discussions very benefitial.
>
> Valentin.
>
> [1] https://cwiki.apache.org/confluence/display/JCLOUDS/How+to+Contribu
> te
> [2] https://github.com/jclouds/jclouds-labs
>
>
> В 13:00 +0200 на 25.02.2018 (нд), Andrey Rusev написа:
> > Hello all,
> >
> > We did a very quick implementation of a cloud provider we use ( https
> > ://www.hetzner.com/cloud ) and I thought we might share it so that
> > other people can use it too. And then I thought we better do it
> > properly. As none of us is really an expert on jclouds internals,
> > plans, etc I'd like some help with figuring out what would be the
> > right way to plug it in, use all available abstractions so that the
> > api is as transparent as any other and so on.
> >
> > For example - at the moment we have a ComputeServiceAdapter that only
> > does the basics, but it feels to me a lot of functionality is left
> > out. Unless you unwrap() the lower-level API or add some metadata
> > key-values (that might 'brake' comparators or something else?).
> >
> > If anyone is happy to help with some guidance please let me know!
> >
> > Also - where do I share the code? Load it somewhere on github? Or
> > with a link to download?
> >
> > Cheers,
> > Andrey
> >
> >
> >
> >
>