jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ignasi Barrera <n...@apache.org>
Subject Re: [DISCUSS] What is the criteria for something to be in the jclouds/jclouds repo?
Date Tue, 02 Dec 2014 20:31:51 GMT
In my opinion there are several requirements to be met, all them mandatory:

1. New providers MUST have an abstraction (more on this below).
2. Must have a Steward, who maintains the provider, takes the issues,
and runs the live tests periodically (at least before each release).
3. It must follow the coding guidelines. As Andrea mentioned,
technical debt is a *real* blocker when it comes to refactor the core
to fix structural issues. We can't keep adding it to the main repo.
Huge providers that are out of date are only going to cause us
trouble.

Regarding the abstractions. We need to think about what jclouds is.
jclouds is ALL about the abstractions. It is not an aggregator of any
api that is labelled "cloud". Without the abstractions, jclouds makes
no sense. Users don't come to jclouds looking for concrete APIs. They
come looking for a portable toolkit. If you have a look at the mailing
list, most questions are about the Blob and Compute abstraction. There
are also many about the Neutron API, but that is *only* because those
APIs have failed to create an abstraction. Users are asking for
concrete APIs just because there is no abstraction for them.

This said, the absence of an abstraction (take network or databases as
an example) shouldn't be a blocker. Abstractions can be proposed in
the mailing list, and even better discussed in a PR! We are all
looking to improve jclouds to make it better for the users, and that
means making it more portable. Let's work on adding an abstraction
when that makes sense! But things have to be *real* and that work has
to be done. Without it, it does not make sense to promote/keep such
apis/providers.

I.


On 2 December 2014 at 18:44, Andrea Turli <andrea.turli@gmail.com> wrote:
> Hi,
>
> I personally think we should consider a couple of additional criteria to
> the good Zack's list.
> The code should support the latest stable (recommended) version of the API.
> The implementation should follow all the current guidelines (i. e. Use of
> Auto Value and Service, MWS, no async API)  so that the new providers don't
> introduce tech debt, this should be kept during reviews but we need some
> standard way to "enforce" them.
> MockTests and LiveTests have to be green.
> The maintainer has to be able to run the LiveTests for each release.
>
> As contributor to labs repos this is my understanding of what it is needed
> to get the provider out of labs, hope this helps.
>
> Andrea
> Il 02/dic/2014 18:28 "Zack Shoylev" <zack.shoylev@rackspace.com> ha scritto:
>
>> Possible criteria that have been discussed before:
>>
>> 1. If it is out of beta
>> 2. If it has a maintainer
>> 3. If it has a jclouds abstraction layer
>> 4. Voted on a case by case basis (current way of doing things)
>>
>> Are there any more possible criteria I have left out? In the end it will
>> be some mix of the above. My thoughts on this is that 2) is sufficient.
>> -Zack
>> ________________________________________
>> From: Dancy, Chris [Chris.Dancy@pega.com]
>> Sent: Tuesday, December 02, 2014 8:27 AM
>> To: dev@jclouds.apache.org
>> Subject: Re: [DISCUSS] What is the criteria for something to be in the
>> jclouds/jclouds repo?
>>
>> As an occasional contributor, and currently coding a Shipyard provider
>> (JCLOUDS-782), I do have a vested interest in how this ends up. IMO I
>> think having a clear separation of ³core² projects vs ³baking² projects is
>> a good idea but it seems that is not working out so great here? Are there
>> other proposals on how to do this?
>>
>> On 12/2/14, 4:09 AM, "Inbar Stolberg" <inbarsto@gmail.com> wrote:
>>
>> >I think openstack neutron should be in jcluods master currently it suffers
>> >from being left out even though it is being updated and runs on openstack
>> >api v2.
>> >
>> >regarding glance I think after
>> >https://github.com/jclouds/jclouds-labs-openstack/pull/77 is merged we
>> >should move it.
>> >
>> >regarding Ceilometer I think that taking to accout what you said Everett:
>> >" in email threads or IRC chats most everybody agrees that the labs repos
>> >are a failed experiment"
>> >maybe its worth considering porting it to jclouds/jclouds from right after
>> >the merge of :
>> >https://github.com/jclouds/jclouds-labs-openstack/pull/166
>> >
>> >(which btw I am already going to use in production code...)
>> >
>> >my 2 cents
>> >Regards Inbar
>> >
>> >
>> >On Tue, Dec 2, 2014 at 2:06 AM, Everett Toews
>> ><everett.toews@rackspace.com>
>> >wrote:
>> >
>> >> What is the criteria for something to be in the jclouds/jclouds repo
>> >>[1]?
>> >>
>> >> Before we go moving any more code around or removing any more
>> >> apis/providers we need to step back and have some agreed upon criteria
>> >>for
>> >> what belongs in jclouds/jclouds and what doesn¹t. If we don¹t do that
>> >>our
>> >> decisions are effectively arbitrary and the questions of ³What to do
>> >>about
>> >> X?² will continue to come up.
>> >>
>> >> I took a shot at addressing a topic like this in "Criteria for moving an
>> >> api/provider from a labs repo to core² [2] but I got zero replies.
>> >>People
>> >> seem to be unwilling or uninterested in tackling this question and I
>> >>think
>> >> jclouds is suffering because of it. It¹s puzzling to me because in email
>> >> threads or IRC chats most everybody agrees that the labs repos are a
>> >>failed
>> >> experiment. So let¹s flip it around and discuss what belongs in
>> >> jclouds/jclouds instead.
>> >>
>> >> I know for a fact that many contributors have an opinion on this. Let¹s
>> >> hear it!
>> >>
>> >> Thanks,
>> >> Everett
>> >>
>> >> [1] https://github.com/jclouds/jclouds
>>
>>

Mime
View raw message