----- Original Message ----- > From: "Yunhong Jiang" <yunhong.ji...@intel.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Sent: Tuesday, November 12, 2013 5:39:58 PM > Subject: Re: [openstack-dev] Custom Flavor creation through Heat > > -----Original Message----- > > From: Shawn Hartsock [mailto:hartso...@vmware.com] > > Sent: Tuesday, November 12, 2013 12:56 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [nova] [heat] Custom Flavor creation through > > Heat > > > > My concern with proliferating custom flavors is that it might play havoc > > with the underlying root-case for flavors. > > > > My understanding of flavors is that they are used to solve the resource > > packing problem in elastic cloud scenarios. That way you know that 256 > > "tiny" VMs fit cleanly into your hardware layout and so do 128 "medium" > > VMs and 64 large VMs. If you allow "flavor of the week" then the packing > > problem re-asserts itself and scheduling becomes harder. > > I'm a bit surprised that the flavor is used to resolve the packing problem. I > thought it should be handled by scheduler, although it's a NP problem.
I should have said "flavors help to make the packing problem simpler for the scheduler" ... flavors do not "solve" the packing problem. > > As for custom flavor, I think at least it's against current nova assumption. > Currently nova assume flavor should only be created by admin, who knows the > cloud quite well. > One example is, flavor may contain extra-spec, so if an extra-spec value is > specified in the flavor, while the corresponding scheduler filter is not > enabled, then the extra-spec has no effect and may cause issue. > Beyond merely extra-specs my understanding was that because you *have* flavors you can make assumptions about packing that make the problem space smaller... someone made a nice presentation showing how having restricted flavors made scheduling easier. I can't find it right now. It was presented at an OpenStack summit IIRC _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev