Git sounds good to me. Does anyone have a pointer re how to get the repo created?
Cheers, David On 23 May 2017 at 11:43, Dominik Przybysz <[email protected]> wrote: > Hi, > new git repo is better in my opinion. > > 2017-05-23 11:43 GMT+02:00 David Bosschaert <[email protected]>: > > > Not a lot of discussion yet - one thing to add is that I did a > presentation > > together with Carsten Ziegeler about this topic some time ago: > > https://www.slideshare.net/mfrancis/dockerizing-apps- > > for-the-deployment-platform-of-the-month-with-osgi-david- > > bosschaert-carsten-ziegeler > > where some of the ideas are covered. > > > > If nobody complains I'll start a little subproject in the Aries SVN where > > the ideas can be worked out further. Or should I create an Aries Git repo > > for this? > > > > Cheers, > > > > David > > > > On 16 May 2017 at 08:46, David Bosschaert <[email protected]> > > wrote: > > > > > Hi all, > > > > > > Over the past years I have been working on an API that provides a layer > > of > > > abstraction for container management. What it basically allows you to > do > > is > > > create a program that can run docker containers (or potentially other > > > containers) regardless of the underlying infrastructure. > > > > > > A little history of the project to provide some context. I worked (and > am > > > still working) on projects that require applications to be run as > docker > > > containers. Initially I started this as a pure docker project, but > later > > it > > > was moved to use Amazon ECS, a docker container environment. Later it > > > migrated to use Marathon and later yet again it migrated to another > > system > > > for managing docker containers. > > > Lucky enough I had an API abstraction in place which allowed me to take > > > the existing application and I just had to write a new driver for > > whatever > > > today's platform of deployment was going to be. > > > > > > The ideas and insights I gained during this time led me to submit OSGi > > RPC > > > 179 which has since been accepted by the OSGi community. While this is > > > currently just an RFP (no detailed technical design yet) the idea could > > be > > > there that different communities can implement this API to focus on the > > > backend that they care about. This has two benefits: > > > 1. users can switch backend by just taking the implementation that > > > supports it > > > 2. implementations don't need to support every backend that exists in > the > > > world. They rather focus on a small number that they care about, which > > > keeps this maintenance of this manageable. > > > > > > While I have quite a lot of code for this personally think that it > would > > > be better to start from scratch here. So, I would propose to start a > new > > > subproject in Apache Aries, for example named 'Aries Containers'. There > > we > > > could implement the start of what could become input to the OSGi API > and > > > maybe a small number of implementations, for example a Marathon one and > > > maybe a bare Docker one. We might also consider providing a Kuberbetes > > impl > > > if someone with knowledge of that (I have not used that much) joins the > > fun. > > > > > > Thoughts anyone? If people are happy with this idea my plan is to start > > > adding some API and impl soon to provide a starting point for such a > > > project. > > > > > > Best regards, > > > > > > David > > > > > > [1] https://github.com/osgi/design/blob/master/rfps/rfp-0179 > > > -ComputeManagementService.pdf > > > > > > > > > -- > Pozdrawiam / Regards, > Dominik Przybysz >
