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 <geoff.macart...@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é <j...@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 <geom...@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 > >
