On 06/22/2016 01:56 PM, Paul Michali wrote:
I did have a question about the current implementation as described by 292499, 324379, and 292500.Looking at the code, when a NUMAPagesTopology object is create, a new parameter is passed for the "reserved" pages. This reservation comes from a dictionary, which is populated at LIbvirtDriver init time, via grabbing the multi-string configuration settings from nova.conf. Because the object's API is changed, a version change is required. Is it possible to, instead of adding a new argument to reduce the "total" argument (Ian Wells suggested this to me on a patch I had), by the number of reserved pages from the config file? This would prevent the need to alter the object's API. So, instead of: mempages = [ objects.NUMAPagesTopology( size_kb=pages.size, total=pages.total, used=0, reserved=_get_reserved_memory_for_cell( self,cell.id <http://cell.id>, pages.size)) for pages in cell.mempages] Do something like this... mempages = [ objects.NUMAPagesTopology( size_kb=pages.size, used=0, total=pages.total - _get_reserved_memory_for_cell( self, cell.id <http://cell.id>, pages.size)) for pages in cell.mempages] If we do this, would it avoid issues with back porting the change? Thanks! PCM On Wed, Jun 15, 2016 at 5:52 PM Matt Riedemann <mrie...@linux.vnet.ibm.com <mailto:mrie...@linux.vnet.ibm.com>> wrote: On 6/15/2016 3:10 PM, Paul Michali wrote: > Is the plan to back port that change to Mitaka? > > Thanks, > > PCM > > > On Wed, Jun 15, 2016 at 1:31 PM Matt Riedemann > <mrie...@linux.vnet.ibm.com <mailto:mrie...@linux.vnet.ibm.com> <mailto:mrie...@linux.vnet.ibm.com <mailto:mrie...@linux.vnet.ibm.com>>> wrote: > > On 6/14/2016 3:09 PM, Jay Pipes wrote: > > > > Yes. Code merged recently from Sahid does this: > > > > https://review.openstack.org/#/c/277422/ > > > > Best, > > -jay > > > > That was actually reverted out of mitaka: > > https://review.openstack.org/#/c/292290/ > > The feature change that got into newton was this: > > https://review.openstack.org/#/c/292499/ > > Which was busted, and required: > > https://review.openstack.org/#/c/324379/ > > Well, required as long as you want your compute service to start. :) > > And no, we aren't backporting these, especially to liberty which is > security / critical fix mode only now. > > -- > > Thanks, > > Matt Riedemann > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > No, it's really a feature. -- Thanks, Matt Riedemann __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
