[Fiware-cloud] some suggestions

[Alex Glikson]

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/20120321/c4c1161e/attachment.html>