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 of
>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 from
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,
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 havi
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 scheduler process in Ironic,
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 f
>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 affinity/ant
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 ex
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 tha
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. Breakin
> 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 abstr
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
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 w
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 que
> 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
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 pain
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 s
17 matches
Mail list logo