Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On May 23, 2017, at 3:15 PM, melanie witt wrote: > > Removing the small VM driver from Nova would allow people to keep using what > they know (Nova API) but would keep a lot of cruft with it. So I would tend > to favor a new porcelain API. This. -- Ed Leafe

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

Thanks for the feedback, Curtis, appreciated! On 05/23/2017 04:09 PM, Curtis wrote: On Tue, May 23, 2017 at 1:20 PM, Edward Leafe wrote: On May 23, 2017, at 1:27 PM, James Penick wrote: Perhaps this is a place where the TC and Foundation should step in

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On Tue, 23 May 2017 20:58:20 +0100 (IST), Chris Dent wrote: If we're talking big crazy changes: Why not take the "small VM driver" (presumably nova-compute) out of Nova? What stays behind is _already_ orchestration but missing some features and having a fair few bugs. I've suggested this a

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On Tue, May 23, 2017 at 1:20 PM, Edward Leafe wrote: > On May 23, 2017, at 1:27 PM, James Penick wrote: > >> Perhaps this is a place where the TC and Foundation should step in and >> foster the existence of a porcelain API. Either by constructing something

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On Tue, 23 May 2017, James Penick wrote: I agree that a single entry point to OpenStack would be fantastic. If it existed, scheduling, quota, etc would have moved out of Nova a long time ago, and Nova at this point would be just a small VM driver. Unfortunately such a thing does not yet exist,

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On Tue, May 23, 2017 at 12:20 PM, Edward Leafe wrote: > > > Oh please, not Nova. The last word that comes to mind when thinking about > Nova code is “porcelain”. > Oh I dunno, porcelain is usually associated with so many every day objects. If we really push, we could see a

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On May 23, 2017, at 1:27 PM, James Penick wrote: > Perhaps this is a place where the TC and Foundation should step in and > foster the existence of a porcelain API. Either by constructing something > new, or by growing Nova into that thing. Oh please, not Nova. The last

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On Tue, May 23, 2017 at 8:52 AM, Jay Pipes wrote: > > If Heat was more widely deployed, would you feel this way? Would you > reconsider having Heat as one of those "basic compute services" in > OpenStack, then? > > (Caveat: I haven't looked at Heat in at least a year) I

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On 05/22/2017 03:36 PM, Sean Dague wrote: On 05/22/2017 02:45 PM, James Penick wrote: I recognize that large Ironic users expressed their concerns about IPMI/BMC communication being unreliable and not wanting to have users manually retry a baremetal instance launch. But, on

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On 05/23/2017 09:48 AM, Marc Heckmann wrote: For the anti-affinity use case, it's really useful for smaller or medium size operators who want to provide some form of failure domains to users but do not have the resources to create AZ's at DC or even at rack or row scale. Don't forget that as

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On 23 May 2017 at 05:33, Dan Smith wrote: > Sure, the diaper exception is rescheduled currently. That should > basically be things like misconfiguration type things. Rescheduling > papers over those issues, which I don't like, but in the room it surely > seemed like operators

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

I have to agree with James My affinity and anti-affinity rules have nothing to do with NFV. a-a is almost always a failure domain solution. I'm not sure we have users actually choosing affinity (though it would likely be for network speed issues and/or some sort of badly architected need or

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

In the case of baremetal in our environment, when a boot attempt fails we mark that node as being in maintenance mode, which prevents Nova from scheduling to it a second time. Then automation comes along and files repair tickets for the bad hardware. Only when a human or other automation fixes the

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On 05/22/2017 02:45 PM, James Penick wrote: > > > I recognize that large Ironic users expressed their concerns about > IPMI/BMC communication being unreliable and not wanting to have > users manually retry a baremetal instance launch. But, on this > particular point, I'm of the

Re: [Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

On Mon, May 22, 2017 at 10:54 AM, Jay Pipes wrote: > Hi Ops, > > Hi! > > For class b) causes, we should be able to solve this issue when the > placement service understands affinity/anti-affinity (maybe Queens/Rocky). > Until then, we propose that instead of raising a

[Openstack-operators] [nova][ironic][scheduler][placement] IMPORTANT: Getting rid of the automated reschedule functionality

Hi Ops, I need your feedback on a very important direction we would like to pursue. I realize that there were Forum sessions about this topic at the summit in Boston and that there were some decisions that were reached. I'd like to revisit that decision and explain why I'd like your support