[Fiware-cloud] some suggestions

[Heijnen Henk]

Hello,

One of the goals of the cloud edge is to be able to maintain some local activity even if the data link is down (simple example: if you have a heating / airco management running in the cloud (with nice server features, a link with the weather forecast etc ...), you want to be sure that in case the link falls down, your local device (the cloud edge) can continue to control the local devices and, at least works on maintaining the programmed temperature).
To answer to another question about redundancy (power supply or HD), I would say that we must keep in mind that we are speaking about consumer electronics grade devices. A low cost is one of the main points when designing such devices and therefore, I don't think we can afford such extra features ...

Regards
H

Henk  HEIJNEN
Manager, Cooperative Projects - Digital Delivery Coordinator
[cid:image001.jpg at 01CD0772.73038890]                  [cid:image002.png at 01CD0772.73038890]
Technology & Research
Funded & Cooperative Programs
1, Avenue de Belle Fontaine - CS 17616
35576 Cesson-Sévigné cedex - FRANCE
Tél:  +33 2 99 27 33 08 -  GSM: +33 6 72 39 26 24


From: fiware-cloud-bounces at lists.fi-ware.eu [mailto:fiware-cloud-bounces at lists.fi-ware.eu] On Behalf Of Alex Glikson
Sent: mercredi 21 mars 2012 14:21
To: Lorenzo Cantelmi
Cc: Denis Caromel; fiware-cloud at lists.fi-ware.eu
Subject: Re: [Fiware-cloud] some suggestions

Regarding the cloud proxy.. Well, I guess it depends on your reference for comparison. If you compare to 'regular' cloud-based application, you have code running on the 'client' device (could be Web browser, or something else), and code running in the 'cloud'. When your router dies, you lose connectivity to the cloud, and hence what is left is the code running on the client side, and the ability to continue working with the application depends on the capabilities of the client-side code (ranging from total outage to being able to fully continue in a disconnected mode). Now, depending on the exact assumptions regarding the role of 'cloud proxy' in this scenario -- you may or may not require 'enhanced' availability.

Alex




From:        Lorenzo Cantelmi <lorenzo.cantelmi at inria.fr>
To:        Alex Glikson/Haifa/IBM at IBMIL,
Cc:        Denis Caromel <denis.caromel at sophia.inria.fr>, fiware-cloud at lists.fi-ware.eu, fiware-cloud-bounces at lists.fi-ware.eu
Date:        21/03/2012 01:29 PM
Subject:        Re: [Fiware-cloud] some suggestions
________________________________



Alex,

thanks for having appreciated it. :-) . Just to be clearer than before:

 *   ok, TCP stands for Trusted Compute Pools (in this context), but in the same part is mentioned as Trusted Pool Computing (so tpc should be right. Moreover, tcp should create misunderstanding with TCP protocol acronym);
 *   It is also the case for regular 'router' -- if it dies, you can not access the Internet at all. Maybe I was not so clear in what I meant (sorry for that): nowadays, if a router fails you can still do stuff on your local host (i.e. laptop, etc), but for instance if you are working locally with your vApp, hosted on your cloud proxy, and then HW fails, you can not continue doing your stuff at all.

Regards,

Lorenzo
________________________________

From: "Alex Glikson" <GLIKSON at il.ibm.com>
To: "Lorenzo Cantelmi" <lorenzo.cantelmi at inria.fr>
Cc: "Denis Caromel" <denis.caromel at sophia.inria.fr>, fiware-cloud at lists.fi-ware.eu, fiware-cloud-bounces at lists.fi-ware.eu
Sent: Wednesday, 21 March, 2012 11:40:18 AM
Subject: Re: [Fiware-cloud] some suggestions

Lorenzo,

Thanks for your comments. Nice to know that someone is actually reading the documentation that we produce :-) See few comments inline below.

Further comments/suggestions are more than welcome!

Regards,
Alex




From:        Lorenzo Cantelmi <lorenzo.cantelmi at inria.fr>
To:        fiware-cloud at lists.fi-ware.eu,
Cc:        Denis Caromel <denis.caromel at sophia.inria.fr>
Date:        21/03/2012 12:04 PM
Subject:        [Fiware-cloud] some suggestions
Sent by:        fiware-cloud-bounces at lists.fi-ware.eu
________________________________



Hi all,

I make my own humble suggestions for wiki, that could be interesting:

 *   in the Guiding Design Principles at this page<http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Cloud_Hosting_Architecture_%28PRELIMINARY%29>  we should insert the reference to NIST Roadmap and similar; we have added links within individual paragraphs, but maybe should also add one when mentioning NIST for the first time.
 *   in the FIware Extensions [here<http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Cloud.DCRM>], at 2. point it is probably tpc, instead of tcp; TCP stands for Trusted Compute Pools (in this context).
 *   in the Components subsection [here<http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Cloud.SM>], at bullet Provisioning it is written that Provisioning is "responsible of deleting the actions that, it takes from the Action Queue", but you can not deduce it from the relative picture: basically a feedback arrow is missing; Fernando -- please, take a look if we need to update the diagram.
 *   about Cloud Edge chapter, Cloud Proxy is basically a router evolved till application layer, a cloud consumer directly (via connection) will work with. So, assuming its hardware fails, consumer is stuck and can not work with deployed applications/services.  In the light of that, I guess we should specify that cloud proxy should assure redundancy HW (supply, hdd, etc). It is also the case for regular 'router' -- if it dies, you can not access the Internet at all. But I agree that specifying some design principles for Cloud Edge could be a good idea, including availability/ resiliency considerations. Pascal -- can you, please, take a look?
 *   we use to speak about QoS, but, according with FG Cloud Technical Report Part 1<http://www.itu.int/en/ITU-T/focusgroups/cloud/Documents/FG-coud-technical-report.zip> (III.2 Details on SLA measurement subsection, page 54 - 59 if we consider the offset), in such a new cloud environment we should speak of 2QoS, that stands for Quality and Quantity of Service, to remark the evolution/innovation of the scenario we are offering. I don not know if this acronym is already in use, but sounds good for me. what do you think about? I'm not sure how much will we be able to invest in the direction within the current scope -- so I wouldn't necessarily want to create the perception that we plan major innovation in this direction. In any case, this is not a high priority for the first release. If it changes -- it would make sense to update the corresponding description (which will be updated towards the second release anyway).
Let me know your kind opinions.


Ciao,

Lorenzo_______________________________________________
Fiware-cloud mailing list
Fiware-cloud at lists.fi-ware.eu
http://lists.fi-ware.eu/listinfo/fiware-cloud

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20120321/16417cb4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 16662 bytes
Desc: image001.jpg
URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20120321/16417cb4/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 2226 bytes
Desc: image002.png
URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20120321/16417cb4/attachment.png>