Ive added additional pieces below (yellow). Apologies for the delay. Andy 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] * OGF33: Venus-C (venus-c.eu) has a OVF to OCCI tool * France telecom participation in WP4 discussed * Gap related to billing/accounting noted * * 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 * number of WP7 folks are interested in Network-as-a-Service, something that OpenStack/Quantum can provide @andy to discuss further with respective WP7 people * * Object Storage [Andy, Fernando] * Interface to openflow (?) * This is NOT related to Object Storage. * Cloud Standard API - CMDI - OVF interoperability * Action Item [Fernando]: CDMI interface specification of the SM * @andy Further investigations required for CDMI on swift * 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] * Monitoring architecture presented * Noted that Analysis should cover both online (e.g. CEP) and offline (e.g. MapReduce) * Noted that Storage should cover both optimized time series storage (e.g. rrdtool, graphite) and BigData storage (e.g. Hadoop/HDFS) * Metric sources should have the possibility to be configured (policies) from a central location * Visualisation noted as a deficiency and possibly subject to an open call * Security [Andy] * Presented extracted security requirements * Andy to continue as mediator between WP4 and WP8 * Representative pleased to see WP4s consideration of requirements * @all Plan to 1st specify WP4 EPICs and then add/modify to account for security requirements * Noted that OpenStack keystone can be considered as an asset providing SSO * 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. * Interest in Network as a Service from WP7 people. Need to understand better integration point here. * 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? * There is a need from the WP to have WP4 services described as USDL * 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. * Presented monitoring architecture using GEs as building blocks 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 <http://lists.fi-ware.eu/listinfo/fiware-cloud> 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/20110923/600d989d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20110923/600d989d/attachment.bin> -------------- next part -------------- ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy