[Openstack] [Orchestration] Handling error events ... explicit vs. implicit

2011-12-07 Thread Sandy Walsh
For orchestration (and now the scheduler improvements) we need to know when an operation fails ... and specifically, which resource was involved. In the majority of the cases it's an instance_uuid we're looking for, but it could be a security group id or a reservation id. With most of the

Re: [Openstack] [Orchestration] Handling error events ... explicit vs. implicit

2011-12-07 Thread Mark Washenberger
Can you talk a little more about how you want to apply this failure notification? That is, what is the case where you are going to use the information that an operation failed? In my head I have an idea of getting code simplicity dividends from an everything succeeds approach to some of our

Re: [Openstack] [Orchestration] Handling error events ... explicit vs. implicit

2011-12-07 Thread Sandy Walsh
@lists.launchpad.net] on behalf of Mark Washenberger [mark.washenber...@rackspace.com] Sent: Wednesday, December 07, 2011 11:53 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] [Orchestration] Handling error events ... explicit vs. implicit Can you talk a little more about how you want

Re: [Openstack] [Orchestration] Handling error events ... explicit vs. implicit

2011-12-07 Thread Mark Washenberger
Subject: Re: [Openstack] [Orchestration] Handling error events ... explicit vs. implicit Can you talk a little more about how you want to apply this failure notification? That is, what is the case where you are going to use the information that an operation failed? In my head I have an idea

Re: [Openstack] [Orchestration] Handling error events ... explicit vs. implicit

2011-12-07 Thread Sandy Walsh
...@rackspace.com] Sent: Wednesday, December 07, 2011 12:36 PM To: openstack@lists.launchpad.net Subject: Re: [Openstack] [Orchestration] Handling error events ... explicit vs. implicit Gotcha. So the way this might work is, for example, when a run_instance fails on compute node, it would publish

Re: [Openstack] [Orchestration] Handling error events ... explicit vs. implicit

2011-12-07 Thread Yun Mao
Hi Sandy, I'm wondering if it is possible to change the scheduler's rpc cast to rpc call. This way the exceptions should be magically propagated back to the scheduler, right? Naturally the scheduler can find another node to retry or decide to give up and report failure. If we need to provision

Re: [Openstack] [Orchestration] Handling error events ... explicit vs. implicit

2011-12-07 Thread Sandy Walsh
To: Sandy Walsh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Orchestration] Handling error events ... explicit vs. implicit Hi Sandy, I'm wondering if it is possible to change the scheduler's rpc cast to rpc call. This way the exceptions should be magically propagated back

Re: [Openstack] [Orchestration] Handling error events ... explicit vs. implicit

2011-12-07 Thread Sandy Walsh
...@rackspace.com] Sent: Wednesday, December 07, 2011 1:55 PM To: Yun Mao Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Orchestration] Handling error events ... explicit vs. implicit True ... this idea has come up before (and is still being kicked around). My biggest concern is what happens

Re: [Openstack] [Orchestration] Handling error events ... explicit vs. implicit

2011-12-07 Thread Michael Pittaro
On Wed, Dec 7, 2011 at 7:26 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: For orchestration (and now the scheduler improvements) we need to know when an operation fails ... and specifically, which resource was involved. In the majority of the cases it's an instance_uuid we're looking for,