Hi all,
Please find below the results of the peer-review on the Architecture Description of the Cloud Chapter carried out by members of the Data Chapter.
=== Review by Guy Sharon:
1. [Cloud Hosting Architecture] Perhaps an end to end usage example could help out in what the users of the current GEs could make use of.
There is partial information in DCRM page and in SM page but a more wider \ cross GE story could help in understand what you can actually use these GEs for in the current version. Is it just building services made up of several resources that the DCRM manages? What is the cloud edge used for in this regards \ or for other purposes and what is the story around the object store (related or not)?
2. In the DCRM Open Specification API - to understand\work with this it seems someone must be familiar with OCCI - if this is the case then should be mentioned in the intended audience - can the software developer and cloud provider really do just with the 3 described familiarities? I am not so sure - I would not know where to start with this - but I might not have the skills or should I?
3. In [FIWARE.ArchitectureDescription.Cloud.SM] -I think it is worth spending a few sentences explaining what service application is meant here that is being managed (maybe under basic concepts) - a service here is a collection of resources and some rules for managing the resources under this service. - is there connections between services? Is it only using DCRM? If not what else can be covered under service?
(It took me a while to understand what services are actually managed by this GE)
4. SM Open Spec API - I see APIs allowing create delete of resources but not clear how these get associated with a service - are their APIs to create a service and add to this service the relevant resources needed? What about the rule APIs? (Seems not to be entirely complete or synced with the descriptions on the architecture description of SM)
5. CloudEdge - Confusing the move between app and service all over the document - it is explained that the AP role provides Apps but who provides services or is this the same? Another such example "End-User (EU): any client that subscribes and consumes a service that runs partly on the Cloud and partly on the Cloud Proxy. In this model, his role is to select those applications that are granted to install and run a piece of code on his Cloud Proxy"
6. CloudEdge - be a good idea to explain what this is for and when you would need to use this - why arent the other GEs used here - same roles, same resources being provisioned. - so whats different - whats the motivation for this. (overview and general description dont cover it - nor in the main Cloud Hosting Architecture page) - well, at least not clear to me
7. Object Store - example and how it fits to the rest would be very helpful
Is it really something that belongs to IaaS or more of a PaaS component - I would use to store objects for my application - or would it have to deal or work with the DCRM and SM and vise versa. A bit confusing that its under the same set of GEs but nothing about Infrastructure is covered here.
=== Review by Peter Amon
General remark: I found no information on how users can switch the infrastructure provider. (This question is mentioned in the review report.)
[Introduction]
- "Cloud Chapter offers Generic Enablers ..." -> "The Cloud Chapter offers Generic Enablers ..."
- The link under [1] is HTTPS. Why not just HTTP (i.e., no hassle with security certificates)?
[Architecture Overview]
- "Service Management GE" -> "Service Management (SE) GE", since the abbreviation "SE" is used in the figure.
[Architecture Description of GEs]
- Only four GEs listed, while the figure contains six GEs. (Ecosystem GEs are missing.) Confusing, since both seem to be the GEs for the first release.
[FIWARE.ArchitectureDescription.Cloud.DCRM]
[[Overview]]
- "providing the OCCI interface" -> "providing the Open Cloud Computing Interface (OCCI) interface"
[[Open Cloud Computing Interface (OCCI)]]
- "API for IaaS model based Services" -> "API for IaaS model-based services" (hyphen and lower case "s"?)
- "Basic type definitions (attributes, actions, relationships):" the following three sub-items should be indented in order to indicate their dependency.
[[Infrastructure]
- "Complimenting" -> "Complementing" or "Complimenting these specialised Resources are two specialised Links and a means to capture the notion of templates." -> "Two specialised Links and a means to capture the notion of templates are complimenting these specialised Resources."
[[Other Open Specifications]]
Sub-section with no content.
[FIWARE.ArchitectureDescription.Cloud.SM]
[[Overview]]
- "Due to it is working at the service level" -> "Since it is working at the service level"
- "On the above diagram, the SMI" -> "On the above diagram, the Service Manager Interface (SMI)"
[[Components]]
- "Due to the Query System could be in a different Host" -> "Since the Query System could be in a different Host"
[[Scalability Scenario]]
- "This Rule might be changed in future" -> "This Rule might be changed in the future"
[[Elasticity & Monitoring operations]]
- "the IaaS Service Manager have to implement" -> "the IaaS Service Manager has to implement"
[[Design Principles]]
- How can "Design Principles" be a subsection of "Basic Design Principles"?
- "IaaS Service Manager allows a single instance of service runs on a server" -> "IaaS Service Manager allows running a single instance of service on a server"
[[Resolution of Technical Issues]]
- Link to "Cloud Hosting Architecture" could be HTTP instead of HTTPS.
- "the general design principles outlined at previous section" -> "the general design principles outlined in the previous section"
[[Other Open Specifications]]
Sub-section with no content.
[FIWARE.ArchitectureDescription.Cloud.CloudEdge]
[[General Description]]
- "The cloud edge consists in one equipment called "cloud proxy" and located in the consumer private network." -> "The cloud edge consists of a component called "cloud proxy" and is located in the consumer private network." ??
- "To this purpose" -> "For this purpose"
[[Security and Privacy concern for Virtual Appliances]]
- "access to user private data" -> "access to private user data" or "access to the user's private data"
[[Virtual Appliance Life Cycle]]
- "An AP request to the CO" -> "An AP requests from the CO"
- "The CO check into his database" -> "The CO checks into his database" / "The CO checks his database" ??
[[Other Open Specifications]]
Sub-section with no content.
[[FIWARE.ArchitectureDescription.Cloud.ObjectStorage]]
[[Overview]]
- "Object storage is a Generic Enabler ." -> "Object storage is a Generic Enabler." (delete space in front of the full stop)
[[Basic Concepts]]
- "The object store presents it self as a service" -> "The object store presents itself as a service"
- "This API" -> The sentence is incomplete.
[[Other Open Specifications]]
Sub-section with no content.
=== end of reviews
Cheers,
-- Juanjo
-------------
Product Development and Innovation (PDI) - Telefonica Digital
website: www.tid.es<http://www.tid.es>
email: jhierro at tid.es<mailto:jhierro at tid.es>
twitter: twitter.com/JuanjoHierro
FI-WARE (European Future Internet Core Platform) Chief Architect
You can follow FI-WARE at:
website: http://www.fi-ware.eu
facebook: http://www.facebook.com/pages/FI-WARE/251366491587242
twitter: http://twitter.com/FIware
linkedIn: http://www.linkedin.com/groups/FIWARE-4239932
On 13/08/12 09:27, Juanjo Hierro wrote:
Dear colleagues,
Another of the actions that we need to carry out is also the review of the contents of the FI-WARE Architecture Descriptions. This goes besides the development of the FI-WARE Technical Whitepaper that follows a separate track.
We should try to do our best to get the FI-WARE Architecture Description resubmitted by end of August.
Please find the plan that I would like to follow to carry out this revision. It is basically the same schema proposed for peer-review of FI-WARE Open Specifications:
Chapter to be reviewed
Reviewing chapter
Data
Security
Cloud
Data
Apps
Cloud
IoT
Apps
I2ND
IoT
Security
I2ND
However, I believe that the major caretakers of this review task are WPLs and WPAs themselves. They can forward a request for revision by other members of their team, but mostly to get additional input.
This first review should finish by end of this month, executing the following calendar:
* Reviewing chapter sends comments to leader of reviewed chapter, with cc to fiware-wpl and fiware-wpa, by August 27, 09:00am (delivery of revisions to be checked in our follow-up confcall at 11:00am)
* Each chapters implement recommended changes by peer-reviewer as well as comments from official reviewers provided in the official FI-WARE review reports: August 31st, 12:00pm CET
All WPLs/WPAs should book enough resources the week starting on August 27th to be able to implement their revision.
Best regards,
-- Juanjo
-------------
Product Development and Innovation (PDI) - Telefonica Digital
website: www.tid.es<http://www.tid.es>
email: jhierro at tid.es<mailto:jhierro at tid.es>
twitter: twitter.com/JuanjoHierro
FI-WARE (European Future Internet Core Platform) Chief Architect
You can follow FI-WARE at:
website: http://www.fi-ware.eu
facebook: http://www.facebook.com/pages/FI-WARE/251366491587242
twitter: http://twitter.com/FIware
linkedIn: http://www.linkedin.com/groups/FIWARE-4239932
________________________________
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
_______________________________________________
Fiware-wpa mailing list
Fiware-wpa at lists.fi-ware.eu<mailto:Fiware-wpa at lists.fi-ware.eu>
http://lists.fi-ware.eu/listinfo/fiware-wpa
________________________________
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/fiware-wpa/attachments/20120827/14111441/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy