I was wondering if some of this could be solved by simply using rpc.call vs rpc.cast so that we get appropriate responses, even if they are exceptions.
- Chris On Aug 26, 2011, at 2:23 PM, Brian Lamar wrote: > Hey Ed, > > I absolutely agree that we need to be confident that all requests will be > handled by the system eventually. However, I'm unsure of the need for a new > service to be created to handle error cases. > > I'm not saying that we can solve every case through our current architecture, > but with some subtle tweaks I think it can be made much more reliable. I > feel like if we look at every place where errors *can* occur we can find > solutions not involving an external service. Are there any particular > bugs/situations that are happening which aren't listed as bugs in Launchpad? > > Long story short I'd rather not create an external service which attempts to > clean up after poor exception handling / bad logic, but there might be some > cases I'm not considering. > > Brian > > > > > -----Original Message----- > From: "Ed Leafe" <e...@leafe.com> > Sent: Friday, August 26, 2011 3:22pm > To: openstack@lists.launchpad.net > Subject: [Openstack] New nova service proposal > > Sorry I haven't come up with a snazzy name for it yet, but what I have > in mind is a new service that is essential for my employer (Rackspace), and > might be important for other OpenStack deployments. This new service would be > completely optional, of course - only those for whom it is relevant would run > it. > > Let me start by stating the problem: when a customer requests that we > create instances for them, nova casts those requests into the queue, where > they are eventually acted upon. That usually works great, but in cases where > the instance creation fails, we need to detect that failure and re-issue the > create request with a different host. This is currently not possible with the > asynchronous design of the compute-scheduler interactions. > > So what I envision is a service that scans a list of recent requests' > reservation IDs, and follows up to see if the request was successful or not, > and takes action if needed. The blueprint for this can be found at > https://blueprints.launchpad.net/nova/+spec/instance-creation-assurance, with > an Etherpad created for ongoing idea exchange at > http://etherpad.openstack.org/instance-creation-assurance > > > > -- Ed Leafe > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > This email may include confidential information. If you received it in error, > please delete it. > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp This email may include confidential information. If you received it in error, please delete it. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
