-
Notifications
You must be signed in to change notification settings - Fork 4
Roadmap: Development
This is a rough outline of the envisioned roadmap for SAGA-Bliss development. Since SAGA-Bliss aims to be a community project, we would like to encourage anyone who's interested in SAGA-Bliss to comment on and contribute to this roadmap. This is probably best done via the developers mailing list: https://groups.google.com/forum/?fromgroups#!forum/bliss-dev.
We have roughly organized the roadmap into three milestones called tiers. Except for Tier 1 which is due September 2012, there are no dates associated with the milestones.
Issue tracker link: https://github.com/saga-project/bliss/issues?milestone=1
-
Implement Job API Package(Done) -
Implement Resource API Package(Done) -
Implement File API Package(Done) -
Implement SSH Plug-In(Done) -
Implement PBS Plug-In(Done) -
Implement SGE Plug-In(Done) - Implement GSISSH Plug-In
Issue tracker link: https://github.com/saga-project/bliss/issues?milestone=2
-
Production Feature: Implementation of the SAGA Advert Package along with a plug-in (probably based on Redis). Advert represents the coordination aspects of the SAGA API and is important for the development of SAGA-based distributed frameworks and application. Advert was one of the popular packages in SAGA C++, we expect it to be just as usable in our Python implementation.
-
Production Feature: Implementation of a Condor Plug-In. This is required for people who want to use SAGA-Bliss on Open Science Grid and other Condor-based grids. Condor doesn't allow remote job submission without having parts of the Condor-stack installed on the client machine -- we would like to circumvent that by implementing a 'remote submission mechanism' that tunnels Condor commands via SSH and GSISSH -- similar to the ssh+pbs:// and ssh+sge:// mechanism in the PBS and SGE plug-ins.
-
Experimental Feature: Implementation of the SAGA Monitoring API and see how feasible it is to integrate it with existing job plug-ins. To our knowledge, the monitoring API has never been implemented -- it would be interesting to explore how practical / difficult to implement it is.
-
Experimental Feature: Implementation of the SAGA Async API and see how feasible it is to integrate it with existing job / file plug-ins.
Issue tracker link: https://github.com/saga-project/bliss/issues?milestone=3
-
Experimental Feature: Implementation of the SAGA Messaging API: Where the SAGA advert API aims to support the coordination of loosely coupled concurrent application components, the Message API aims at more tightly coupled distributed communication patterns, in particular for use cases which require high frequency, low latency and/or high volume communication channels. ZeroMQ seems to be an excellent backend for an initial message adaptor.
-
Production Feature: implementation of Globus GRAM / GridFTP / Globus online plug-ins, for the job and/or resource package, and the file package. Globus will continue to be a work horse for a number of DCIs we intent to work with.
-
Experimental Feature: Implementation of an OCCI plug-in: the SAGA resource package maps, by design, well to OCCI, and OCCI is expected to become a unifying interface to IaaS based infrastructures. Iff OCCI is really becoming widely adopted, an OCCI adaptor will simplify Bliss interactions with a variety of Clouds. FutureGrid (with openStack) should be used as development testbed.
-
Experimental Feature: Implementation of a BES plug-in: OGF's Basic Execution Service interface is supported by a number of relevant DCI middlewares (Unicore, Arc, Genesis, Globus (Globus-Europe), and others). While there is no immediate need to support BES (all DCIs support other interfaces, too), the support for BES would simplify interoperability experiments. Also, due to the native JSDL support of BES services, Bliss would minimize job description translation pain.