[cloud-workshop] Notes from OSGi Cloud Workshop at Eclipsecon

David Bosschaert david at redhat.com
Thu Mar 29 17:05:38 EDT 2012


Hi all,

Thanks for joining the discussion today. I thought it was a highly 
productive and enjoyable morning.

I took some notes of the topics that were brought forward during the 
meeting. Please find them below. Do let me know if I captured something 
incorrectly or something is missing.
Also, if you're interested in taking part in the further technical 
design of any of these, do let me and/or co-chair Tim Diekmann (tdiekman 
at tibco.com) know and we will fill you in on how to get involved in the 
EEG.

Best regards,

David Bosschaert
OSGi EEG co-chair

BTW I'm planning to collect the presentations that were given here: 
http://www.osgi.org/Design/Cloud
----
Below you can find the topics that were proposed today as areas to work 
on in the OSGi Enterprise Expert Group in the context of Cloud 
Computing. The list is not in any particular order.

Topic: Make it possible to describe various Service unavailable States. 
A service may be unavailable in the cloud because of a variety of reasons.
Maybe the amount of invocations available to you have exhausted for today.
Maybe your credit card expired
Maybe the node running the service crashed.
It should be possible to model these various failure states and it 
should also be possible to register 'callback' mechanisms that can deal 
with these states in whatever way is appropriate (blacklist the service, 
wait a while, send an email to the credit card holder, etc).

Topic: WYTIWYR (What you test is what you run) It should be possible to 
quickly deploy and redeploy.
There was an additional use-case around reverting the data (and 
configuration) changes made during an upgrade. If we need to downgrade 
after an upgrade then we may need to convert the data/configuration back 
into its old state. Peter Kriens says that there had been a lot of 
discussion about reverting deployments in the past and that it was 
decided not to support it.
Stefan Derdak: you need to be careful of feature creep in the framework. 
This seems to outside of the realm of the framework.
David Bosschaert: possibly it can already be addressed with the current 
building blocks. Maybe a whitepaper could help?

Topic: Come up with a common and agreed architecture for Discovery. This 
should include consideration of Remote Services, Remote Events and 
Distributed Configuration Admin.

Topic: Using OSGi in the cloud should be super easy and frictionless.

Topic: Resource utilization. It should be possible to measure/report 
this for each cloud node. Number of threads available, amount of memory, 
power consumption etc… Possibly create OSGi Capability namespaces for this.

Topic: OBR scaling. Need to be able to use OBR in a highly available 
manner. Should support failover and should hook in with discovery.

Topic: We need subsystems across frameworks. Possibly refer to them as 
'Ecosystems'. These describe a number of subsystems deployed across a 
number of frameworks.

Topic: Asynchronous services and asynchronous remote services.

Topic: Isolation and security for applications
For multi-tenancy
Protect access to file system
Lifecycle handling of applications
OBR - isolated OBR (multiple tenants should not see each other's OBR)
This all needs to be configurable

Topic: It should be possible to look at the cloud system state:
where am I (type of cloud, geographical location)?
what nodes are there and what is their state?
what frameworks are available in this cloud system?
where's my OBR?
what state am I in?
what do I need here in order to operate?
etc…

Topic: There should be a management mechanism for use in the cloud
JMX? Possibly not
REST? Most likely
Management of application state should also be possible in addition to 
bundle/framework state

Topic: Deployment - when deploying replicated nodes it should be 
possible to specify that the replica should *not* be deployed on certain 
nodes, to avoid that all the replicas are deployed on the same node.

Topic: Review all OSGi service specifications for suitability in the cloud.



More information about the cloud-workshop mailing list