Russell Bryant <rbry...@redhat.com> wrote on 23/07/2013 05:35:18 PM: > >> #1 - policy associated with a host aggregate > >> > >> This seems very odd to me. Scheduling policy is what chooses hosts, so > >> having a subset of hosts specify which policy to use seems backwards. > > > > This is not what we had in mind. Host aggregate is selected based on > > policy passed in the request (hint, extra spec, or whatever -- see > > below) and 'policy' attribute of the aggregate -- possibly in > > conjunction with 'regular' aggregate filtering. And not the other way > > around. Maybe the design document is not clear enough about this point. > > Then I don't understand what this adds over the existing ability to > specify an aggregate using extra_specs.
The added value is in the ability to configure the scheduler accordingly -- potentially differently for different aggregates -- in addition to just restricting the target host to those belonging to an aggregate with certain properties. For example, let's say we want to support two classes of workloads - CPU-intensive, and memory-intensive. The administrator may decide to use 2 different hardware models, and configure one aggregate with lots of CPU, and another aggregate with lots of memory. In addition to just routing an incoming provisioning request to the correct aggregate (which can be done already), we may want different cpu_allocation_ratio and memory_allocation_ratio when managing resources in each of the aggregates. In order to support this, we would define 2 policies (with corresponding configuration of filters), and attach each one to the corresponding aggregate. > > >> #2 - via a scheduler hint > >> How about just making the scheduling policy choice as simple as an item > >> in the flavor extra specs? > > > > This is certainly an option. It would be just another implementation of > > the policy selection interface (implemented using filters). In fact, we > > already have it implemented -- just thought that explicit hint could be > > more straightforward to start with. Will include the implementation > > based on flavor extra spec in the next commit. > > Ok. I'd actually prefer to remove the scheduler hint support > completely. OK, removing the support for doing it via hint is easy :-) > I'm not even sure it makes sense to make this pluggable. I > can't think of why something other than flavor extra specs is necessary > and justifies the additional complexity. Well, I can think of few use-cases when the selection approach might be different. For example, it could be based on tenant properties (derived from some kind of SLA associated with the tenant, determining the over-commit levels), or image properties (e.g., I want to determine placement of Windows instances taking into account Windows licensing considerations), etc > I think some additional examples would help. It's also important to > have this laid out for documentation purposes. OK, sure, will add more. Hopefully few examples above are also helpful to clarify the intention/design. Regards, Alex > -- > Russell Bryant
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
