| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-25 | |||
| 12:44:00 | gibi | it is just a complication | |
| 12:44:06 | gibi | thanks | |
| 12:44:12 | sean-k-mooney | no worries | |
| 12:44:40 | sean-k-mooney | the other complication is while we support numa affinity policies with pci device/sriov ports we dont create a numa toplogy when you use them by default | |
| 12:44:56 | sean-k-mooney | we just enforce those policies if you also request numa for an instance | |
| 12:45:05 | gibi | I see | |
| 12:46:24 | sean-k-mooney | the descrioption of FLAVOR-NODES is not really correct | |
| 12:46:33 | sean-k-mooney | for a different reason | |
| 12:46:41 | sean-k-mooney | no of these values are related to host toplogy | |
| 12:47:02 | sean-k-mooney | hw:numa_nodes is the number of virtual numa_nodes that we present to the guest | |
| 12:47:34 | sean-k-mooney | the relationship with the host numa nodes is a libvirt driver implemeatnion detail and is not guarenteed by the api currenly | |
| 12:47:53 | sean-k-mooney | althogh it is the behavior the numa toplogy filter will give you | |
| 12:47:57 | gibi | it talks about where the cpus are run on and in that sense it is correc that they can run on any host numa nodes | |
| 12:48:21 | sean-k-mooney | yes | |
| 12:49:53 | sean-k-mooney | but we technically would be allowed to change the meaning of hw:numa_nodes in libvirto to mean spread to at most N host numa nodes instead of exactly N numa nodes with out violating that api guarentees today. although the proposed placment work will actully guarentee a 1:1 mapping | |
| 12:51:02 | gibi | ahha | |
| 12:51:12 | sean-k-mooney | well actully it does not have too but we likely will to keep the same behavior | |
| 12:52:31 | sean-k-mooney | the one thing we are not allowed to do by the current api semantics is take a vm that reqest 1 numa node and spread it across several host numa nodes | |
| 12:53:20 | sean-k-mooney | i.e. we cant split virutal numa nodes across host numa nodes without regressing performance | |
| 12:53:35 | gibi | yes, that would be a serious bug | |
| 12:54:01 | sean-k-mooney | the other way around is ok but if we allow it in the futrue we would likely want to contol it via policy | |
| 12:54:30 | sean-k-mooney | e.g. hw:numa_packing=true or something like that and default to false | |
| 12:55:01 | sean-k-mooney | anyway we dont need to worry about that right now anyway | |
| 12:55:34 | gibi | thanks for the explanation | |
| 12:56:53 | sean-k-mooney | the more this tribal knowadge spreads the less of a bus factor there is | |
| 13:01:08 | gmann | stephenfin: thanks, will check. | |
| 13:01:25 | gmann | stephenfin: gibi this is last patch for deprecated api policy-work - https://review.opendev.org/#/c/747784/ | |
| 13:02:47 | gibi | gmann: thanks | |
| 13:02:50 | gibi | +2 | |
| 13:07:56 | stephenfin | gmann: Some grammar nits on the reno | |
| 13:08:29 | gmann | stephenfin: thanks, will fix | |
| 13:09:06 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add reno for deprecated APIs policy changes https://review.opendev.org/747784 | |
| 13:09:11 | gmann | stephenfin: ^^ | |
| 13:09:40 | stephenfin | ta | |
| 13:10:18 | gibi | approved | |
| 13:10:44 | rs_goyal__ | Hi guys, I am attaching second network interface to a compute instance based on Ubuntu OS. The issue I am facing is the name of second interface that gets created on instance when I try different ways to attach the network. First way is to attach the second interface while instance creation in which case the interface name comes as 'ens4'. Second way is attaching the interface after vm is created, where the | |
| 13:10:45 | rs_goyal__ | interface name is 'ens6'. This is only happening in case of ubuntu as it follows the 'ens*' naming of interfaces. Is there a way so that only one interface name comes in both cases so that it will be easy to create network configuration? | |
| 13:18:54 | gibi | rs_goyal__: I think what you are looking for is interface tagging https://notartom.net/2016/09/28/device-tagging-new-in-newton/ | |
| 13:32:17 | artom | gibi, rs_goyal__, and the follow-up: https://notartom.net/2017/06/20/virtual-device-role-tagging-better-explained/ | |
| 13:32:36 | artom | (How long have I been saying that I should include this in an official guide?) | |
| 13:34:46 | gibi | there is even a sequel?! \o/ | |
| 13:38:02 | rs_goyal__ | @artom @gibi | |
| 13:38:53 | rs_goyal__ | Is this only supported via nova cli or can be done via openstack cli also? | |
| 13:42:50 | gibi | rs_goyal__: looking at the help text it is not supported by the openstack cli | |
| 13:43:28 | artom | rs_goyal__, I know *I* didn't add it to osc :) | |
| 13:45:18 | rs_goyal__ | okay Thanks. | |
| 14:01:26 | openstackgerrit | Alexandre Arents proposed openstack/nova master: Add a lock to prevent race during detach_interface https://review.opendev.org/747957 | |
| 14:09:58 | openstackgerrit | sean mooney proposed openstack/nova master: Set migrate_data.vifs only when using multiple port bindings https://review.opendev.org/742180 | |
| 14:14:47 | rs_goyal__ | https://www.irccloud.com/pastebin/BUiY7qIX/ | |
| 14:14:49 | sean-k-mooney | lyarwood: this might be of interest to you https://review.opendev.org/#/c/747957/ | |
| 14:15:07 | gmann | stephenfin: gibi any of you can review this - https://review.opendev.org/#/c/738126/17 | |
| 14:15:48 | rs_goyal__ | @gibi | |
| 14:15:53 | sean-k-mooney | you were fixing issue we had with persitent xml and transient getting out of sync but maybe the locking will also help | |
| 14:16:29 | sean-k-mooney | aarents: there is potentially a seperate cause to that bug | |
| 14:16:37 | openstack | Launchpad bug 1892870 in OpenStack Compute (nova) "concurrent interface detach/attach may accidently unbind port" [Undecided,In progress] - Assigned to Alexandre arents (aarents) | |
| 14:16:37 | sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1892870 | |
| 14:17:32 | sean-k-mooney | aarents: Detaching interface %(mac)s failed because the device is no longer found | |
| 14:17:34 | sean-k-mooney | on the guest. | |
| 14:18:00 | sean-k-mooney | this can happen for other reasons then a race at lest that seamed to be the case for volumes | |
| 14:19:03 | sean-k-mooney | aarents: that siad i dont nessacarly thing adding a lock is a bad thing although your commit mentions | |
| 14:19:05 | sean-k-mooney | multiple detach/attach are run | |
| 14:19:08 | sean-k-mooney | concurrently | |
| 14:19:12 | sean-k-mooney | but you are only locking detach | |
| 14:19:31 | sean-k-mooney | you might want to use a shared lock between attach and detach | |
| 14:19:44 | sean-k-mooney | and add a lock to attach too | |
| 14:20:00 | lyarwood | sean-k-mooney: yeah I think we already lock for disks | |
| 14:20:24 | aarents | sean-k-mooney: Yes because the race exists only because of detach that sends multiple UNBIND | |
| 14:20:49 | aarents | if it is fixed on detach attach should be consistent I think | |
| 14:20:51 | sean-k-mooney | what happens if we do multiple attach api calls concurrently | |
| 14:21:39 | sean-k-mooney | aarents: since the syconisation woudl be on the interface uuid i think it would be fairly cheap to just lock both operation | |
| 14:23:23 | aarents | sean-k-mooney: hum why not | |
| 14:23:42 | sean-k-mooney | lyarwood: and yes we already lock in detach_volume using the volume_uuid | |
| 14:24:22 | aarents | lock only on interface uuid not instance_uuid-interface_uuid but on bot attach and detach ? | |
| 14:24:59 | sean-k-mooney | so volumes lock on both attach and detach | |
| 14:25:47 | sean-k-mooney | i would change teh lock name from 'detach_interface-%s-%s' to 'interface-%s-%s' | |
| 14:26:16 | sean-k-mooney | you can pass the instance uuid and port but honestly the neutron port uuid will be unique so the instance uuid is not actully needed | |
| 14:26:53 | aarents | sean-k-mooney and put it on both detach and attach ? | |
| 14:27:02 | sean-k-mooney | yep | |
| 14:27:06 | aarents | make sense | |
| 14:27:11 | sean-k-mooney | to keep it consitent with volumes | |
| 14:27:20 | aarents | yep | |
| 14:27:39 | sean-k-mooney | volumes actully does @utils.synchronized(instance.uuid) | |
| 14:27:50 | sean-k-mooney | but i prefer using the port uuid | |
| 14:28:14 | sean-k-mooney | unless we want to block detaching differnet ports in parallel | |
| 14:28:40 | sean-k-mooney | i guess that is why the instance uuid is used for volumes to prevent detaching multiple volumes in paralel | |
| 14:28:45 | sean-k-mooney | but im not sure that is actully required | |
| 14:29:22 | aarents | sean-k-mooney: yeah but I want to keep it // I make some test | |
| 14:30:00 | sean-k-mooney | ya using a uniqe lock name for this is fine | |
| 14:30:43 | sean-k-mooney | if at some point we really need to make it instance wide we can just drop the port uuid | |
| 14:30:50 | openstackgerrit | Stephen Finucane proposed openstack/nova master: functional: Add 'start_compute' helper https://review.opendev.org/746943 | |
| 14:30:50 | openstackgerrit | Stephen Finucane proposed openstack/nova master: functional: Provide default 'host_info' for '_get_connection' https://review.opendev.org/746942 | |
| 14:30:51 | openstackgerrit | Stephen Finucane proposed openstack/nova master: functional: Clean up PCI tests https://review.opendev.org/746945 | |
| 14:30:51 | openstackgerrit | Stephen Finucane proposed openstack/nova master: functional: Use tempdir for CONF.instances_path https://review.opendev.org/746944 | |
| 14:30:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conductor: Don't use setattr https://review.opendev.org/746947 | |
| 14:30:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: functional: Add resize tests for PCI servers https://review.opendev.org/746946 | |
| 14:30:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: fixtures: Handle binding of first port https://review.opendev.org/746949 | |
| 14:30:53 | openstackgerrit | Stephen Finucane proposed openstack/nova master: functional: Add test for SR-IOV neutron ports https://review.opendev.org/746948 | |
| 14:30:54 | openstackgerrit | Stephen Finucane proposed openstack/nova master: functional: Add live migration tests for PCI, SR-IOV servers https://review.opendev.org/746950 | |
| 14:31:19 | aarents | sean-k-mooney, I made some test reauest 7 detach on same instance taking 4s to detach with a lock per instance-port and > 10sec when only instance | |
| 14:32:27 | sean-k-mooney | yep as long as libvirt safely handels the parrale detach request we dont need to lock at the instance levle | |