Jay Pipes <jaypi...@gmail.com> wrote on 01/21/2014 08:50:36 PM: ... > On Tue, 2014-01-21 at 14:28 +0000, Day, Phil wrote: > > > > > > > > I think there is clear water between this and the existing aggregate > > > > based > > > isolation. I also think this is a different use case from reservations. > > > It's > > > *mostly* like a new scheduler hint, but because it has billing impacts I > > > think it > > > needs to be more than just that - for example the ability to request a > > > dedicated instance is something that should be controlled by a specific > > > role.
> Please help me see this clear water. At the icehouse summit I heard the > concern that > without reservations there will be an unacceptably high probability that a > nova-boot > request will be unsatisfiable due to lack of hosts that are fully idle. > Why is that not a concern now? I don't think that's an issue of reservations - it's an issue of capacity management. Unless all future demand is captured as a reservation then there is always a risk of there being more demand than supply. Maybe some environments can run on a reservation-only basis, but I wouldn't think that is a general case. Maybe I have the wrong model but I was thinking of a reservation system as some kind of premium offering - you pay more (or maybe less as its helping the operator with their future demand forcast) but you know you will be able to get the capacity when you want it. ... >> ... >> Yup, agreed. It's difficult to guess what the capacity implications >> would be without having solid numbers on customer demands for this >> functionality, including hard data on how long such instances would >> typically live (see my previous point about re-using compute hosts for >> other purposes once the last dedicated instance is terminated on that >> host). > That is what I find hardest about designing stuff for general purpose use --- > we get to assume little about the usage. That's why we have to provide basic well constrained bits of functionality that operators can choose to use or not. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
