1 / 10

Scenario 6

Scenario 6. Peter Solagna – EGI.eu. VM/Resource state change notification. What scenario 6 enables: Resource providers to notify interested parties about changes in the user's VM state or a proposed state change in the VMM.

slowery
Télécharger la présentation

Scenario 6

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Scenario 6 Peter Solagna – EGI.eu

  2. VM/Resource state change notification What scenario 6 enables: • Resource providers to notify interested parties about changes in the user's VM state or a proposed state change in the VMM. • End user to build automated VM management and reactive workflows in user space. • Standards for the messages format and transport have to be explored

  3. What has been done Kick start of the scenario • Sent an email to the fedclouds ML • Request for collaboration • Request for use case from user communities • Identified the steps for the scenario fulfillment • Created the Wiki Page to collect: • Description of the scenario & steps • Collaborators for the working group • Summary tables for the notifications implemented by the technologies and the standards • Missing: timeline for the scenario fulfillment • Missing: only one collaborator joined Started the collection of notification sys. implementations

  4. Steps of Scenario 6 Information gathering steps • List the notification system adopted by the technology deployed in the testbed • Collect users requirements • List the currently available standards and map them into the technologies implemented in the testbed • Map users requirements into the notification mechanisms available in the testbed • Identify a core set of features. Identify if there are standards eligible to be suggested as common standards. Operative steps • 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. Missing steps? • …

  5. Notification systems currently in use

  6. Standards • I will extend this table by the next teleconf meeting – adding more columns for a comparative view of the features • Please, if you are familiar with other standards extend it adding new rows

  7. Active/Passive notifications • Active: resource provider sends a notification message to the user when the status of an owned VM changes, or when a specific event occurs • Passive: users poll all their VMs for their status • To implement any automated workflow passive notifications should be available through a PI • OpenStack enables active notification • OpenNebula enables only passive notification through the OCCI interface • Others Tech Providers?

  8. What users want? Scenario6, so far, has no support of users requirements  • Would the applications workflows implement active/passive VM status monitoring? • About what different users want to be notified? • Status changes • After an amount wall-clock time • Expected downtimes of the service • Would be useful for users to have periodic summary messages, containing statistics about the number of VMs running/suspended/.. • Would it be in scope? • Is it critical for users the encryption of notification messages? • Notifications shouldn’t contain sensitive data • Encrypted payload of the notification messages • HTTPS connection • Other?

  9. After the information gathering • Within the working group (and hopefully with some users representative), analyze the requirements, mapping them on the currently available technologies and standards • Agree on a set of features that are critical and should go into the blueprint • Start to testthose features on the Fedclouds-TF’s testbeds • How to test them? • Dummy “hello world” style? • Any chance to have real use case to test?

  10. Conclusions The work for the scenario is started but it needs to speed up • Collaborators • Now: for the information gathering/analysis process • Near future: for the use cases testing • Collect information about the current notifications system implemented (and planned) • Use cases from users

More Related