[openstack-dev] [Nova][Heat][Horizon][Oslo] EventScheduler Service Proposal

Joshua Harlow harlowja at yahoo-inc.com
Fri May 3 04:58:51 UTC 2013


Sandy, do u mind expanding on how this might work with the existing event notification system (for something like orchestration). I'd like to understand maybe with a simple example of how it would operate.

I might have an idea of what you are thinking, but am not 100% sure :-)

Where u thinking about something like the following?

Entity A announces action X to occur via event notification, some group of Y fight over who gets to perform that action (using something like zookeeper perhaps?) then Y performs part #1 of the action X, then sends an event to get someone to do part #2 (which then again causes a zookeeper fight) and so on (until the last part happens and no more events are sent out). 

I might be on the right track, but am not so sure :-)
________________________________________
From: Sandy Walsh [sandy.walsh at rackspace.com]
Sent: Thursday, May 02, 2013 12:45 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Nova][Heat][Horizon][Oslo] EventScheduler Service Proposal

On 05/02/2013 04:31 PM, Adrian Otto wrote:
> Stackers,
>
> In this prior thread, is clear that multiple projects could make use of a utility service for the purpose of scheduling task-flows (workflows) or possibly Heat orchestrations to occur on regular intervals.
>
> http://lists.openstack.org/pipermail/openstack-dev/2013-April/008307.html
> http://lists.openstack.org/pipermail/openstack-dev/2013-May/008332.html
>
> Russel Bryant from the Nova team would like to use something to trigger capturing snapshots, and the auto-scale Heat developers would like something that allows them to trigger the scaling up and down of compute servers on a pre-determined schedule. There is potential value in offering an API service (integrated with Horizon) that can be exposed to end-users to trigger events to start on a schedule. Some discussion about the design of such a service has begun, and needs to be conducted in the open.
>
> I'd like to ask for your input on how the ideal solution would be designed. I have started a Wiki Page here as a starting point for the discussion:
>
> https://wiki.openstack.org/wiki/EventScheduler
>
> Questions to answer:
>
> 1) What features should be included?
> 2) Where should the service be incubated, and if/how it should be integrated with Oslo? The answer to this should indicate where the blueprints should be filed.
> 3) Are there volunteers to work on this?
>
> This solution will be designed primarily for simplicity and scalability. We can iterate on it to add features as use cases materialize for this.

For all of these efforts, be they the Orchestration effort or this
EventScheduler, I urge people to prefer an approach based on the
existing event notification system. It provides a great mechanism for
distributing state changes already.

So long as we're not building yet-another-notification system, I'm cool
which whatever state machine people settle on.

-S


>
> Thanks,
>
> Adrian
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list