Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

>Affinity is mostly meaningless with baremetal. It's entirely a >virtualization related thing. If you try and group things by TOR, or >chassis, or anything else, it's going to start meaning something entirely >different than it means in Nova, I disagree, in fact, we need TOR and power

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

Someone else expressed this more gracefully than I: *'Because sans Ironic, compute-nodes still have physical characteristics* *that make grouping on them attractive for things like anti-affinity. I* *don't really want my HA instances "not on the same compute node", I want* *them "not in the same

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

Excerpts from Jim Rollenhagen's message of 2015-12-16 08:03:22 -0800: > Nobody is talking about running a compute per flavor or capability. All > compute hosts will be able to handle all ironic nodes. We *do* still > need to figure out how to handle availability zones or host aggregates, > but I

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

>We actually called out this problem in the Ironic midcycle and the Tokyo >summit - we decided to report Ironic's total capacity from each compute >host (resulting in over-reporting from Nova), and real capacity (for >purposes of reporting, monitoring, whatever) should be fetched by >operators

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

On 12/16/15 at 12:40pm, James Penick wrote: Affinity is mostly meaningless with baremetal. It's entirely a virtualization related thing. If you try and group things by TOR, or chassis, or anything else, it's going to start meaning something entirely different than it means in Nova, I disagree,

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

On Dec 10, 2015, at 15:57, Devananda van der Veen wrote: > So, at this point, I think we need to accept that the scheduling of > virtualized and bare metal workloads are two different problem domains that > are equally complex. > > Either, we: > * build a separate

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

On Wed, Dec 16, 2015 at 01:51:47PM -0800, James Penick wrote: > >We actually called out this problem in the Ironic midcycle and the Tokyo > >summit - we decided to report Ironic's total capacity from each compute > >host (resulting in over-reporting from Nova), and real capacity (for > >purposes

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

On Wed, 16 Dec 2015, melanie witt wrote: I’d rather we provided something like a more generic “Resource View API” in Nova that allows baremetal/container/clustered hypervisor environments to report resources via a REST API, and scheduling would occur based on the resources table (instead of

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

On Tue, Dec 15, 2015 at 05:19:19PM -0800, James Penick wrote: > > getting rid of the raciness of ClusteredComputeManager in my > >current deployment. And I'm willing to help other operators do the same. > > You do alleviate race, but at the cost of complexity and > unpredictability. Breaking

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

> getting rid of the raciness of ClusteredComputeManager in my >current deployment. And I'm willing to help other operators do the same. You do alleviate race, but at the cost of complexity and unpredictability. Breaking that down, let's say we go with the current plan and the compute host

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

Excerpts from James Penick's message of 2015-12-15 17:19:19 -0800: > > getting rid of the raciness of ClusteredComputeManager in my > >current deployment. And I'm willing to help other operators do the same. > > You do alleviate race, but at the cost of complexity and > unpredictability.

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

A question but what filtering/scheduling would be done in which place; any thoughts on the breakup between nova and ironic? If say ironic knows about all baremetal resources and nova doesn't know about them, then what kind of decisions can nova make during scheduling time? I guess the same

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

On Mon, Dec 14, 2015 at 04:15:42PM -0800, James Penick wrote: > I'm very much against it. > > In my environment we're going to be depending heavily on the nova > scheduler for affinity/anti-affinity of physical datacenter constructs, > TOR, Power, etc. Like other operators we need to also have a

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

I'm very much against it. In my environment we're going to be depending heavily on the nova scheduler for affinity/anti-affinity of physical datacenter constructs, TOR, Power, etc. Like other operators we need to also have a concept of host aggregates and availability zones for our baremetal as

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

> Thanks for summing this up, Deva. The planned solution still gets my > vote; we build that, deprecate the old single compute host model where > nova handles all scheduling, and in the meantime figure out the gaps > that operators need filled and the best way to fill them. Mine as well, speaking

Re: [openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

On Thu, Dec 10, 2015 at 03:57:59PM -0800, Devananda van der Veen wrote: > All, > > I'm going to attempt to summarize a discussion that's been going on for > over a year now, and still remains unresolved. > > TLDR; > > > The main touch-point between Nova and Ironic continues to be a

[openstack-dev] [Ironic] [Nova] continuing the "multiple compute host" discussion

All, I'm going to attempt to summarize a discussion that's been going on for over a year now, and still remains unresolved. TLDR; The main touch-point between Nova and Ironic continues to be a pain point, and despite many discussions between the teams over the last year resulting in a