[Fiware-cloud] IMPORTANT: Next Steps

[FERNANDO LOPEZ AGUILAR]

My contributions in red...

Fernando López Aguilar
Cloud Computing
fla at tid dot es
+34 914 832 729
Telefónica I+D (R&D)
Ronda de la Comunicación s/n
Distrito C, Edificio Oeste 1, Planta 5
28050 Madrid, Spain

[cid:65E3CA3A-3DFE-41B6-8F69-2AD965EA42FA at hi.inet]

El 21/09/2011, a las 17:29, Alex Glikson escribió:

Below is my initial input for highlights and action items. Please, augment with your input (please, use a different color). Thanks.

Regards,
Alex



From:        Alex Glikson/Haifa/IBM at IBMIL
To:        fiware-cloud at lists.fi-ware.eu<mailto:fiware-cloud at lists.fi-ware.eu>
Date:        19/09/2011 10:36 PM
Subject:        [Fiware-cloud] IMPORTANT: Next Steps
Sent by:        fiware-cloud-bounces at lists.fi-ware.eu<mailto:fiware-cloud-bounces at lists.fi-ware.eu>
________________________________



Hi All,

It was great to see many of you in Turino last week.

First, I'm out of office tomorrow, so there will be no weekly call. However, I would like us to make progress offline, as follows.

1. Highlights and action items from the F2F at Turin
Please, send me your notes regarding highlights (main accomplishments and issues) and action items from the F2F discussions last week. I will consolidate them and will send to Juanjo (per his request).
For your convenience, here is a list of sessions:

 *   General -- main accomplishments:
    *   Socializing among team members, including additional team members which did not attend the kick-off in May. Improved team atmosphere and trust.
    *   Gained common understanding of the architecture, main assets, interfaces, potential integration challenges and gaps -- for the entire WP as a whole, as well as for individual GEs
    *   Identified several significant gaps (see below), some of which may become topics for open calls
    *   Conducted highly productive joint sessions with other WPs (see more details below)
       *   Met in person key representatives of other teams, thus improving future collaboration
       *   Gained better understanding of what other WPs are doing
       *   Identified and verified potential integration points and assets/GEs that can be leveraged
 *   Cloud Edge, Cloud Edge RM [Serge, Alex]
    *   Reviewed the architecture of the Cloud Proxy
    *   Reviewed end-to-end scenario of provisioning of an application hosted in the cloud, having a component designed to run close to the end-user (on a Cloud Proxy)
    *   Refined WP architecture to address the distinction between the Cloud Proxy device (running outside of the centralized cloud infrastructure) and the management component that would typically run within the centralized infrastructure and act as a proxy between the centralized cloud management stack and the numerous Cloud Proxy devices located close to the end-uses.
    *   Identified a gap in providing the above management component.
       *   Action Item [Serge]: find out whether this gap can be contained (e.g., by re-balancing the Cloud Proxy related work between WP4 and WP7).
          *   Note: this issue was discussed at the PCC, and it was mentioned that the chances to be able to handle this gap via the open calls mechanisms are not high (as this is a mandatory component to provide the end-to-end functionality of Cloud Proxy, which should have been taken into account in the original plan)

 *
 *   IaaS Service Management [Fernando]
    *   TBD
    *   It should be possible to design services that comprise components that run on Cloud Proxy (and potentially also end-devices -- see comment from I2ND interlock), as well as object storage resources. This should be reflected in service manifest, as well as handled during provisioning and life cycle management of services. It must be studied.
    *   A service composition tool should be part of the ecosystem provided to the application developer/provider. Should be considered for the Open Call. A Service composition tool should be part of the Portal or a specific tool provided by the specific WP within FI-WARE (TBD). IMHO It is not part of the SM.
    *   Scalability and security aspects of Claudia should be considered. The security aspects must be applied to all GE. BTW, we need more discussion about this topics due to we need to clarify all the security requirements.

    *   How do we store/mngt. the credentials (e.g. EC2 Amazon)? [AI Fernando]
    *   What is the possibility of scaling Claudia? [AI Fernando]
    *   It is possible to update the service manifest dynamically (I suppose yes) [AI Fernando]
    *   There are not trivial dependencies between Claudia and IaaS Data Center Mngt.
    *   Why do we need to use clone VMs? Can we provide some UCs?
    *   Integration with SLA-SLO. Which type of SLA we are using. How Claudia manages the SLAs?
    *   Interoperability between Cloud Standard API (DMTF CIMI) and OCCI through OVF. Especify the OVF exchanges messages in common (the same for CDMI could be applied) [AI Fernando Andy Alex]

 *
 *   PaaS [Fernando]
    *   TBD
    *   The current approach for PaaS provisioning is to install middleware components into an existing running OS (with Chef), which has been installed separately (in our case -- as part of the provisioning of the corresponding VM). A unified approach should be considered, in which the VM images already include the middleware components pre-installed, and they just need to be customized during provisioning

 *
    *   It is not clear whether OVF-based manifest would be a good fit to describe PaaS-level services. Other alternatives should be considered. We prefer to extend a common standard API (OVF) and not use another one from the beginning. We want to use the same protocol that we are using in the SM. Also the interface that PaaS GE provide is Cloud Standard API based on OVF.

    *   How can we specify the elasticity rules in terms of PaaS? [AI Fernando]
    *   Why do we use Chef for the PaaS? [AI Fernando]

 *
 *   IaaS DataCenter Resource Management [Alex, Andy, Fernando]
    *   Reviewed WP architecture, mapped assets and gaps
    *   A need for common monitoring infrastructure was stressed
    *   The resource management layer should provide capability of orchestrating operations across groups of VMs -- e.g., in a scenario of service snapshot.
    *   We should consider supporting non-virtualized workloads
    *   proximity policies
    *   translate the requirements of the SM to the policies of the CDRM

 *
 *   Object Storage [Andy, Fernando]
    *   Interface to openflow (?)
    *   Cloud Standard API - CMDI - OVF interoperability
       *   Action Item [Fernando]: CDMI interface specification of the SM

 *   Self-Service Interfaces [Juaquin]
    *   A collaboration-driven approach to Cloud Portal was presented
    *   Action Item [Alex, Joaquin]: assess whether this can be contained within the existing funding. It might make sense to focus on have a fully-functional cloud portal as a subject for an Open Call.
    *   where is the user management? permission, accounting, etc…

    *   How to manage the SSO? and how to translate it to each GE?


 *
 *   Monitoring [Andy]
 *   Security [Andy]
 *   Interlock with I2ND
    *   It was mentioned that in some cases a cloud application may include a component designed to run at the end-user device (e.g., a mobile phone) -- either within the Web browser, or as a 'rich client' component. In a way, this can be considered as another 'tier', besides the centralized cloud infrastructure and the cloud proxy. This should be taken into account when designing the service manifest, as well as during provisioning and service life cycle management.
 *   Interlock with Security [Andy]
    *   Reviewed security considerations which might apply to Cloud Hosting. How to protect the services in the Cloud?
       *   Action Item [Andy to coordinate]: need to refine our security considerations in the HLD (once transferred to the Wiki)
    *   It was noted that the security WP is interested in leveraging the common infrastructure for monitoring and CMDB. Cloud Hosting does not intend having a centralized CMDB, but having a single monitoring system which can be augmented with security probes definitely makes sense.
       *   Action Item [Alex] need to follow-up on monitoring infrastructure, across GEs and WPs
 *   Interlock with Apps [David]
    *   In order to drive business processes related to applications deployed in the cloud (e.g., SLAs), resource-related metrics produced by Cloud WP components must be accessible by the components of the Apps WP.
    *   Mashup execution engines might be hosted on the cloud (PaaS would probably make more sense than IaaS)
    *   If we move one service from one Data Center to another. How does the user know the way to access it?


 *
 *   Interlock with Data [Andy, David]
    *   In order to develop a common monitoring system, 3 components have been identified that will be provided by the Data Management WP: pub/sub broker, Big Data and Complex Event Processing. Need to follow-up on architecture, requirements, interfaces, schedule, etc.

Of course, not only the people mentioned above can contribute. Please, send me your input by EOD Wednesday. Make it brief (concise bullets).

2. Epics spreadsheets
As you know, we need to come up with a list of Epics for each GE, outlining the main areas of work we envision in the project (focusing on the first release).
Please, send me by the end of the week your initial lists, with some details for each Epic. Let's follow the format in the attached Excel -- it is an 'optimized' version of the original template (I've copied few of Fernando's epics into the new table format, as an example).
Please, remember that the work items should focus on work that is still to be done, by our team. So, when considering various assets, the work items should only refer to their integration and enhancements -- and not to features which are already there, or are developed by someone else.
There are many cool features in Excel that can potentially make the usage of Excel to manage the Epics rather convenient, but let's wait until the Agile tooling topics becomes more clear (I'm not sure Tracker is better than Excel, for our internal use).

Let's discuss both topics in our next week's call, following the input that each of us provides.

Thanks!
Alex

[attachment "Backlog entries description v0.1 TID - Alex.xls" deleted by Alex Glikson/Haifa/IBM] _______________________________________________
Fiware-cloud mailing list
Fiware-cloud at lists.fi-ware.eu<mailto:Fiware-cloud at lists.fi-ware.eu>
http://lists.fi-ware.eu/listinfo/fiware-cloud

<ATT00001..txt>


________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20110921/18d77ac1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 66394 bytes
Desc: PastedGraphic-1.tiff
URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20110921/18d77ac1/attachment.tiff>