Actually, I think I can just go ahead and give you a few more examples of what 
we need ... in general... and I think might be a good fit to jclouds, not sure 
if you guys think jclouds is the right place for this, but... if you do - I'd 
be happy to support the development for these... They're generally 
karaf-related too, but I'll share them here:

- Hot deploy to karaf instances from buckets (on any cloud)
- Unified way of accessing VM metadata services (again, at the end - we'll be 
using this inside karaf) - for reasons like auto configuration, automating some 
processes happening inside our code, automated discovery of other karaf 
instances launched as a cluster (this involves the use of more cloud APIs - 
beyond buckets and computes), etc...

These are just a couple of examples where we currently have some custom 
implementations, but I would be happy to release them as open source, either in 
jclouds or some other project... At the moment I don't necessarily know what 
would be the best place for them (as open source) - will it be jclouds or karaf 
or something else ... but still sharing it here in case it will be useful to 
you too...

Cheers,
A

 ---- On Fri, 09 Dec 2022 20:05:47 +0200  Andrey Rusev  wrote --- 
 > Hi,
 > 
 > I don't know if I will be really helping here, but I thought ... as the 
 > conversation is shifting towards 'will there be volunteers to join' ... I 
 > might share my perspective here, as someone who has been observing this mail 
 > list (and also this thread) for years... Quietly observing, that is :)
 > 
 > We have a few use cases around here for a java-to-any cloud lib (I can share 
 > more details on this if anyone is interested?), but I've honestly during 
 > that time I've been warming up and cooling down on the idea of using 
 > jclouds. Not a bad idea, if you ask me, but then the 'native' libs usually 
 > take over, so we don't use jclouds currently (it's actually not that 
 > difficult for us to plug some custom, per-cloud logic into karaf - which is 
 > what we use a lot).
 > 
 > On the other hand - I'm also super keen on working on better integration 
 > between Apache projects, say, for example, one thing we might be interested 
 > in is adding Apache Ozone support to jclouds (I don't see it in the list on 
 > the official web?), plus a few more 'compute' providers that we use around 
 > here. And I can also bring a couple of guys to this too, if needed. Far from 
 > the idea that we can start doing PR reviews straight away, but we can 
 > volunteer some development effort if it fits our use cases - say, 
 > provisioning networks (and not just buckets and computes) might also be a 
 > fit...
 > 
 > But at the same time - I do still kinda struggle (that is - for the use 
 > cases we have around here) - with the question of 'why not use the official 
 > libs instead?'. And in that sense, in my opinion, it really comes down to - 
 > who are the users of jclouds, and are there any potential new uses for it... 
 > And if there are - it will be worth supporting jclouds.
 > 
 > Don't know if I managed to explain my view clearly, happy to answer 
 > questions you might have... And ... sort of, really hoping I can be of any 
 > help here. :)
 > 
 > Cheers,
 > A
 > 
 > 
 >  ---- On Fri, 09 Dec 2022 18:59:39 +0200  Jean-Baptiste Onofré  wrote --- 
 >  > If you don't want to continue on jclouds (I fully understand this),
 >  > fair enough. But if people still want to maintain it, I don't see any
 >  > issue there.
 >  > 
 >  > Is a fork better ? I don't think so. Because, it might happen if we
 >  > retire the project.
 >  > 
 >  > As I proposed earlier, if the current PMC members don't want to
 >  > continue on jclouds, but we have potential volunteers to take over, I
 >  > think it's fair to try. Apache is community driven, if we have new
 >  > people in the jclouds community, willing to help, we could be
 >  > "welcoming".
 >  > After some months, we will definitely see if the project is still alive 
 > or not.
 >  > 
 >  > If you absolutely want to retire the project, I'm with you, and then
 >  > pulsar or brooklyn (or another project) will do a fork probably.
 >  > 
 >  > Regards
 >  > JB
 >  > 
 >  > 
 >  > On Fri, Dec 9, 2022 at 3:38 PM Ignasi Barrera n...@apache.org> wrote:
 >  > >
 >  > > I agree with Gaul's comments.
 >  > >
 >  > > If people wants to help, worth to see if it actually happens ;)
 >  > > >
 >  > >
 >  > > It's been 2 months since the proposal of retiring the project and to 
 > date,
 >  > > nothing real happened beyond "I'm in" comments.
 >  > > If at the time of discussing the project retirement, this is all the 
 > energy
 >  > > that is around to maintain it, I don't think it is a setup for success 
 > and
 >  > > agree with Gaul that we will better serve users by retiring the project.
 >  > >
 >  > >
 >  > >
 >  > > P.S. Geoff, really appreciate your honesty in accounting for your 
 > bandwidth!
 >  > 
 > 

Reply via email to