If we take this to its logical conclusion, it sounds like we can separate APIs into two categories:
1. Those that have an abstraction or can be abstracted in the future (to be in jclouds/jclouds). Most APIs would be in here. 2. Those that provide provider-specific features only, and cannot be abstracted. There should only be a few here, but this means a few per provider, so overall this category might contain a large number of APIs. If we were to organize the repos using the two categories above, we can do something like (suggestion): 1. jclouds/jclouds (Same as now, with more APIs - including beta APIs - promoted. Regular release schedule) 2. jclouds/providers (All provider-specific APIs that will never be abstracted. Release together with 1. This also needs a better name, as it only contains APIs that are not abstractable). 3. jclouds/labs (very experimental only - will not be released) Note that I am strongly in favor of fewer repos for us to manage. Maybe we should not even have 2. What would you change in the description above? Thanks! -Zack ________________________________________ From: Ignasi Barrera [ignasi.barr...@gmail.com] Sent: Monday, December 08, 2014 4:19 PM To: dev@jclouds.apache.org Subject: Re: [DISCUSS] What is the criteria for something to be in the jclouds/jclouds repo? 1. So once an api meets the criteria of having a steward, being modern, and having a proper test suite, it can immediately be promoted? I really think that those APIs need to have an abstraction, or a potential abstraction that is being developed, but something real, tangible, that ensures that it is aligned with the essence of what jclouds is. 2. Can you elaborate on this point? Did you have some criteria in mind for what “makes sense” means? There are several features more than one cloud provider offers (networking, load balancers and databases, are the obvious examples) that could have an abstraction. Not every feature in every cloud provider may make sense in others, and thus are not suitable to have an abstraction. In that case, we should be asking ourselves what value adding such an "independent" API gives to jclouds. We have provider specific APIs to *complete* the functionality "offered by the abstractions", but I really don't think is a good idea to add "entire independent apis" that won't have an abstraction because they're too specific to a single cloud provider. When I say "makes sense" I'm saying to ask ourselves if that API really makes sense in the global jclouds picture. If it makes sense, let's work on getting those features available in a portable way to other providers too. If that doesn't make sense, then that API doesn't make sense to jclouds. 3. Are you saying that if there’s an api that would never be a good fit for abstraction, that it has no chance of being promoted? Yes. I really believe we should be doing that. As I said, jclouds is not an API placeholder to every single API that qualifies itself as "cloud". jclouds is all about abstractions, and about providing users a way to write portable code. Of course we have provider specific features, but as I mentioned before, those should serve the purpose of completing the abstractions, but never be independent and standalone providers/apis. That has proven to be difficult to maintain. considerably increase the codebase complexity and make it more difficult to evolve jclouds itself. 4. Are you saying that if an abstraction doesn’t happen in some amount of time, that any apis related to that lack-of-abstraction would be removed? Well, this is open source, and "time" is relative. The complexity of abstractions can be very different: databases seems to be a simple, but networking can be really complex. What I'm saying is that we should *work* on those abstractions and *work in a direction to make those abstractions" something real. But we can't just keep adding more "satellite" APIs and forget about the rest. We should be thinking about abstractions and woking on them, and that's what matters, not time. Take the database APIs as an example. It has been commented more than once that it would be nice to have an abstraction. What actions have been taken in that direction? None. Any proposal? Nope. That's what we have to change. On 8 December 2014 at 16:01, Everett Toews <everett.to...@rackspace.com> wrote: > On Dec 2, 2014, at 2:31 PM, Ignasi Barrera <n...@apache.org> wrote: > >> 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 think having everything in jclouds/jclouds could possibly work but we would > need to be more specific about the above. Otherwise I’m concerned we’d wind > up in the same place 6 months down the road. > > If this were to be the path we go down, I have some clarifying questions. > These are open questions for anyone to answer. > > “the absence of an abstraction shouldn’t be a blocker” > > 1. So once an api meets the criteria of having a steward, being modern, and > having a proper test suite, it can immediately be promoted? > > > “Let's work on adding an abstraction when that makes sense!” > > 2. Can you elaborate on this point? Did you have some criteria in mind for > what “makes sense” means? > > > "it does not make sense to promote/keep such apis/providers.” > > These are two different concerns and should be broken out. > > "it does not make sense to promote such apis/providers.” > > 3. Are you saying that if there’s an api that would never be a good fit for > abstraction, that it has no chance of being promoted? > > "it does not make sense to keep such apis/providers.” > > 4. Are you saying that if an abstraction doesn’t happen in some amount of > time, that any apis related to that lack-of-abstraction would be removed? > > > Everett
