On 3 February 2014 08:45, Jaromir Coufal <[email protected]> wrote: >
>> However, taking a step back, maybe the real answer is: >> >> a) homogeneous nodes >> b) document. . . >> - **unsupported** means of "demoing" Tuskar (set node attributes to >> match flavors, hack >> the scheduler, etc) > > Why are people calling it 'hack'? It's an additional filter to > nova-scheduler...? It doesn't properly support the use case; its extra code to write and test and configure that is precisely identical to mis-registering nodes. >> - our goals of supporting heterogeneous nodes for the J-release. > > I wouldn't talk about J-release. I would talk about next iteration or next > step. Nobody said that we are not able to make it in I-release. +1 > >> Does this seem reasonable to everyone? >> >> Mainn > > > Well +1 for a) and it's documentation. > > However me and Robert, we look to have different opinions on what > 'homogeneous' means in our context. I think we should clarify that. So I think my point is more this: - either this iteration is entirely limited to homogeneous hardware, in which case, document it, not workarounds or custom schedulers etc. - or it isn't limited, in which case we should consider the options: - flavor per service definition - custom scheduler - register nodes wrongly -Rob -- Robert Collins <[email protected]> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
