Dear Alex,
Thank you very much for your answer, I think that I can now understand your point of view in a better way.
My comments inline.
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 31/05/2011, a las 09:09, Alex Glikson escribió:
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.
OK, I’ll try to make the mental switch.. so by now focusing on capabilities from the “user” perspective.
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*.
OK, yes, I agree that we can call it SLA or SLO, it is just that calling SLA is more known out there, but I don’t have a problem here. No a strong opinion about the name.
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).
OK, I see.
policy-driven optimization -- I see it as a part of the VM hosting GE. Let me know if you think differently.
In my view is more part of the Hosting of compound services, a layer up that is able to decide which concrete VM hosting to use. But we can go more into the capabilities specification and then decide where it fits better.
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.
Yes, probably will be the reporting of usage metering, anyway it is something that we need to elaborate more, and as you say see the interactions with the WP3 and their needs. And of course, I am completely agree with you that it is part of the FT interest within the Hosting Cloud WP. We hope that someone from them could give us more details about it.
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!
Just the only comment now is that we do not understand very well the position of the Hosting of Compund Services and the Hosting of Application Containers. We see it change in the order shown in the figure.
<ATT00001..gif>
From: FERNANDO LOPEZ AGUILAR <fla at tid.es<mailto:fla at tid.es>>
To: Alex Glikson/Haifa/IBM at IBMIL
Cc: "fiware-cloud at lists.fi-ware.eu<mailto:fiware-cloud at lists.fi-ware.eu>" <fiware-cloud at lists.fi-ware.eu<mailto: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.
<ATT00002..png>
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
<ATT00003..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/2518b783/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/20110531/2518b783/attachment.tiff>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy