[Fiware-cloud] IMPORTANT: Next Steps

Edmonds, AndrewX andrewx.edmonds at intel.com
Fri Sep 23 11:29:29 CEST 2011


 

I’ve added additional pieces below (yellow). Apologies for the delay.



Andy


Hi All, 

It was great to see many of you in Turino last week. 

First, I'm out of office tomorrow, so there will be no weekly call. However,
I would like us to make progress offline, as follows. 

1. Highlights and action items from the F2F at Turin 
Please, send me your notes regarding highlights (main accomplishments and
issues) and action items from the F2F discussions last week. I will
consolidate them and will send to Juanjo (per his request). 
For your convenience, here is a list of sessions: 

*	General -- main accomplishments: 

*	Socializing among team members, including additional team members
which did not attend the kick-off in May. Improved team atmosphere and
trust. 
*	Gained common understanding of the architecture, main assets,
interfaces, potential integration challenges and gaps -- for the entire WP
as a whole, as well as for individual GEs 
*	Identified several significant gaps (see below), some of which may
become topics for open calls 
*	Conducted highly productive joint sessions with other WPs (see more
details below) 

*	Met in person key representatives of other teams, thus improving
future collaboration 
*	Gained better understanding of what other WPs are doing 
*	Identified and verified potential integration points and assets/GEs
that can be leveraged

*	Cloud Edge, Cloud Edge RM [Serge, Alex] 

*	Reviewed the architecture of the Cloud Proxy 
*	Reviewed end-to-end scenario of provisioning of an application
hosted in the cloud, having a component designed to run close to the
end-user (on a Cloud Proxy) 
*	Refined WP architecture to address the distinction between the Cloud
Proxy device (running outside of the centralized cloud infrastructure) and
the management component that would typically run within the centralized
infrastructure and act as a proxy between the centralized cloud management
stack and the numerous Cloud Proxy devices located close to the end-uses. 
*	Identified a gap in providing the above management component. 

*	Action Item [Serge]: find out whether this gap can be contained
(e.g., by re-balancing the Cloud Proxy related work between WP4 and WP7). 

*	Note: this issue was discussed at the PCC, and it was mentioned that
the chances to be able to handle this gap via the open calls mechanisms are
not high (as this is a mandatory component to provide the end-to-end
functionality of Cloud Proxy, which should have been taken into account in
the original plan)

*	 
*	IaaS Service Management [Fernando] 

*	TBD 
*	It should be possible to design services that comprise components
that run on Cloud Proxy (and potentially also end-devices -- see comment
from I2ND interlock), as well as object storage resources. This should be
reflected in service manifest, as well as handled during provisioning and
life cycle management of services. It must be studied.
*	A service composition tool should be part of the ecosystem provided
to the application developer/provider. Should be considered for the Open
Call. A Service composition tool should be part of the Portal or a specific
tool provided by the specific WP within FI-WARE (TBD). IMHO It is not part
of the SM. 
*	Scalability and security aspects of Claudia should be considered.
The security aspects must be applied to all GE. BTW, we need more discussion
about this topics due to we need to clarify all the security requirements.

*	How do we store/mngt. the credentials (e.g. EC2 Amazon)? [AI
Fernando]
*	What is the possibility of scaling Claudia? [AI Fernando]
*	It is possible to update the service manifest dynamically (I suppose
yes) [AI Fernando]
*	There are not trivial dependencies between Claudia and IaaS Data
Center Mngt.
*	Why do we need to use clone VMs? Can we provide some UCs?
*	Integration with SLA-SLO. Which type of SLA we are using. How
Claudia manages the SLAs?
*	Interoperability between Cloud Standard API (DMTF CIMI) and OCCI
through OVF. Especify the OVF exchanges messages in common (the same for
CDMI could be applied) [AI Fernando Andy Alex]

*	OGF33: Venus-C (venus-c.eu) has a OVF to OCCI tool

*	France telecom participation in WP4 discussed
*	Gap related to billing/accounting noted

*	 
*	PaaS [Fernando] 

*	TBD 
*	The current approach for PaaS provisioning is to install middleware
components into an existing running OS (with Chef), which has been installed
separately (in our case -- as part of the provisioning of the corresponding
VM). A unified approach should be considered, in which the VM images already
include the middleware components pre-installed, and they just need to be
customized during provisioning

·          

*	It is not clear whether OVF-based manifest would be a good fit to
describe PaaS-level services. Other alternatives should be considered. We
prefer to extend a common standard API (OVF) and not use another one from
the beginning. We want to use the same protocol that we are using in the SM.
Also the interface that PaaS GE provide is Cloud Standard API based on OVF.

*	How can we specify the elasticity rules in terms of PaaS? [AI
Fernando]
*	Why do we use Chef for the PaaS? [AI Fernando]

*	 
*	IaaS DataCenter Resource Management [Alex, Andy, Fernando] 

*	Reviewed WP architecture, mapped assets and gaps 
*	A need for common monitoring infrastructure was stressed 
*	The resource management layer should provide capability of
orchestrating operations across groups of VMs -- e.g., in a scenario of
service snapshot. 
*	We should consider supporting non-virtualized workloads
*	proximity policies
*	translate the requirements of the SM to the policies of the CDRM
*	number of WP7 folks are interested in Network-as-a-Service,
something that OpenStack/Quantum can provide – @andy to discuss further with
respective WP7 people

 

*	 
*	Object Storage [Andy, Fernando] 

*	Interface to openflow (?)

*	This is NOT related to Object Storage.

*	Cloud Standard API - CMDI - OVF interoperability 

*	Action Item [Fernando]: CDMI interface specification of the SM
*	@andy Further investigations required for CDMI on swift

*	Self-Service Interfaces [Juaquin] 

*	A collaboration-driven approach to Cloud Portal was presented 
*	Action Item [Alex, Joaquin]: assess whether this can be contained
within the existing funding. It might make sense to focus on have a
fully-functional cloud portal as a subject for an Open Call.
*	where is the user management? permission, accounting, etc


*	How to manage the SSO? and how to translate it to each GE? 

 

*	Monitoring [Andy] 

*	Monitoring architecture presented
*	Noted that Analysis should cover both online (e.g. CEP) and offline
(e.g. MapReduce)
*	Noted that Storage should cover both optimized time series storage
(e.g. rrdtool, graphite) and BigData storage (e.g. Hadoop/HDFS)
*	Metric sources should have the possibility to be configured
(policies) from a central location 
*	Visualisation noted as a deficiency and possibly subject to an open
call

*	Security [Andy] 

*	Presented extracted security requirements
*	Andy to continue as mediator between WP4 and WP8
*	Representative pleased to see WP4’s consideration of requirements
*	@all Plan to 1st specify WP4 EPICs and then add/modify to account
for security requirements
*	Noted that OpenStack keystone can be considered as an asset
providing SSO

*	Interlock with I2ND 

*	It was mentioned that in some cases a cloud application may include
a component designed to run at the end-user device (e.g., a mobile phone) --
either within the Web browser, or as a 'rich client' component. In a way,
this can be considered as another 'tier', besides the centralized cloud
infrastructure and the cloud proxy. This should be taken into account when
designing the service manifest, as well as during provisioning and service
life cycle management.
*	Interest in Network as a Service from WP7 people. Need to understand
better integration point here.

*	Interlock with Security [Andy] 

*	Reviewed security considerations which might apply to Cloud Hosting.
How to protect the services in the Cloud? 

*	Action Item [Andy to coordinate]: need to refine our security
considerations in the HLD (once transferred to the Wiki)

*	It was noted that the security WP is interested in leveraging the
common infrastructure for monitoring and CMDB. Cloud Hosting does not intend
having a centralized CMDB, but having a single monitoring system which can
be augmented with security probes definitely makes sense. 

*	Action Item [Alex] need to follow-up on monitoring infrastructure,
across GEs and WPs

*	Interlock with Apps [David] 

*	In order to drive business processes related to applications
deployed in the cloud (e.g., SLAs), resource-related metrics produced by
Cloud WP components must be accessible by the components of the Apps WP. 
*	Mashup execution engines might be hosted on the cloud (PaaS would
probably make more sense than IaaS)
*	If we move one service from one Data Center to another. How does the
user know the way to access it?
*	There is a need from the WP to have WP4 services described as USDL

 

*	Interlock with Data [Andy, David] 

*	In order to develop a common monitoring system, 3 components have
been identified that will be provided by the Data Management WP: pub/sub
broker, Big Data and Complex Event Processing. Need to follow-up on
architecture, requirements, interfaces, schedule, etc.
*	Presented monitoring architecture using GEs as building blocks

Of course, not only the people mentioned above can contribute. Please, send
me your input by EOD Wednesday. Make it brief (concise bullets). 

2. Epics spreadsheets 
As you know, we need to come up with a list of Epics for each GE, outlining
the main areas of work we envision in the project (focusing on the first
release). 
Please, send me by the end of the week your initial lists, with some details
for each Epic. Let's follow the format in the attached Excel -- it is an
'optimized' version of the original template (I've copied few of Fernando's
epics into the new table format, as an example). 
Please, remember that the work items should focus on work that is still to
be done, by our team. So, when considering various assets, the work items
should only refer to their integration and enhancements -- and not to
features which are already there, or are developed by someone else. 
There are many cool features in Excel that can potentially make the usage of
Excel to manage the Epics rather convenient, but let's wait until the Agile
tooling topics becomes more clear (I'm not sure Tracker is better than
Excel, for our internal use). 

Let's discuss both topics in our next week's call, following the input that
each of us provides. 

Thanks! 
Alex 

[attachment "Backlog entries description v0.1 TID - Alex.xls" deleted by
Alex Glikson/Haifa/IBM] _______________________________________________
Fiware-cloud mailing list
Fiware-cloud at lists.fi-ware.eu
 <http://lists.fi-ware.eu/listinfo/fiware-cloud>
http://lists.fi-ware.eu/listinfo/fiware-cloud

<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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20110923/600d989d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20110923/600d989d/attachment.bin>
-------------- next part --------------
-------------------------------------------------------------
Intel Ireland Limited (Branch)
Collinstown Industrial Park, Leixlip, County Kildare, Ireland
Registered Number: E902934

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


More information about the Old-Fiware-cloud mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy