Fernando -- thanks for insightful comments! All, We need to start thinking about the capabilities that we provide to our users -- those who would directly consume the GEs (e.g., UC project developer, Cloud Hosting provider), rather than functional components. GEs should represent groups of requirements, exposed externally. I know it is not easy, but all of us need to do this mental switch. For example, "service management" is a component, bit it is not necessarily a GE. What a UC developer will be looking for is the capability to host his (multi-VM) services somewhere. We know that this capability is provided by the Service Management component, on top of pool management, VM resource management, hypervisors, etc. But HLDesc should focus on the users and the capabilities we provide them, rather than on internal components - at least for now. Similarly, "platform management" is a component, rather than a GE The user doesn't really need to know that it runs on top of VMs, manages those VMs in a certain way, etc. Those details are important, but not at this level. I had a similar discussion yesterday with Andy regarding internal components of VM hosting GE -- what the users (or other GEs using VM hosting) are really interested in, is to be able to host their VMs. Whether or not there is a component called "node manager" somewhere underneath -- they probably wouldn't care much. Same for monitoring -- unless we refer to some unique monitoring capabilities that we provide externally, like the Amazon's CloudWatch (which I don't know if we plan to do). So, being Agile, let's focus on the needs of the target audience of the HLDesc -- which is mainly UC projects and wider audience interested in capabilities, and not internals. Regarding auto-scaling, and whether or not it should be a separate GE.. I don't mind merging them, and specifying 'auto-scaling' as one of the (optional) functions provided by the (compound) service hosting GE. SLAs vs SLOs -- "SLA" is a business/legal term, while what we provide is the infrastructure to monitor & enforce the *objectives* derived fro those *agreements*. Object Storage -- this is analogous to Amazon S3. It is a service that is surfaced separately, not necessarily related to VM hosting. VM hosting can use Object Storage -- as anyone else, internal or external to Cloud Hosting offering (we could consider some optimization for internal access -- but I think this is far beyond the level of details that we currently need). policy-driven optimization -- I see it as a part of the VM hosting GE. Let me know if you think differently. Accounting and billing -- the business side of this should be provided by WP3. On the infrastructure side -- what functions do you envision besides resource usage metering? BTW, I assume we might want to elaborate on this further once someone from FT (who is associated with this function) joins the discussion and the HLDesc effort. As discussed in our last meeting, the inter-relationships between auto-scaling, service hosting and application container hosting should be more flexible than on my original diagram. See below an updated version of the diagram. Comments are welcome! From: FERNANDO LOPEZ AGUILAR <fla at tid.es> To: Alex Glikson/Haifa/IBM at IBMIL Cc: "fiware-cloud at lists.fi-ware.eu" <fiware-cloud at lists.fi-ware.eu> Date: 31/05/2011 02:47 AM Subject: Re: [Fiware-cloud] 24-May-2011 weekly conf call -- minutes Dear all, I was checking the GE and the relationships between all of them. I suggest to review it with the following updates. - We prefer to change the name of "Hosting of VM-Based services" to "Service Management" due to it reflects more appropriately the functionality. * Within this GE (compound basically by Claudia assets), we can find the functionality of Autoscaling, Lifecycle Management and Image processing. * Image Processing is a VM Image Manager that will be used by the PaaS (see bellow). * The functionality of the Autoscaling is provided autoscale functionality of the VM. In case of the PaaS autoscaling, we have to define specific functionality (see bellow). * Other functionality, that we need to put here, is the Federation & Interoperability part. - PaaS, is something more complex to be managed. It creates the Virtual Appliance and manages the different products that the services will need * PaaS needs also autoscaling, but we can see it compounded by 2 different parts. The first one manages the configuration of the platforms (DB, Web Server, etc...) that it is needed in a Platform. Meanwhile, the autoscaling part of the Service Management will be the functional block that realizes the real autoscale of the VM, based on this configuration information. * The name of Hosting of Application Containers is not very appropriate in this case due to PaaS is not a Platform Container itself. It tries to manage automatically the virtualization of the different components needed by an application, for example DB or Web Server. We see more appropriate the term "Platform Management (PaaS)" here. * The scalability is applied both PaaS level and Service Management level, cue to we need to reconfigure the different platforms in which our services will be scaled furthermore. * The same have to be applied to the monitoring in which we have to take into consideration both the services KPIs in the Service Management and the PaaS KPIs in the Platform part. - Regarding the SLO Mgmt, I am not sure why you put the name of this GE to SLO and not to SLA, we consider it would the more general view if we consider SLA and not the part of it. What was the reason to adopt it? * We have to considerer the different rules defined by the users through the Elasticity Rules, QoS and/or Business Criteria. If we consider this elasticity rules like SLA or related to the SLA then we need to put a relationship between the SLA and the autoscaling functionality. - Object Storage, in this case we do not see directly what is the reason that we have to put direct connection between Self-Service Interface and it, maybe due to you have to put here protocols like CDMI? Anything else? Continue with this GE we see that it is needed a connection between Object Storage and the Hosting of VM in order to access to the data objects. - Regarding the Policy-Driven Local and cross-data centre optimization. Question here is that it is related to the placement concept? in which GE can we put this functional block? - Finally, accounting and billing, we see it like a transversal component not specified here but related to all piece of the Cloud Hosting. Best regards, 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 El 26/05/2011, a las 18:35, Alex Glikson escribió: Please, see below the summary of the conf call we had this Tuesday. Your comments are welcome. Also, see attached the latest version of the HLDesc template. As discussed, I haven't integrated your contributions -- please, send them in the new HLDesc format by next Monday, and I will then integrate them. Regards, Alex Attendees: IBM (Alex, David, Marina), TID (Fernando), Intel (Andy), TRDF (Serge), UPM (Juaquin et al). Missing: INRIA, FT Agenda: Generic Enablers HLDesc progress Minutes: List of GEs was reviewed. Relationships between the GEs might need to be adjusted (e.g., between PaaS and SM. also, auto-scaling might be used generically on top of PaaS or IaaS) Each partner sent their updates to the document. Next steps is to align it with the GEs structure, as well as with the HLDesc template Action Items: For each of the Generic Enablers, the corresponding partners will send an updated draft of the corresponding section of the HLDesc (3.1.2.x), according to the guidelines provided within the template (document attached below). They will also include a list of terms relevant for their GE, as well as open questions that would need to be addressed. The materials will be sent to the mailing list, by EOD Monday, May 30. 3.1.2.1 (Hosting of VMs) -- Alex & Andy, 3.1.2.2 (Hosting of VM-based Services) -- Fernando, 3.1.2.3 (Auto-Scaling) -- Fernando, 3.1.2.4 (SLO management) - David, 3.1.2.5 (Object Storage) - Andy, 3.1.2.6 (PaaS) - Fernando, 3.1.2.7 (Cloud Edge) - Serge. Alex and Andy to meet separately to discuss the collaboration on the HLDesc section describing "Hosting of VMs" GE <FIWARE HLDesc Cloud v0.1.doc><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/20110531/5407912f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 18223 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20110531/5407912f/attachment.gif> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 250731 bytes Desc: not available URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20110531/5407912f/attachment.png>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy