Federated Cloud Roadmap and Innovation

From EGIWiki
Jump to: navigation, search
Overview For users For resource providers Infrastructure status Site-specific configuration Architecture




Alert.png This page is obsolete. The main documentation for FedCloud can be found here.

Scenarios Roadmap

VM Management

Boris Parák (CESNET)

  • PUSP support
  • OCCI extensions
    • Compute -- resize
    • Compute -- save
  • Move to OCCI 1.2
  • Deployment of OOI for OpenStack
  • Native API support
  • Improvements/integration for client tools

(related topics in Security, Image Management & Monitoring)

Data Management

Kostas Koumantaros (GRNET)

Information Discovery

Peter Solagna (EGI.eu)

Accounting

Stuart Pullinger (STFC)

Monitoring

Emir Imamagic (SRCE)

Federated AAI

Paul Millar (DESY)

VM Image Management

Marios Chatziangelou (IASA)


Specific to AppDB:

  • VM Management operations through the AppDB

      Description: Extending the AppDB with VM management capabilities, in order to provide users with the means to instantiate and manage running instances of virtual appliances through the AppDB Portal (which in other words means: directly from their browser). For details please have a look at the AppDB VM Management operations analysis document.Comments are more than welcome.

      Status: Analysis - Preliminary design phase


  • Single VMI per VA version

      Description: Restrict only one VMI to be associated to a VA version. Going that way we will simplify all the workflows that are or will be supported by the system. Such workflows could be: creation and update of a VA version, endorsement of a VA version, auditing etc.

      Status: Implementation phase


  • VA version endorsements

      Description: Participation in discussions with regards to VA versions endorsements.

      Status: n/a

      Comments& topics that would be great to be discussed:  Confusion ....

            .... about what "endorsement" term means and what we need it for. Different interpretations, requirements and needs based on the prospective one sees the "endorsement" concept.

            .... about which entity should actually be endorsed i.e. every VA version? or the VA as a whole?

            .... on who should be the endorser. For example: one person? one group of persons? an external system (auto-endorsement)?

            .... about the scope under which an endorsement has be realized. For example: endorsed on behalf of a specific VO, endorsed from a security prospective, (just) endorsed (=no scope at all), etc.

            .... about un-endorse a VA version. This is a bit tricky because IMO, by un-endorsing a VA version, should not mean that the given VA version was never endorsed. On the contrary, evidence should be kept in order to prove whether the given VA version was endorsed or not at the moment it was downloaded (by a site) and/or instantiated (to a site).

            .... about allowing multiple endorsements per VA version. And what should happen if only one (not all) of the endorsements is revoked.

            .... about automations that should be available (developed) in endorsement or un-endorsement case respectively. For example: should only endorsed VA versions be available to the VO managers? what should happen if a VA version looses its endorsement?

            .... about allowing or not, multiple endorsements per VA version and what should happen if only one (not all) of the endorsements is revoked.

            .... etc.

VM endorsement

Vincenzo Spinoso (EGI.eu)

Brokering, APIs, SDKs

Enol Fernandez (EGI.eu)


AppDB as a GUI for VM management

Extending the AppDB with VM management capabilities, in order to provide users with the means to instantiate and manage running instances of virtual appliances through the AppDB Portal (which in other words means: directly from their browser). For details please have a look at the AppDB VM Management operations analysis document.

  • Backend: Two possible solutions:
    • Private comm. layer infrastructure: a solution tailored specifically for the needs of the AppDB service. Its main purpose is to communicate various VM management operations from the AppDB frontend to the EGI Fedcloud infrastructure, specifically to OCCI-enabled sites. In this case, the backend is divided into the following logical components:
      • API
      • Proxy certificate manager
      • Action handler
      • Monitoring
      • OCCI-enabled communication layer. Options evaluated for implementing the "OCCI-enabled communication layer" are:
        • rOCCI
        • Infrastructure Manager
    • Public comm. layer infrastructure: Use of an individual service for VM operations, publicly available to the EGI ecosystem, providing APIs based on one or more cloud communication standards. In this case, the AppDB should be integrated with that service.


  • Frontend: A dedicated VM Operations dashboard that will provide details about the running VM instances for each user, as well as a search interface for finding, selecting, configuring, and instantiating AppDB VMs that are available to the user, according to VO membership.

    Detailed analysis at: AppDB VM Management operations analysis document

Security

Linda Cornwall (STFC)

  • Security Threat Risk Assessment with Cloud focus - Need participation from a few others in the EGI Federated Cloud
  • Security Requirements related to the EGI Fed cloud. VA and VM drafted, needs iteration, probably also software requirements extracting
  • Probably also we should write down the EGI Federated Cloud Security Model

Intra Cloud Networking

Zdenek Sustr(CESNET)

Federation Model

Enol Fernandez (EGI.eu)