Difference between revisions of "Fedcloud-tf:WorkGroups:Scenario6"

From EGIWiki
Jump to: navigation, search
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Fedcloud-tf:Menu}} {{Fedcloud-tf:WorkGroups:Menu}} {{TOC_right}}
+
{{Fedcloud-tf:Menu}} {{Fedcloud-tf:WorkGroups:Menu}} {{TOC_right}}  
  
= Scenario 6: VM/Resource state change notification  =
+
= [Closed] Scenario 6: VM/Resource state change notification  =
  
<font color="red">Leader: Peter Solagna, EGI</font>
+
<font color="red">Leader: Peter Solagna, EGI</font>  
  
The scenario enables:
+
The scenario enables:  
* Resource providers to notify interested parties about changes in the user's VM state of a proposed state change in the VMM.
 
* End user to build automated VM management and reactive workflows in user space.
 
  
Such notification system must enable automatic notification consumers and so there is the need to identify the standards to be used:
+
*Resource providers to notify interested parties about changes in the user's VM state of a proposed state change in the VMM.
* Standard for the payload in the notification messages
+
*End user to build automated VM management and reactive workflows in user space.
* Standard for the messages transport
 
  
If such standards are available in the federated cloud infrastructure, the users will be able to implement monitoring/management tools for their workflows.
+
Such notification system must enable automatic notification consumers and so there is the need to identify the standards to be used:
  
== Steps for the scenario fulfillment ==
+
*Standard for the payload in the notification messages
=== Information gathering steps ===
+
*Standard for the messages transport
The steps I identify to have a comprehensive description of the current situation:
 
# List the notification systems adopted by the technologies currently deployed in the FedClouds testbeds.
 
## Collect requirements and use cases from the users communities.
 
# List the currently available standards available, and map them - if possible - to the technologies implemented in the testbed.
 
# Map the users requirements to the existing implementations and standards. Assess if there are missing features in the current implementations and standards.
 
# Identify if there are standards eligible to be suggested as common standards.
 
  
=== Operative steps ===
+
If such standards are available in the federated cloud infrastructure, the users will be able to implement monitoring/management tools for their workflows.  
When the points above are done, I suggest the following, operative, tasks:
 
<ol start="5">
 
<li>Technology providers should provide the status change notifications through standard formats and transport protocols.</li>
 
<li>User communities should test these notification mechanisms in their workflows, or implementing a client prototype.</li>
 
</ol>
 
  
'''Comments to the steps list, or about any other aspect of the scenario are more than welcome'''
+
== Steps for the scenario fulfillment  ==
  
== Scenario collaborators ==
+
=== Information gathering steps  ===
{| border="1"  
+
 
!Role
+
The steps I identify to have a comprehensive description of the current situation:
!Institution
+
 
!Name
+
#List the notification systems adopted by the technologies currently deployed in the FedClouds testbeds.
 +
##Collect requirements and use cases from the users communities.
 +
#List the currently available standards available, and map them - if possible - to the technologies implemented in the testbed.
 +
#Map the users requirements to the existing implementations and standards. Assess if there are missing features in the current implementations and standards.
 +
#Identify if there are standards eligible to be suggested as common standards.
 +
 
 +
=== Operative steps  ===
 +
 
 +
When the points above are done, I suggest the following, operative, tasks:
 +
 
 +
#Technology providers should provide the status change notifications through standard formats and transport protocols.
 +
#User communities should test these notification mechanisms in their workflows, or implementing a client prototype.
 +
 
 +
'''Comments to the steps list, or about any other aspect of the scenario are more than welcome'''
 +
 
 +
== Scenario collaborators ==
 +
 
 +
{| border="1"
 
|-
 
|-
|Scenario leader
+
! Role
|EGI.eu
+
! Institution
|Peter Solagna
+
! Name
 
|-
 
|-
|Collaborator
+
| Scenario leader
| OeRC
+
| EGI.eu
| Matteo Turilli
+
| Peter Solagna
 
|-
 
|-
|Collaborator
+
| Collaborator  
|
+
| OeRC
|
+
| David Wallom
 +
|-
 +
| Collaborator
 +
| Jan Meizner
 +
| CYFRONET
 
|}
 
|}
  
== Step 1: List the notification systems currently adopted ==
+
== Step 1: List the notification systems currently adopted ==
{| border="1"  
+
 
!VM Manager
+
{| border="1"
!What is automatically notified
 
!Any standard in the message format used
 
!Message transport protocol
 
 
|-
 
|-
|Open Nebula
+
! VM Manager
| states of VM
+
! What is automatically notified
| NO
+
! Any standard in the message format used
 +
! Message transport protocol
 +
|-
 +
| Open Nebula  
 +
| states of VM  
 +
| NO  
 
| Users have to query explicitly the result are in XML
 
| Users have to query explicitly the result are in XML
 
|-
 
|-
|CloudSigma
+
| CloudSigma  
|
+
|  
|
+
|  
|
+
|  
 
|-
 
|-
|OpenStack
+
| OpenStack  
| Not clear yet, still at blueprint stage<ref name="NovaNotification">http://wiki.openstack.org/NotificationSystem</ref><ref>https://blueprints.launchpad.net/nova/+spec/notification-system</ref><ref>https://blueprints.launchpad.net/openstack-devel/+spec/notification-and-statistics</ref>
+
| Not clear yet, still at blueprint stage<ref name="NovaNotification">http://wiki.openstack.org/NotificationSystem</ref><ref>https://blueprints.launchpad.net/nova/+spec/notification-system</ref><ref>https://blueprints.launchpad.net/openstack-devel/+spec/notification-and-statistics</ref>  
| Atom 1.0<ref name="NovaNotification"/>
+
| Atom 1.0<ref name="NovaNotification" />  
| PubSubHubbub (PSH)<ref name="NovaNotification"/>
+
| PubSubHubbub (PSH)<ref name="NovaNotification" />
 
|-
 
|-
|WNoDeS
+
| WNoDeS  
|States of VM: RUNNING, PENDING, ABORTED, DESTROYED
+
| States of VM: RUNNING, PENDING, ABORTED, DESTROYED  
|No
+
| No  
|Users have to query explicitly the result are in XML
+
| Users have to query explicitly the result are in XML
 
|-
 
|-
|StratusLab
+
| StratusLab  
|
+
|  
|
+
|  
|
+
|  
 
|}
 
|}
  
== Step 2: List of the standard available for notification message ==  
+
== Step 2: List of the standard available for notification message ==
 +
 
 
{| border="1"
 
{| border="1"
! Standard name
+
|-
! Message Format/Transport
+
! Standard name  
 +
! Message Format/Transport  
 
! Comments and information
 
! Comments and information
 
|-
 
|-
|Atom 1.0
+
| Atom 1.0  
|Message Format
+
| Message Format  
|Implemented by OpenStak
+
| Implemented by OpenStak
 
|-
 
|-
|PubSubHubbub
+
| PubSubHubbub  
|Transport
+
| Transport  
|Implemented by OpenStak
+
| Implemented by OpenStak
 
|}
 
|}
  
== References ==
+
== References ==
<references/>
+
 
 +
<references />  
 +
 
 +
= Input for blueprint  =
 +
 
 +
== Description of the scenario6: Notification system ==
 +
 
 +
=== Use cases for this scenario  ===
 +
 
 +
=== Available technologies  ===
 +
 
 +
== Operative steps  ==
  
= Input for blueprint =  
+
=== Test ActiveMQ based technologies  ===
== Description of the scenario6: Notification system==
 
  
== Use cases for this scenario ==
+
*Technology providers deploying Stratuslab 1.2 or higher. '''Who is deploying it currently?'''
== Available technologies ==
+
*Configure a messaging broker to be used by the cloud service (EGI test brokers network is an option)
== Operative steps ==
+
*Implement a client to consume the messages (it needs to implement the ActiveMQ libraries)
 +
*Submit a virtual machine request and use the client to listen to the messages
  
=== Test ActiveMQ based technologies ===
 
 
== Results of the scenario tests ==
 
== Results of the scenario tests ==

Latest revision as of 10:26, 20 April 2015

Main Roadmap and Innovation Technology For Users For Resource Providers Media


Workbenches: Open issues
Scenario 1
VM Management
Scenario 2
Data Management
Scenario 3
Information Systems
Scenario 4
Accounting
Scenario 5
Monitoring
Scenario 6
Notification
Scenario 7
Federated AAI
Scenario 8
VM Image Management
Scenario 9
Brokering
Scenario 10
Contextualisation
Scenario 11
Security



[Closed] Scenario 6: VM/Resource state change notification

Leader: Peter Solagna, EGI

The scenario enables:

  • Resource providers to notify interested parties about changes in the user's VM state of a proposed state change in the VMM.
  • End user to build automated VM management and reactive workflows in user space.

Such notification system must enable automatic notification consumers and so there is the need to identify the standards to be used:

  • Standard for the payload in the notification messages
  • Standard for the messages transport

If such standards are available in the federated cloud infrastructure, the users will be able to implement monitoring/management tools for their workflows.

Steps for the scenario fulfillment

Information gathering steps

The steps I identify to have a comprehensive description of the current situation:

  1. List the notification systems adopted by the technologies currently deployed in the FedClouds testbeds.
    1. Collect requirements and use cases from the users communities.
  2. List the currently available standards available, and map them - if possible - to the technologies implemented in the testbed.
  3. Map the users requirements to the existing implementations and standards. Assess if there are missing features in the current implementations and standards.
  4. Identify if there are standards eligible to be suggested as common standards.

Operative steps

When the points above are done, I suggest the following, operative, tasks:

  1. Technology providers should provide the status change notifications through standard formats and transport protocols.
  2. User communities should test these notification mechanisms in their workflows, or implementing a client prototype.

Comments to the steps list, or about any other aspect of the scenario are more than welcome

Scenario collaborators

Role Institution Name
Scenario leader EGI.eu Peter Solagna
Collaborator OeRC David Wallom
Collaborator Jan Meizner CYFRONET

Step 1: List the notification systems currently adopted

VM Manager What is automatically notified Any standard in the message format used Message transport protocol
Open Nebula states of VM NO Users have to query explicitly the result are in XML
CloudSigma
OpenStack Not clear yet, still at blueprint stage[1][2][3] Atom 1.0[1] PubSubHubbub (PSH)[1]
WNoDeS States of VM: RUNNING, PENDING, ABORTED, DESTROYED No Users have to query explicitly the result are in XML
StratusLab

Step 2: List of the standard available for notification message

Standard name Message Format/Transport Comments and information
Atom 1.0 Message Format Implemented by OpenStak
PubSubHubbub Transport Implemented by OpenStak

References

Input for blueprint

Description of the scenario6: Notification system

Use cases for this scenario

Available technologies

Operative steps

Test ActiveMQ based technologies

  • Technology providers deploying Stratuslab 1.2 or higher. Who is deploying it currently?
  • Configure a messaging broker to be used by the cloud service (EGI test brokers network is an option)
  • Implement a client to consume the messages (it needs to implement the ActiveMQ libraries)
  • Submit a virtual machine request and use the client to listen to the messages

Results of the scenario tests