| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-23 | |||
| 12:53:30 | mriedem | https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/custom-resource-classes-in-flavors.html | |
| 12:54:15 | mriedem | jroll: this isn't regressed in rocky right? it's just a master thing | |
| 12:54:20 | jroll | mriedem: I don't know | |
| 12:54:37 | jroll | mriedem: everything I know about the bug is here in channel | |
| 12:54:55 | openstackgerrit | melanie witt proposed openstack/nova master: Correct the release notes related to nova-consoleauth https://review.openstack.org/595455 | |
| 12:55:00 | jroll | mriedem: it could have regressed in rocky, but was masked by the fact we were still reporting cpu/ram/disk for the ironic nodes | |
| 12:55:47 | mriedem | https://github.com/openstack/nova/blob/cc436c2b2a2dad974c4d28871851a456ebd80e48/nova/scheduler/utils.py#L220 | |
| 12:58:52 | jroll | man this code is not super easy to understand | |
| 12:58:54 | mriedem | this is the old code https://review.openstack.org/#/c/515223/12/nova/scheduler/utils.py@a224 | |
| 12:59:01 | mriedem | it wasn't before either | |
| 12:59:41 | Tomatosoup1 | hello | |
| 13:01:08 | Tomatosoup1 | i would like to set up SNAT network on one of the openstack VM, how may i do it? docs are mentioning SNAT but only in theoretical way | |
| 13:01:10 | jroll | mriedem: so that first link, are you saying it should work as advertised? | |
| 13:01:57 | mriedem | w/o a functional test showing it works, idk | |
| 13:02:05 | mriedem | if it was regressed, it's been broken since queens | |
| 13:02:10 | mriedem | with https://review.openstack.org/#/c/515223/ | |
| 13:02:19 | jroll | awesome | |
| 13:02:43 | mriedem | :) this is why i was easing into the "remove the old flavor support for baremetal" pool | |
| 13:03:07 | jroll | yeah, glad we didn't kill it at the tail end of rocky | |
| 13:03:21 | mriedem | you remember talking about it though right? | |
| 13:03:24 | mriedem | like 2 weeks ago | |
| 13:03:44 | jroll | about removing it? or about this bug? | |
| 13:03:52 | mriedem | removing it | |
| 13:03:55 | jroll | yeah | |
| 13:04:13 | jroll | I can say "you win" if that's what you're looking for :) | |
| 13:04:16 | mriedem | YES | |
| 13:04:56 | mriedem | i would take some eggs and toast | |
| 13:05:14 | jroll | okay, I shall go make them | |
| 13:05:51 | mriedem | thanks babe | |
| 13:06:53 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge keypair extension response into server view builder https://review.openstack.org/584748 | |
| 13:06:54 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge server usage extension response into server view builder https://review.openstack.org/585262 | |
| 13:06:55 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge security groups extension response into server view builder https://review.openstack.org/585475 | |
| 13:06:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge extended_status extension response into server view builder https://review.openstack.org/592092 | |
| 13:07:48 | mriedem | tssurya: fyi ^ i'm trying to keep gmann's series straight and rebased so we can flush it through | |
| 13:08:19 | mriedem | Tomatosoup1: see channel topic please | |
| 13:09:02 | Tomatosoup1 | mriedem, sorry! | |
| 13:09:04 | tssurya | mriedem: noted thanks :) I need extended_volumes also, probably we will have it when he is back | |
| 13:09:53 | sean-k-mooney | are there any known bugs with pysaml2? my devstack is failing to install it. im wondering do we need a version cap | |
| 13:12:18 | mriedem | tssurya: he's out for another week, | |
| 13:12:30 | mriedem | these changes are pretty mechanical so could probably just do it yourself | |
| 13:12:33 | mriedem | following the pattern, | |
| 13:12:38 | mriedem | the hardest part would be the unit test stuff | |
| 13:12:57 | tssurya | ah okay, I didn't want to step into his stuff, but if that's okay I can get it up and update them | |
| 13:13:01 | mriedem | sean-k-mooney: upper-constraints should restrict it in devstack | |
| 13:18:32 | edmondsw | in my devstack I'm seeing a lot of "DEBUG nova.notifications.objects.base [None req-af08f64a-756e-4b43-8357-fd879d3bbbc9 None None] Defaulting the value of the field 'numa_membw_values' to None in MetricPayload due to 'Cannot load 'numa_membw_values' in the base class' {{(pid=145045) populate_schema /opt/stack/nova/nova/notifications/objects/base.py:142}}" | |
| 13:18:45 | edmondsw | but I can't find anything that would ever actually set numa_membw_values, outside of tests | |
| 13:19:26 | edmondsw | should that be removed? What am I missing? | |
| 13:22:41 | edmondsw | or set to Null here? https://github.com/openstack/nova/blob/baf858b03d55273f92fc115ea5c8f71c0bbb6582/nova/compute/monitors/cpu/virt_driver.py#L42 | |
| 13:23:13 | edmondsw | if it's only ever null, though... | |
| 13:24:57 | sean-k-mooney | mriedem: its trying to install 4.6.0 and thats failing on my system. | |
| 13:25:10 | sean-k-mooney | ill pin locally to 4.5 for now | |
| 13:29:14 | sean-k-mooney | edmondsw: numa_membw_values being memory bandwidth? i think that is only supported skylake or newer intel chips and on skylake its broken becaue but memory reand and memory write counters were actully the read value | |
| 13:29:47 | edmondsw | sean-k-mooney unclear from the code I've found | |
| 13:30:29 | edmondsw | I wonder if this was added with the intention of having a followup that used it and maybe that just never happened | |
| 13:31:09 | sean-k-mooney | perhaps that or there is patch in review that has not landed yet | |
| 13:37:31 | stephenfin | mriedem: Does we need to wait for blueprint approval for [1] or can I start flushing them through? [1] https://review.openstack.org/#/q/topic:bp/api-extensions-merge-stein+status:open | |
| 13:38:37 | stephenfin | mriedem: Wait, it's specless and approved. Ignore me | |
| 13:39:09 | zigo | mriedem: cdent: I now know why I missed the webob version, it's because I forgot the EPOCH ... | |
| 13:39:20 | zigo | 1:1.8.2 is what's needed, not 1.8.2 ... | |
| 13:39:22 | zigo | :/ | |
| 13:39:27 | mriedem | stephenfin: right some are already approved/merged | |
| 13:39:34 | stephenfin | ack | |
| 13:41:48 | mriedem | edmondsw: a notification is trying to build a payload from the MonitorMetric object which has unset fields which don't have default values | |
| 13:41:57 | mriedem | but if it's nullable we can just set it to None | |
| 13:42:10 | mriedem | since 'numa_membw_values': fields.DictOfIntegersField(nullable=True), that's what we do | |
| 13:43:08 | edmondsw | mriedem yep, my point is that I think it's always going to be unset and thus DEBUG logs will always have a bunch of these messages filling them because nowhere is it ever set that I can find | |
| 13:43:23 | mriedem | we also get that a ton for flavor stuff i think | |
| 13:43:24 | mriedem | or used to | |
| 13:43:35 | edmondsw | and if that's the case, why does the schema have it in the first place? | |
| 13:44:02 | mriedem | i would be ok with dropping the 'defaulting to None' debug log | |
| 13:44:04 | mriedem | but it's up to gibi | |
| 13:44:30 | mriedem | or change to TRACE if we ever get a TRACE log level | |
| 13:44:42 | edmondsw | I can ignore it, it's not a big deal to me... just thought I'd ask | |
| 13:44:49 | mriedem | it bothers me too | |
| 13:45:51 | openstackgerrit | Eric Fried proposed openstack/nova master: reshaper: Look up provider if not in inventories https://review.openstack.org/585033 | |
| 13:45:52 | openstackgerrit | Eric Fried proposed openstack/nova master: Make get_allocations_for_resource_provider raise https://review.openstack.org/584598 | |
| 13:45:53 | openstackgerrit | Eric Fried proposed openstack/nova master: Report client: Real get_allocs_for_consumer https://review.openstack.org/584599 | |
| 13:45:54 | openstackgerrit | Eric Fried proposed openstack/nova master: Report client: get_allocations_for_provider_tree https://review.openstack.org/584648 | |
| 13:45:55 | openstackgerrit | Eric Fried proposed openstack/nova master: Report client: _reshape helper, placement min bump https://review.openstack.org/585034 | |
| 13:45:56 | openstackgerrit | Eric Fried proposed openstack/nova master: Report client: update_from_provider_tree w/reshape https://review.openstack.org/585049 | |
| 13:45:57 | openstackgerrit | Eric Fried proposed openstack/nova master: Compute: Handle reshaped provider trees https://review.openstack.org/576236 | |
| 13:47:09 | ykarel | jroll, mriedem openstack flavor unset --property resources:VCPU --property resources:DISK_GB --property resources:MEMORY_MB <flavor> didn't help, or i tried something wrong | |
| 13:49:19 | gibi | mriedem: as the MonitorMetric.numa_membw_values is also nullable I think when nova creates the MonitorMetric object it fails to set the default value of that field | |
| 13:49:36 | mriedem | there is no default value | |
| 13:49:39 | mriedem | but it is nullable | |
| 13:49:48 | mriedem | i guess you mean fails to initialize the field to None? | |
| 13:49:50 | gibi | mriedem: ohh, my bad | |
| 13:50:03 | gibi | mriedem: I mixed nullable and default value | |
| 13:54:00 | gibi | mriedem: if an ovo is valid with unset fields then I cannot do anything else than remove the debug log | |
| 13:55:06 | mriedem | yeah i don' think the debug log adds much besides noise - if the field is unset and can't be lazy-loaded and is nullable and set it to None, great | |
| 13:55:08 | mriedem | that's what should happen | |
| 13:55:19 | mriedem | if we can't do that - i.e. it's not nullable, then we fail and log an error | |
| 13:55:37 | mriedem | like that flavor.disabled thing we had to fix | |
| 13:55:59 | gibi | mriedem: yeah. Then I will file a bug and propose the removal. | |
| 13:56:04 | mriedem | i can report a "logs are noisy" bug if you want for tracking | |
| 13:56:07 | mriedem | ah ok | |
| 13:56:08 | mriedem | :) | |
| 13:56:18 | melwitt | nova meeting in 4 minutes | |
| 13:56:33 | gibi | mriedem: I'm not fully happy with ovos with unset fields but we use the ovos that way a lot in nova | |
| 13:56:43 | mdbooth | melwitt: We may have to continue that discussion another time, then ;) | |