| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-05-11 | |||
| 16:12:45 | gibi | yeah, I see now | |
| 16:23:26 | openstackgerrit | Takashi Natsume proposed openstack/nova master: Remove six.reraise https://review.opendev.org/726898 | |
| 16:30:14 | openstack | bug 1878024 in OpenStack Compute (nova) "disk usage of the nova image cache is not counted as used disk space" [Undecided,New] https://launchpad.net/bugs/1878024 | |
| 16:30:14 | gibi | lyarwood, dansmith: updated the bug 1878024 with what we talked about above. | |
| 16:30:24 | dansmith | cool | |
| 16:30:57 | gibi | and now I go and bake some bread for dinner | |
| 16:31:04 | gibi | see you tomorrow | |
| 18:15:35 | openstackgerrit | Merged openstack/nova master: Support for --force flag for nova-manage placement heal_allocations command https://review.opendev.org/715395 | |
| 18:15:48 | openstackgerrit | Merged openstack/nova stable/queens: Include only required fields in ironic node cache https://review.opendev.org/724862 | |
| 18:16:01 | openstackgerrit | Merged openstack/nova stable/queens: Lowercase ironic driver hash ring and ignore case in cache https://review.opendev.org/723054 | |
| 18:16:10 | openstackgerrit | Merged openstack/nova stable/rocky: Add config option for neutron client retries https://review.opendev.org/722819 | |
| 18:16:27 | openstackgerrit | Merged openstack/nova master: Suppress remaining policy warnings in unit tests https://review.opendev.org/726272 | |
| 18:22:04 | markguz_ | anyone know how to get out of Unsupported VIF type binding_failed convert '_nova_to_osvif_vif_binding_failed' hell? | |
| 19:35:26 | openstackgerrit | Harshavardhan Metla proposed openstack/nova master: [Nova] Add reference to Placement installation guide https://review.opendev.org/726936 | |
| 19:42:27 | markguz_ | for anyone that's interested setting neutron.ml2_port_bindings.vif_type to "ovs" in the database fixed this for me | |
| 19:43:35 | sean-k-mooney | markguz_: if you get that error its because neutron failed to bind the port | |
| 19:43:47 | markguz_ | i know | |
| 19:43:50 | sean-k-mooney | which normally means there was an error on cthe compute node | |
| 19:44:10 | markguz_ | but once it happens it seems next to impossible to fix it via the normal methods. | |
| 19:44:46 | sean-k-mooney | markguz_: you fix it by setting the host filed to "" or "none" then back to the original hostname | |
| 19:45:09 | markguz_ | the instance will not boot due the "binding_failed" being written into the vif_type field | |
| 19:45:33 | markguz_ | sean-k-mooney: or by updating that field i just mentioned in the neutron db | |
| 19:46:02 | sean-k-mooney | yes but you can do "openstack --os-cloud=admin port set --host none baf2b165-797b-4305-bc6b-5b63250b890d" follow by " openstack --os-cloud=admin port set --host workstation baf2b165-797b-4305-bc6b-5b63250b890d" | |
| 19:46:09 | sean-k-mooney | to do it from the api without db hacking | |
| 19:46:36 | sean-k-mooney | it will actully cause port binding to happen properly recalualting the correct values | |
| 19:46:41 | markguz_ | sean-k-mooney: ok. thanks for that | |
| 19:47:01 | sean-k-mooney | so i did that yesterday becauses i was swaping form the iptables firewall dirver to the ovs one | |
| 19:48:18 | markguz_ | this happened to me when i did a non-live migrate of a shutdown instance to a new host | |
| 19:48:42 | sean-k-mooney | hum it should not happen in that case | |
| 19:49:10 | sean-k-mooney | something obviosly went wrong there should be an error in the neutron server log | |
| 19:49:46 | markguz_ | yeah. haven't had time to deep dive. Was focussed on getting the instance back online | |
| 19:50:11 | sean-k-mooney | ist the instance still in resize_verify or did this happen after that point | |
| 19:50:33 | sean-k-mooney | if you had not confirmed the migrate/resize then you could have reverted | |
| 19:51:02 | sean-k-mooney | if you had then ya db edit or unest and reset the host to rebind the port then hard reboot | |
| #openstack-nova - 2020-05-12 | |||
| 00:43:17 | openstackgerrit | xuyuanhao proposed openstack/nova master: Optimization the soft-delete logical https://review.opendev.org/724260 | |
| 01:25:32 | openstackgerrit | xuyuanhao proposed openstack/nova master: Optimization the soft-delete logical https://review.opendev.org/724260 | |
| 02:03:13 | openstackgerrit | Wenping Song proposed openstack/nova master: error may occur when filter scheduler with accelerator https://review.opendev.org/722651 | |
| 03:16:56 | openstackgerrit | xuyuanhao proposed openstack/nova master: Optimization the soft-delete logical https://review.opendev.org/724260 | |
| 04:29:41 | openstackgerrit | Wenping Song proposed openstack/nova master: error may occur when filter scheduler with accelerator https://review.opendev.org/722651 | |
| 05:44:08 | openstackgerrit | Harshavardhan Metla proposed openstack/nova master: [Nova] Add reference to Placement installation guide https://review.opendev.org/726936 | |
| 06:38:17 | gibi | good morning Nova | |
| 06:47:33 | ikla | how do I passthrough multiple pci devices in nova? | |
| 06:53:36 | gibi | ikla: https://docs.openstack.org/nova/pike/admin/pci-passthrough.html#configure-a-flavor-controller | |
| 07:00:54 | sean-k-mooney | ikla: you just create a flavor with multiple alia's referenced | |
| 07:09:56 | ikla | I have rocky | |
| 07:10:37 | jkulik | hi, is there something like sub-flavors somewhere on nova's roadmap? Having a flavor that maps to different specific flavors per hardware generation would be great. | |
| 07:16:01 | ikla | do I need to define the devices in the nova controller? | |
| 07:18:55 | gibi | ikla: the alias needs to be defined both on the controller and on the computes, the passthrough_whitelist needs to be defined on each compute | |
| 07:19:59 | gibi | jkulik: I don't know about such feature on the roadmap. I think you can implement that top of nova | |
| 07:20:27 | ikla | do I have multiple lines with passthrough_whitelist ? or can I do it all on one line? | |
| 07:21:51 | bauzas | good morning nov | |
| 07:21:57 | bauzas | err, nova even | |
| 07:22:13 | gibi | ikla: you can have a full json dict, see the config doc https://docs.openstack.org/nova/rocky/configuration/config.html#pci.passthrough_whitelist | |
| 07:22:26 | gibi | ikla: or even a list of such dicts | |
| 07:22:36 | gibi | bauzas: o/ | |
| 07:25:23 | ikla | same for alias? | |
| 07:26:12 | gibi | ikla: I think alias is a single dict, so you have to have multiple line of alias = {...} in your config to have multiple aliases | |
| 07:28:24 | ikla | thanks | |
| 07:28:33 | ikla | passthrough cannot have multiple lines? | |
| 07:29:09 | jkulik | gibi, by on top of nova, do you mean on the client? Even if we would control the client, which we don't necessarily, we would have to decide on the precise flavor before going into scheduling afaics. So if a user doesn't care about the hardware version, we would have to make a decision anyways instead of taking "what's free" automatically. | |
| 07:32:29 | ikla | nvrmind :) | |
| 07:34:48 | gibi | ikla: I think passthrough_whitelist also can be used multiple times | |
| 07:36:06 | ikla | does passthrough_whitelist work on rocky or does it need to be prefixed with pci_ ? | |
| 07:37:39 | gibi | ikla: in the [pci] section you can use passthrough_whitelist config | |
| 07:50:49 | openstackgerrit | Harshavardhan Metla proposed openstack/nova master: [Nova] Add reference to Placement installation guide https://review.opendev.org/726936 | |
| 07:59:03 | openstackgerrit | James Page proposed openstack/nova stable/queens: Fix overcommit for NUMA-based instances https://review.opendev.org/726868 | |
| 07:59:03 | openstackgerrit | James Page proposed openstack/nova stable/queens: hardware: fix memory check usage for small/large pages https://review.opendev.org/726867 | |
| 08:19:27 | openstackgerrit | sean mooney proposed openstack/nova-specs master: move implemented specs in ussuri https://review.opendev.org/721278 | |
| 08:19:55 | sean-k-mooney | gibi: sorry ment to do that last week ^ if you want any changes let me know and ill respin the patch | |
| 08:29:20 | huaqiang | stephenfin: There are ~20 patches in bp/use-pcpu-and-vcpu-in-one instance, for roles of py-checks, realtime policy, and fixes for hardware.py | |
| 08:29:37 | huaqiang | these are not depending on each other so much | |
| 08:29:51 | huaqiang | how about let me re-arrange the order | |
| 08:30:40 | huaqiang | and resolving some dependencies with slight change to make it possible to be reviewed parallelly | |
| 08:32:18 | openstackgerrit | Nalini Varshney proposed openstack/nova master: Add migration to make key field type VARBINARY in aggregate_metadata table, https://review.opendev.org/725522 | |
| 08:35:00 | bauzas | gibi: impressive count on open bugs https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New | |
| 08:35:12 | bauzas | gibi: how have you triaged them ? | |
| 08:48:12 | gibi | bauzas: most of the did not have enough information | |
| 08:48:50 | gibi | bauzas: and during the last two weeks we get only about 5 new bug reports so the low inflow helped a lot | |
| 08:49:51 | gibi | sean-k-mooney: thanks, I will check it | |
| 08:50:42 | gibi | jkulik: what you want to achive? Do you want to move users from old HW gen to new HW gen over time? | |
| 08:51:07 | stephenfin | huaqiang: Sure. The only issue with that is that future rebases are harder. If you can keep the existing +2s though, go for it | |
| 08:52:29 | jkulik | gibi, we have different hardware versions in place at the same time, where, because of NUMA and whatnot, flavors differ slightly. We want a user to be able to deploy a "2 TB instance" flavor, even if that means 1.8 on one node and 2.1 on the other. | |
| 08:53:35 | sean-k-mooney | jkulik: that is how it works by default | |
| 08:54:18 | sean-k-mooney | unless you meen 1.8 TB on one and 2.1 TB on the other? in not sure what those number refer too | |
| 08:54:48 | jkulik | sean-k-mooney, the flavor has to map to 1.8 TB on one hardware version and 2.1 TB on the other | |
| 08:55:00 | sean-k-mooney | jkulik: ya that is not allowed | |
| 08:55:01 | jkulik | sean-k-mooney, we just want our users to be able to specify "give me that 2 TB thingy" | |
| 08:55:22 | sean-k-mooney | right but its a 1.8TB thing and a 2.1TB thing | |
| 08:55:31 | sean-k-mooney | its not a 2TB thing in either case | |
| 08:55:43 | jkulik | because it's hard for us to keep hypervisors empty enough to support that size, the user can't really know up-front what hardware is currently free | |
| 08:55:47 | sean-k-mooney | you could use boot form volume and not provide any default root disk | |
| 08:56:09 | jkulik | we're talking RAM here :/ | |
| 08:56:20 | sean-k-mooney | oh i taught you ment disk | |
| 08:56:33 | sean-k-mooney | and the user should know know up front how much ram is free | |
| 08:56:38 | sean-k-mooney | *should not | |
| 08:57:09 | sean-k-mooney | jkulik: it sound like you want to reconfigure the scheduler to pack | |
| 08:57:10 | openstackgerrit | Tony Su proposed openstack/nova-specs master: Re-propose provider-config-file spec for Victoria https://review.opendev.org/725788 | |
| 08:57:16 | jkulik | I don't see how we could tell the user what flavors could currently get deployed via nova's api | |
| 08:57:39 | sean-k-mooney | if you configure the schduler to pack based on ram usage it will try to keep hosts free if it will fit on othet hosts | |
| 08:57:57 | sean-k-mooney | jkulik: well you cant and that is kind fo intentional | |