[Fiware-cloud] some suggestions

[Alex Glikson]

Hi Henk, all,

I understand that the current Technicolor's approach is to focus on the 
consumer market. However, I think we agreed that in FI-WARE the focus will 
be broader, and will cover also use-cases of cloud edge devices installed 
in organizations (e.g., SMEs). In those cases, the tradeoff between price 
and other capabilities (such as availability, performance, capacity, etc) 
may be different. Although I don't expect this to be a high priority in 
the short-term, I think we definitely should address this in the longer 
term.

Regards,
Alex





From:   Heijnen Henk <henk.heijnen at technicolor.com>
To:     Alex Glikson/Haifa/IBM at IBMIL, 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 at lists.fi-ware.eu>
Date:   21/03/2012 03:57 PM
Subject:        RE: [Fiware-cloud] some suggestions



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
                  
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  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], at 2. point it is probably tpc, instead 
of tcp; TCP stands for Trusted Compute Pools (in this context). 
in the Components subsection [here], 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 (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/20120323/dfe7e305/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 16662 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20120323/dfe7e305/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 2226 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20120323/dfe7e305/attachment.png>