> -----Original Message----- > From: Sylvain Bauza [mailto:[email protected]] > Sent: Monday, August 29, 2016 2:43 PM > To: OpenStack Development Mailing List (not for usage questions) <openstack- > [email protected]> > Subject: Re: [openstack-dev] [Nova] Reconciling flavors and block device > mappings > >> While : > >> #1 the first change about setting root_gb equals 0 in RequestSpec for > >> making sure BFV instances are correctly using the DiskFilter is fine > >> by me having it merged with a TODO/FIXME saying that the code would > >> be expired once the scheduler uses the resource providers, #2, then > >> the second patch about trying to look at the BDMs for DiskFilter is > >> very wrong by me, because the Compute API shouldn't accept IMHO to > >> ask for a flavor *and* a BDM with a related disk size different from > >> the flavor. AFAIT, we should return a 40x (probably 409 or 400) for > >> that instead of accepting it silently. > > > > Well, a flavor is always required when launching an instance. I wasn't > > aware until recently that one could "override" the root GB (or > > eph/swap) sizes in the API. Apparently, the API allows it, though, > > even though the code ignores whatever was passed as the override > > value. If the API supports it, I think the code should probably be > > changed to override the size values to whatever the user entered, no? > > > I'm very sad to see this possible. FWIW, I think that the flavor should > always be > the source of truth for knowing the asked disk size (if no, imagine all the > conditionals in code...) and we should somehow reconcile what the flavor > provided and what the user explicitly asked for. > > Having a possibility to trample the flavor size seems to be a very bad UX (I > guess > most of the operators don't think about that when understanding why this > instance could have a different size from the related flavor) hence me > thinking > we should rather discuss on a possible new microversion for returning a 400 > when both sizes are not identical. Hi, when it comes to more short-term I think that many comments of John/Tim/Andrew/Jay/Silvain are not against the fact that patches will get merged. somehow I disagree with Silvain on the part of 'returning 400 in case both sizes are not identical' as mid-term direction
That will break the scheduling for those who now use root disk = 0. And using root disk=0 for such instances should be not only acceptable workaround but also acceptable in mid- long- term IMHO. I disagree because [1] gives definition of root disk as ' Virtual root disk size in gigabytes. This is an ephemeral disk that the base image is copied into. When booting from a persistent volume it is not used' So there it is written 'root disk is an ephemeral disk', 'when booting from a persistent volume it is not used' Using boot from volume [which should be referred 'using BDM, as more technically learnt, according to what I learnt in this thread] thus shouldn't have relation with root disk. And not-yet-merged [2] gives direction "Therefore 0 should only be used for volume booted instances or for testing purposes." So operators should not wonder [Sylvain] why its disk sizes could be different from the related flavor. I have no objections on improving flavors (/flavor specs) or having other mechanism to control the size of the (Cinder) volume being used with VM. It sounds for me more Cinder area than Nova, but maybe I am wrong. I would say, that would be used to complement volume quota(s) Introducing something like max.instances could be part of addressing that use cases/possibly with other use cases. That however sounds like a new blueprint. BR, Konstantin [1] http://docs.openstack.org/admin-guide/compute-flavors.html [2] https://review.openstack.org/#/c/339034/ > The other option I could see could be to have the nested flavor in the > RequestSpec be reconciling those two objects being different from the user- > provided flavor (eg. say a flavor with swap=10G and a BDM with swap=1G, then > RequestSpec.flavor would have swap=1G) but given we don't expose the > RequestSpec objects on the API level, that still leaves operators possibly > confused. > > -Sylvain > > > > -jay > > > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
