| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-08 | |||
| 16:15:06 | sean-k-mooney | if we have ci/release blocking bugs we will sometimes make an excpetion but while this is an annoying issue its not that pressing | |
| 16:15:49 | maciejjozefczyk | for this particular one we have about 20-30 occurrences/day | |
| 16:15:56 | maciejjozefczyk | on all regions | |
| 16:16:53 | sean-k-mooney | ouch we have only had one customer report an issue and for them it happended after a power failuer broke quoram on there glara cluster | |
| 16:22:24 | stephenfin | I'm seeing 'sqlalchemy.exc.NoSuchTableError: migration_tmp' when running unit tests. Any idea why? | |
| 16:22:27 | stephenfin | *Anyone any | |
| 16:29:38 | sean-k-mooney | oh by the way i figured out why the intel nfv ci is still triggering but skipping all jobs. ie why intel has not disabled it totaly | |
| 16:29:52 | sean-k-mooney | it is still runing jobs properly on neutron | |
| 16:30:02 | sean-k-mooney | they have just disabel the nova jobs. | |
| 16:47:54 | jaypipes | stephenfin: from your ML post about hugepages... "It's perfectly fine to have NUMA without CPU pinning, though not the other way around." <-- is that true? Wouldn't a user want to request dedicated CPU resources regardless of whether those CPUs are associated with a particular NUMA node? I mean, if they don't have a device that has NUMA affinity requirements and they don't have a need for a specific guest NUMA layout/topology, why isn't that a | |
| 16:47:54 | jaypipes | legit request? | |
| 16:49:06 | stephenfin | jaypipes: Ah, I'm talking about the nova view of things. Nova doesn't currently let you have CPU pinning without a NUMA topology | |
| 16:49:33 | jaypipes | ah, yes, much to my chagrin. | |
| 16:49:39 | sean-k-mooney | jaypipes oversubscription is perfectly fine fore cpu pinning too | |
| 16:49:46 | stephenfin | Whether CPU pinning without taking NUMA affinity into account is a different issue entirely | |
| 16:49:59 | stephenfin | sean-k-mooney: but daft, given why people are using CPU pinning | |
| 16:50:01 | sean-k-mooney | stephenfin: oh you were refering to the cpu pinning bit | |
| 16:50:09 | sean-k-mooney | needing numa toplogy | |
| 16:50:10 | jaypipes | stephenfin: it's just the way you wrote that, made it seem that a request for dedicated CPU resources without any NUMA affinity/topology wasn't a valid request. | |
| 16:50:19 | sean-k-mooney | stephenfin: no its not | |
| 16:50:34 | sean-k-mooney | cpu pinning means i have a compute intensive workload | |
| 16:50:45 | sean-k-mooney | it dows nto mean that workload is memory sencitive | |
| 16:51:06 | stephenfin | jaypipes: Sorry, not what I was going for. If you are replying, to that email you might clarify | |
| 16:51:19 | stephenfin | sean-k-mooney: Think you're crossing wires here | |
| 16:51:36 | jaypipes | sean-k-mooney: pls see my comment on that topic on https://review.openstack.org/#/c/599957 | |
| 16:51:36 | stephenfin | I'm saying oversubscription for pinned CPUs is daft, i.e. allowing two instances to share the same pCPU | |
| 16:52:03 | jaypipes | stephenfin: not a huge deal. if I reply, I'll mention it, but was more just making sure I was understanding you properly. | |
| 16:52:14 | jaypipes | stephenfin: see my comment on https://review.openstack.org/#/c/599957/ :) | |
| 16:52:15 | stephenfin | sean-k-mooney: I have no issues with unbinding CPU pinning from NUMA topologies | |
| 16:52:17 | sean-k-mooney | stephenfin: that i agree with but we were talking about memory oversubsription on the email tread | |
| 16:52:37 | stephenfin | jaypipes: Indeed :) I recall that discussion at the PTG | |
| 16:53:11 | sean-k-mooney | jaypipes: ya i stand by my comments on that spec i dont think we should support that | |
| 16:53:24 | stephenfin | sean-k-mooney: Right, you said "oversubscription is perfectly fine fore cpu pinning too" and I thought you mean CPU oversubscription | |
| 16:53:29 | stephenfin | *meant | |
| 16:53:33 | sean-k-mooney | jaypipes: that being https://review.openstack.org/#/c/599957/ | |
| 16:53:57 | stephenfin | sean-k-mooney: Hence my "that is daft" comment :) | |
| 16:54:32 | sean-k-mooney | stephenfin: no dedicated means you get the whole cpus if we ever wanted to allow pinning and over subsrciption i woudl want to different cpu_policy to indicate that | |
| 16:55:09 | openstackgerrit | Merged openstack/nova stable/rocky: Make compute rpcapi version calculation check all cells https://review.openstack.org/624982 | |
| 16:55:15 | stephenfin | sean-k-mooney: yup, I agree :) Just me misinterpreting what you said | |
| 16:55:21 | sean-k-mooney | we named it shared and dedicated to clearly callout that one allows over subscription or cpus and the other does not so https://review.openstack.org/#/c/599957/ is a definet no form me | |
| 16:56:20 | sean-k-mooney | stephenfin: i just resopned to that mail again pointing out the setting hw:numa_nodes=X does not prevent swaping the memory for 4k pages too incase you did not see | |
| 16:57:00 | openstackgerrit | Maciej Jozefczyk proposed openstack/nova master: Add fill_virtual_interface_list online_data_migration script https://review.openstack.org/614167 | |
| 16:57:01 | openstackgerrit | Maciej Jozefczyk proposed openstack/nova master: Force refresh instance info_cache during heal https://review.openstack.org/591607 | |
| 16:57:27 | maciejjozefczyk | jaypipes: I did a little update after your nits, will be silky smooth now | |
| 16:57:31 | maciejjozefczyk | needed to go, bb ;) | |
| 17:00:39 | stephenfin | sean-k-mooney, jaypipes, sahid: https://bugs.launchpad.net/nova/+bug/1810977 | |
| 17:00:41 | openstack | Launchpad bug 1810977 in OpenStack Compute (nova) "Oversubscription broken for instances with NUMA topologies" [Undecided,New] | |
| 17:01:26 | stephenfin | I checked and reverting the patch gets us back to where we want to be. Have a better patch ready but currently trying to figure out why UTs won't run | |
| 17:01:45 | jaypipes | stephenfin: I would mark that bug as affecting me but... it doesn't. :) | |
| 17:02:37 | sean-k-mooney | im assuming oath does not over subscirbe ram or does not use the numa retlated features | |
| 17:03:28 | jaypipes | sean-k-mooney: that would be correct. | |
| 17:03:48 | sean-k-mooney | jaypipes: that certinly simplfies life. | |
| 17:04:09 | jaypipes | sean-k-mooney: indeed. | |
| 17:04:43 | jaypipes | sean-k-mooney: for performance-sensitive things, we use Ironic and the tenant does whatever the f**k they want to. | |
| 17:05:26 | sean-k-mooney | ya when thats a option baremetal will always beat even the most tunned vm | |
| 17:05:39 | jaypipes | (which is why 90% of our infrastructure is Ironic unfortunately, because tenants assume they must have baremetal to achieve the performance they need, even though 99% of our tenants haven't actually quantified what "performance" they "need". | |
| 17:05:52 | openstackgerrit | Merged openstack/nova-specs master: Add PENDING vm state https://review.openstack.org/554212 | |
| 17:07:01 | sean-k-mooney | jaypipes: ya, im so familar with the tuneing options at this point that i pick an chooes the ones that make sense when i need them | |
| 17:07:34 | sean-k-mooney | i normally have at least one of the numa feature enabled even if it is just hw:numa_nodes=1 | |
| 17:08:37 | sean-k-mooney | oh the pending state spec has merged cool :) | |
| 17:09:00 | sean-k-mooney | the rest of the premptable instance work is in the reaper project right? | |
| 17:15:16 | jaypipes | yonglihe: k, reviewed the NUMA spec. | |
| 17:51:01 | openstackgerrit | Merged openstack/nova-specs master: Flavor Extra Spec and Image Properties Validation https://review.openstack.org/618542 | |
| 18:07:26 | openstackgerrit | Chris Dent proposed openstack/nova master: Remove placement from nova install docs https://review.openstack.org/628184 | |
| 18:07:26 | openstackgerrit | Chris Dent proposed openstack/nova master: Remove link to placement configuration from nova config docs https://review.openstack.org/628185 | |
| 18:07:27 | openstackgerrit | Chris Dent proposed openstack/nova master: Remove placement from contributor doc https://review.openstack.org/628186 | |
| 18:07:45 | openstackgerrit | Chris Dent proposed openstack/nova master: Switch to using os-resource-classes https://review.openstack.org/628278 | |
| 18:24:04 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Fix overcommit for NUMA-based instances https://review.openstack.org/629281 | |
| 18:24:13 | stephenfin | sean-k-mooney, gibi, jaypipes: Ta-da ^ | |
| 18:24:22 | stephenfin | Makes sense to me, anyway. Lemme know | |
| 18:34:13 | sean-k-mooney | stephenfin: its almost right comment inline. you messed the case fo explcit small pages e.g. hw:mem_page_size=small|4|4k | |
| 18:40:31 | stephenfin | sean-k-mooney: replied | |
| 19:20:51 | lbragstad | johnthetubaguy jaypipes o/ curious if either of you have thoughts on this since the last time we discussed it - http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001518.html | |
| 19:52:27 | openstackgerrit | Paul-Emile Element proposed openstack/os-traits master: Add new traits for TPM support https://review.openstack.org/629299 | |
| 20:19:20 | mnaser | oh yikes | |
| 20:19:34 | mnaser | how safe is it to change the admin_or_owner rule | |
| 20:19:59 | mnaser | to say, something like: "is_admin:True or (role:compute and project_id:%(project_id)s)" | |
| 20:20:04 | openstackgerrit | Jack Ding proposed openstack/nova master: Improve libvirt image and snapshot handling https://review.openstack.org/616692 | |
| 20:51:58 | openstackgerrit | Jack Ding proposed openstack/nova-specs master: Fix format flavor-extra-spec-image-property-validation https://review.openstack.org/629311 | |
| 22:07:16 | yonglihe | jay, thanks. | |
| 22:27:17 | yonglihe | jaypipes, sean-k-mooney do we need aligned about sean-k-mooney's suggestion? move some stuff out of the 'nodes' and a more granular policy rule. | |
| 22:35:29 | openstackgerrit | Yongli He proposed openstack/nova-specs master: add spec "show-server-numa-topology" https://review.openstack.org/612256 | |
| 22:37:38 | yonglihe | jaypipes, update per your comments. i working on a more specific policy rule, that's fine to me. | |
| 23:15:13 | openstackgerrit | Yongli He proposed openstack/nova-specs master: add spec "show-server-numa-topology" https://review.openstack.org/612256 | |
| 23:15:19 | jaypipes | yonglihe: I actually think no, it's best just left defaulted to admin-only policy. | |
| 23:15:37 | jaypipes | yonglihe: but I won't hold up the spec for that reason or anything | |
| 23:16:05 | yonglihe | ok, i need revert it. already add a fine control | |
| 23:16:44 | jaypipes | yonglihe: don't revert :) | |
| 23:16:51 | jaypipes | yonglihe: it's not a big deal | |
| 23:16:54 | yonglihe | ok | |
| 23:18:04 | yonglihe | nice to know your idea about which item cause you add -1 | |
| 23:18:32 | yonglihe | really nice hint for review. | |
| 23:40:33 | openstackgerrit | Merged openstack/python-novaclient stable/rocky: Fix up userdata argument to rebuild. https://review.openstack.org/613057 | |
| 23:45:03 | openstackgerrit | Merged openstack/python-novaclient stable/rocky: Follow up "Fix up userdata argument to rebuild" https://review.openstack.org/613086 | |
| 23:45:51 | openstackgerrit | Hongbin Lu proposed openstack/nova-specs master: Scheduling support for SR-IOV bond https://review.openstack.org/626055 | |
| #openstack-nova - 2019-01-09 | |||
| 00:03:54 | openstackgerrit | Hongbin Lu proposed openstack/nova-specs master: Scheduling support for SR-IOV bond https://review.openstack.org/626055 | |
| 00:36:31 | openstackgerrit | Merged openstack/nova stable/rocky: Fail to live migration if instance has a NUMA topology https://review.openstack.org/625880 | |
| 02:06:03 | openstackgerrit | Merged openstack/nova stable/rocky: Imported Translations from Zanata https://review.openstack.org/628109 | |
| 02:06:09 | openstackgerrit | Merged openstack/nova stable/rocky: Fix a broken link https://review.openstack.org/626798 | |
| 02:06:15 | openstackgerrit | Merged openstack/nova stable/rocky: Removing pip-missing-reqs from default tox jobs https://review.openstack.org/628952 | |