Re: [openstack-dev] [nova][scheduler] bug in handling of ISOLATE thread policy
On 08 Jun 10:11, Finucane, Stephen wrote: > On 07 Jun 11:36, Chris Friesen wrote: > > Hi, > > > > The full details are available at > > https://bugs.launchpad.net/nova/+bug/1590091 but the short version > > is this: > > > > 1) I'm running stable/mitaka in devstack. I've got a small system > > with 2 pCPUs, both marked as available for pinning. They're two > > cores of a single processor, no threads. > > > > 2) I tried to boot an instance with two dedicated CPUs and a thread > > policy of ISOLATE, but the NUMATopology filter fails my host. > > This sounds like bug #1550317 [1], which has been fixed on master but > clearly needs to be backported to stable/mitaka. I'll do this as soon > as soon I figure out how to :) > > Stephen > > PS: Marked #1590091 as a duplicate, per above. > > [1] https://bugs.launchpad.net/nova/+bug/1550317 Done (thanks to bauzas). Review is available here [1]. I'll also point out the other bug fix that's available for the CPU thread policy feature [2]. This fixes less obvious issues with the 'require' policy. Stephen [1] https://review.openstack.org/326944 [2] https://review.openstack.org/285232/ __ 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
Re: [openstack-dev] [nova][scheduler] bug in handling of ISOLATE thread policy
On 07 Jun 11:36, Chris Friesen wrote: > Hi, > > The full details are available at > https://bugs.launchpad.net/nova/+bug/1590091 but the short version > is this: > > 1) I'm running stable/mitaka in devstack. I've got a small system > with 2 pCPUs, both marked as available for pinning. They're two > cores of a single processor, no threads. > > 2) I tried to boot an instance with two dedicated CPUs and a thread > policy of ISOLATE, but the NUMATopology filter fails my host. This sounds like bug #1550317 [1], which has been fixed on master but clearly needs to be backported to stable/mitaka. I'll do this as soon as soon I figure out how to :) Stephen PS: Marked #1590091 as a duplicate, per above. [1] https://bugs.launchpad.net/nova/+bug/1550317 __ 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-dev] [nova] Standardized executable return codes/logging conventions?
I'm working on a fix [1] for bug #1538227, "Failed `nova-manage db sync` returns exitcode of 0" [2]. Having done this, I've noted that there seems to be no consistent policy around (a) what return codes to use (if any), and (b) whether to use logging or printing. Are there any guidelines on this in Nova (or any OpenStack project, for that matter) and, if not, do we need some? This is important for me as I'm adding a new return code to said executable and I've been asked for provide some rationale for my choice of code [3] FWIW, I think the returns codes don't matter so much so long as they always return non-zero for failed/error cases and don't change (without good reason) once they do so. I also think output should be done via print, per the recommendations of the Python documentation [4], but some consitency in output would be appreciated. Cheers, Stephen [1] https://review.openstack.org/#/c/289308/2 [2] https://bugs.launchpad.net/nova/+bug/1538227 [3] https://review.openstack.org/#/c/289308/2/nova/cmd/manage.py [4] https://docs.python.org/3.3/howto/logging.html#when-to-use-logging __ 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-dev] [nova] [stringfreeze] request for SFE
Nova cores, I would like to request a SFE for the below fix: https://review.openstack.org/#/c/170190/ https://bugs.launchpad.net/nova/+bug/1438226 This change adds a useful error message to help users debug incompatibilities with some versions of a dependency (libvirt). Without this error message the change is of little use. Regards, Stephen Finucane PS: I can redirect this to the i18n mailing list if necessary. __ 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
