Open Stack

> -----Original Message-----
> From: Sylvain Bauza [mailto:sbauza at redhat.com]
> Sent: Monday, August 29, 2016 2:43 PM
> To: OpenStack Development Mailing List (not for usage questions) <openstack-
> dev at lists.openstack.org>
> 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
> >
> >