Highlights and action items from the F2F at Turin 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 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). IaaS Service Management 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 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 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 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 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 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 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 Presented extracted security requirements Andy to continue as mediator between WP4 and WP8 Representative pleased to see WP4?s 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 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 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) Mashups are composite services. As all other services they should adhere to SLAs. To protect end-to-end SLAs of mashups, run-time information about performance of the services comprising a mashup should be provided to the Cloud hosting resource optimization GE. Note that this information is different from the static USDL data. Kalin [?], took it as an action point to verify whether this information can be extracted from the mashup execution engine in a reasonable fashion. We have service manifests (i.e., template) for stand alone services. Do we have a reciprocal for mashups? [Kalin, Fernando] The services comprising mashups should be deployed and running either in FiWare or outside of it, but they should exist and run as a prerequisite. If services are deployed on FiWare, then resource management GE can optimize their placement and resource allocation from a global perspective. There is a strong connection to networking. Mashups' performance critically depends on the network performance. Cloud Hosting should be network performance aware to manage infrastructure for mashups. There is a need from the WP to have WP4 services described as USDL Interlock with Data 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20111004/816a1b0e/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy