Re: A world without jclouds?

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Geoff

Sorry for the late reply. I think having a "generic server/storage"
plug is probably the "easiest" move (even if it means some effort).

I can start a sketch of this (not sure when depending on my workload).

Regards
JB

On Sun, Feb 26, 2023 at 10:15 PM Geoff Macartney
<ge...@gmail.com> wrote:
>
> Hi all,
>
> Just to ask again, what are your thoughts on what we should do when jclouds
> retires? I like JB's suggestion of making the implementation of a generic
> "server" (or storage object) pluggable, and of course that would be easy to
> do with Karaf. Any thoughts on what this might look like?
>
> Regards
> Geoff
>
>
> On Tue, 14 Feb 2023 at 06:36, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> > Hi Geoff,
> >
> > I think a mix of (2) and (3) could be a good approach: Brooklyn can
> > expose a generic "server" interface, and we can have a "server cloud
> > provider" implementations. It's a kind of plugins mechanism. We can
> > provide some plugins in Brooklyn itself, but open the door to our
> > users/cloud providers to implement their own plugins.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> > On Mon, Feb 13, 2023 at 9:03 PM Geoff Macartney <ge...@apache.org>
> > wrote:
> > >
> > > Hi all,
> > >
> > > Just to follow up on the email I just sent, I have been meaning to say
> > the
> > > time has come to discuss what we do if jclouds does move to the attic.
> > > Options seem to me to include:
> > >
> > > 1. Fork jclouds.
> > > 2. Figure out some small/minimal subset of functionality we need and
> > > implement it ourselves within Brooklyn
> > > 3. Change the Brooklyn model, most obviously removing the support for
> > > general "server" and buckety types, and just go with cloud provider
> > > specific entities.
> > > 4. ??? There are bound to be more.
> > >
> > > Let's talk. What shall we do?
> > >
> > > Regards
> > > Geoff
> >