| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-05 | |||
| 16:46:52 | mriedem | efried: ack | |
| 16:46:57 | lbragstad | mriedem possibly - i could time it | |
| 16:47:09 | mriedem | efried: i'll just rebase and abuse any changes of yours that i need | |
| 16:47:24 | efried | mriedem: It would be easier just to merge them right now. | |
| 16:47:43 | mriedem | bah | |
| 16:47:55 | mriedem | my queue is already deep and i haven't started on either of the 2 things i said i'd do today | |
| 16:49:25 | Sundar | efried: Have fun and Happy Holidays! | |
| 16:49:31 | efried | Thanks | |
| 16:51:25 | openstackgerrit | Eric Fried proposed openstack/nova master: Add cyborg client to requirements https://review.openstack.org/623026 | |
| 16:51:25 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Cyborg PCI handling https://review.openstack.org/623027 | |
| 16:56:36 | yan0s | No I definitely needed to change the nova.conf | |
| 16:56:50 | yan0s | I was restarting the service in every try | |
| 16:57:11 | yan0s | @lbragstad | |
| 16:57:20 | yan0s | @mriedem | |
| 16:58:19 | mriedem | hmm, well i'm stumped then | |
| 16:58:20 | lbragstad | yeah - by default, oslo.policy isn't going to reload policy files on disk | |
| 16:58:44 | mriedem | lbragstad: but they shouldn't have had to explicitly configure nova.conf with [oslo_policy]/policy_file = policy.json | |
| 16:58:49 | mriedem | since that's the default in code | |
| 16:59:12 | mriedem | anyway, probably just something i'd need to mess with in devstack to see if i can recreate it | |
| 16:59:23 | lbragstad | this sounds like two different issues | |
| 17:03:19 | lbragstad | yan0s if you're in #openstack-oslo this might be more relevant to talk about there | |
| 17:07:57 | openstackgerrit | Eric Fried proposed openstack/nova master: Add cyborg client to requirements https://review.openstack.org/623026 | |
| 17:07:58 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Cyborg PCI handling https://review.openstack.org/623027 | |
| 17:25:12 | mriedem | gibi: not sure if you saw my comment in that notifications patch, but if we planned on switching the default format to unversioned, marking it as deprecated would be weird | |
| 17:29:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Address nits on I08991796aaced2abc824f608108c0c786181eb65 https://review.openstack.org/614322 | |
| 17:29:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Address nits on I1f1fa1d0f79bec5a4101e03bc2d43ba581dd35a0 https://review.openstack.org/614323 | |
| 17:31:47 | stephenfin | mriedem: I'd suggested going the other way, leaving it to deployers to manually set things if some tool can't consume versioned notifications. Maybe that's too severe though | |
| 17:32:37 | mriedem | stephenfin: by some tool you mean *all* tools? | |
| 17:32:42 | mriedem | at least all tools in openstack | |
| 17:33:14 | mriedem | as far as i know, nothing in openstack which consumes nova notifications uses versioned notifications | |
| 17:33:24 | mriedem | and it's on us to add that support to those already understaffed projects | |
| 17:33:33 | stephenfin | Apparently so. I thought there were some, based on some mailing list post from a while back | |
| 17:33:49 | sean-k-mooney | didnt we say we were removing the unversioned notification in denver | |
| 17:33:53 | mriedem | there are lots of projects that consume nova's notifications, but not versioned | |
| 17:33:58 | mriedem | no | |
| 17:34:01 | mriedem | we said we'd never remove them | |
| 17:34:04 | stephenfin | Not removing - just deprecating | |
| 17:34:06 | stephenfin | Yeah | |
| 17:34:13 | stephenfin | until they eventually break, presumably | |
| 17:34:40 | sean-k-mooney | sorry your right we said we woudl keep them but not add new unversioned notifications | |
| 17:35:13 | mriedem | we haven't been adding new unversioned notifications since...we had versioned notifications | |
| 17:35:37 | mriedem | getting telemetry over the hump is probably the biggest hurdle | |
| 17:35:39 | mriedem | within openstack | |
| 17:35:41 | sean-k-mooney | right but i gues what i ment is freezing the unversioned code. | |
| 17:35:47 | mriedem | it's already frozen | |
| 17:36:07 | sean-k-mooney | including bug fixes | |
| 17:36:11 | mriedem | deprecation would just be signaling, don't write new stuff with this | |
| 17:36:32 | mriedem | i can't remember the last time we had a bug fix that dealt with unversioned notifications | |
| 17:37:09 | mriedem | my concern is https://bugs.launchpad.net/nova/+bug/1805659 | |
| 17:37:09 | openstack | Launchpad bug 1805659 in OpenStack Compute (nova) "nova notifications hammering the message bus" [Low,Confirmed] | |
| 17:37:11 | mriedem | which jmlowe brought up | |
| 17:37:22 | mriedem | today we default to send both, versioned and unversioned, which kills rpc | |
| 17:37:27 | mriedem | s/kills/doesn't help/ | |
| 17:37:39 | mriedem | if nothing is consuming versioned yet, then that is a shitty default imo | |
| 17:38:02 | mriedem | i know we want to get people off the old stuff, but no one is doing that | |
| 17:38:18 | sean-k-mooney | ya just readign that makes sense but im kind of reluctent to default to old | |
| 17:38:32 | mriedem | and honestly without a schema that consumers can use, it's probably not really something they care about | |
| 17:38:37 | mriedem | since they can't do version negotiation | |
| 17:39:27 | sean-k-mooney | can we default to versioned going forward instead and tell peopel to enable both/unversions if they have a service that uses them? | |
| 17:39:45 | mriedem | we can do whatever | |
| 17:40:00 | mriedem | me? i'm going to go make lunch and try to think about something else. | |
| 17:40:21 | sean-k-mooney | ok :) | |
| 17:54:19 | cfriesen | sean-k-mooney: I replied to your comments on https://review.openstack.org/#/c/620959/ | |
| 17:55:33 | sean-k-mooney | cfriesen: yep i know the feature flags are already in placement but they currently mean find ma a host wtih X not enable X on the vm | |
| 17:55:53 | sean-k-mooney | cfriesen: qemu does not always requrie the host to have X to enable X for the guest | |
| 17:56:27 | sean-k-mooney | AVX is an exampel you can enable AVX in a guest as long as the host has SSE4 suport | |
| 17:56:28 | cfriesen | sean-k-mooney: not quite true. according to the spec the exposed traits represent the features of the CPU model that you would get in the guest. | |
| 17:57:01 | sean-k-mooney | the new spec | |
| 17:57:20 | cfriesen | In https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/report-cpu-features-as-traits.html it says "The libvirt virt-driver should only return the CPU features which are available to the guest." | |
| 17:57:49 | sean-k-mooney | cfriesen: we currently report all cpu feature on the host i belive | |
| 17:58:00 | sean-k-mooney | i dont think we filter by the configured cpu model | |
| 17:59:15 | cfriesen | sean-k-mooney: see _get_cpu_traits() in virt/libvirt/driver.py | |
| 17:59:28 | openstackgerrit | Merged openstack/nova master: Add a bug tag for nova doc https://review.openstack.org/619434 | |
| 18:00:24 | cfriesen | sean-k-mooney: "if mode is 'custom', use cpu_model to generate CPU features" | |
| 18:02:28 | sean-k-mooney | when the traits were defiend in os tratis they were ment to model the host capablity though | |
| 18:02:32 | cfriesen | so on x86-64 specifying a trait currently *should* result in a guest with the specified CPU feature present, as far as I can tell | |
| 18:02:55 | sean-k-mooney | cfriesen: that seams to be the case but that was not the intent of the trait | |
| 18:02:59 | cfriesen | why would you care whether a host has a feature if you can't get it in the guest? | |
| 18:03:27 | sean-k-mooney | the trait was ment to allow you to ensure it was not emulated in software | |
| 18:04:11 | sean-k-mooney | the way it currently works i could get avx emulated in software using sse4 which will allow the application to run but will have worese perfromance | |
| 18:04:17 | cfriesen | so I guess you'd need to still use the ComputeCapabilitiesFilter for that? | |
| 18:04:34 | cfriesen | combine that with requesting the trait in the flavor, and you'd get both, no? | |
| 18:06:00 | sean-k-mooney | it still misses the point that HW_CPU_X86_AVX is ment to only be used if the host support it in hardware | |
| 18:07:22 | cfriesen | sean-k-mooney: if ComputeCapabilitiesFilter fails hosts that don't have it in hardware, and specifying the trait requests that it's available in the guest, that seems like it'd work. | |
| 18:07:49 | cfriesen | The other option is to simply not specify CPU models with features unsupported by your hardware...which is up to the operator. | |
| 18:08:11 | sean-k-mooney | it would work but i realy dislike that we are not useing the HW e.g. hardware namespace to model only hardware things | |
| 18:08:22 | cfriesen | sean-k-mooney: have you got any specs/docs for the intent of the trait? | |
| 18:09:41 | sean-k-mooney | that was my intent when i asked for namespacing in os traits https://github.com/openstack/os-traits/commit/23d81d4451dd29c23150b29b8fa9d3025ee8878f#diff-f290aedb8b7fdc21b2b04be76222f6c3 | |
| 18:10:23 | sean-k-mooney | the HW namespace was for hardware features | |
| 18:10:42 | cfriesen | we use the "hw" namespace for all sorts of virtual hardware stuff | |
| 18:11:10 | sean-k-mooney | we only started doing that this cylce with the vtpm spec | |
| 18:11:12 | cfriesen | number of numa nodes, cpu distribution between numa nodes, etc | |
| 18:11:19 | cfriesen | oh, you mean for trait | |
| 18:11:23 | sean-k-mooney | yes | |
| 18:12:10 | sean-k-mooney | anyway looks like we approved and implmented https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/report-cpu-features-as-traits.html#libvirt so we are stuck with it | |
| 18:13:04 | sean-k-mooney | i was hopping not to make the same mistakes we did with flavors in os-traits but if i can rely on traits to modele this correctly i will always need filters | |
| 18:13:16 | cfriesen | I think it'd be worth adding something to the release notes warning operators to consider this when adding CPU models to the list. | |
| 18:13:55 | cfriesen | In practice, I would expect that most operators advertising high-performance would not want emulated features, no? | |
| 18:14:16 | sean-k-mooney | ya or better to the config option so its in the docs for setting the models/extra flags | |
| 18:14:27 | cfriesen | right, that makes sense | |