| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-15 | |||
| 16:42:57 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-15-16.00.txt | |
| 16:42:57 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-15-16.00.html | |
| 16:42:57 | opendevmeet | Meeting ended Tue Jun 15 16:42:57 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:42:57 | gibi | #endmeeting | |
| 16:42:57 | opendevmeet | Log: https://eavesdrop.opendev.org/meetings/nova/2021/nova.2021-06-15-16.00.log.html | |
| 16:42:57 | opendevmeet | Minutes (text): https://eavesdrop.opendev.org/meetings/nova/2021/nova.2021-06-15-16.00.txt | |
| 16:42:57 | opendevmeet | Minutes: https://eavesdrop.opendev.org/meetings/nova/2021/nova.2021-06-15-16.00.html | |
| 16:43:50 | sean-k-mooney | pjakuszew: im going to get somethign to drink but if you have more question regarding the embeded flavor feel free to ask them | |
| 16:43:54 | sean-k-mooney | brb | |
| 16:46:54 | gibi | fyi I noticed a new version of the wierd pip version conflict, now with paramiko. Added the info to https://bugs.launchpad.net/nova/+bug/1931864 | |
| 16:46:58 | pjakuszew | sean-k-mooney: just one, should I change both Instance.flavor.extra_specs and RequestSpec.flavor.extra_specs to the new ones from Flavor, if I want the instance migration to work in the same way as the new instances with that modified flavor | |
| 16:47:53 | pjakuszew | i.e. if I added 'foo':'bar' to flavor extra_specs, should I modify both Instance and RequestSpec so migrations behave in the same way as for new instances which have these specs already | |
| 16:49:19 | pjakuszew | this is all assuming that I have enabled InstanceAggregateExtraSpecs scheduler filter and now I want the old instance migrations to behave like the new ones | |
| 16:52:14 | sean-k-mooney | yes you would have to update both | |
| 16:52:35 | sean-k-mooney | the request spec flavor is used for schduling but the instinace.flavor is used form cretating the vm xml | |
| 16:52:55 | sean-k-mooney | but it depends on your goal | |
| 16:53:31 | sean-k-mooney | if you only wanted to sync the extra spec use for the InstanceAggregateExtraSpecs filter technically only the request spec flavor would need to be updated | |
| 16:54:42 | pjakuszew | right, though it wouldn't probably hurt to also have the Instance flavor in-sync, just to keep things "clean" | |
| 16:55:18 | sean-k-mooney | am is your pimary usecase the InstanceAggregateExtraSpecs filter | |
| 16:55:37 | sean-k-mooney | if so you could limit the extra spec update to just those that are prefixed with aggregate_instance_extra_specs | |
| 16:56:19 | sean-k-mooney | pjakuszew: the main issue is the two flavor opies are stored in different databases | |
| 16:56:33 | sean-k-mooney | so you cant update both in the same transaction i bleive | |
| 16:58:24 | pjakuszew | it shouldn't be a big issue in this situation | |
| 16:58:54 | sean-k-mooney | the main thing you would have to do is look up the cell/instance maping to know which db to update it in for the instnace copy | |
| 16:58:54 | pjakuszew | ok, then my main focus is requestspec flavor object | |
| 16:59:35 | sean-k-mooney | i would start with the request spec yes and preferably limit it to extra specs that are used by that filter | |
| 16:59:57 | sean-k-mooney | so extra specs with aggregate_instance_extra_specs: or no namespeace | |
| 17:00:58 | sean-k-mooney | if you wanted all extra specs to be updated via nova manage in this way i think you would have to update the copy in instnace_extra also | |
| 17:02:00 | pjakuszew | yes I have some preliminary version of that added into nova-manage locally for tests | |
| 17:03:26 | pjakuszew | in current form it iterates over InstanceList and does 'if instance.flavor.extra_specs != flavor.extra_specs: instance.flavor.extra_specs = flavor.extra_specs; instance.save()' | |
| 17:04:44 | pjakuszew | that was before we talked | |
| 17:05:09 | pjakuszew | now I know that reqspec.flavor.extra_specs = flavor.extra_specs is the way | |
| 17:09:06 | pjakuszew | and there's a separate command which prints a table of instances that don't have extra_specs matching their flavors | |
| 17:11:18 | pjakuszew | sean-k-mooney: thanks for the help, it is now more clear to me | |
| 18:50:50 | opendevreview | sean mooney proposed openstack/nova-specs master: [WIP] pci device tracking in placment https://review.opendev.org/c/openstack/nova-specs/+/791047 | |
| 18:55:54 | opendevreview | Merged openstack/nova stable/wallaby: Error anti-affinity violation on migrations https://review.opendev.org/c/openstack/nova/+/794328 | |
| 21:47:20 | opendevreview | Merged openstack/nova master: Remove references to 'inst_type' https://review.opendev.org/c/openstack/nova/+/778548 | |
| #openstack-nova - 2021-06-16 | |||
| 00:03:47 | opendevreview | norman shen proposed openstack/nova master: Saving security group to info_cache https://review.opendev.org/c/openstack/nova/+/786348 | |
| 00:53:16 | opendevreview | Merged openstack/nova master: libvirt: Set driver_iommu when attaching virtio devices to SEV instance https://review.opendev.org/c/openstack/nova/+/794639 | |
| 02:19:05 | opendevreview | melanie witt proposed openstack/nova master: Add test coverage for API version headers in CORS https://review.opendev.org/c/openstack/nova/+/796580 | |
| 02:19:47 | opendevreview | melanie witt proposed openstack/nova master: Add test coverage for API version headers in CORS https://review.opendev.org/c/openstack/nova/+/796580 | |
| 06:17:50 | kevinz | Hi lyarwood, would be really appreciated if you can help to review this for live migrate on Arm64: https://review.opendev.org/c/openstack/nova/+/763928, the patch has been updated | |
| 06:56:21 | opendevreview | Balazs Gibizer proposed openstack/os-resource-classes master: Add packet rate related resource classes https://review.opendev.org/c/openstack/os-resource-classes/+/796591 | |
| 06:58:29 | gibi | stephenfin: do you have an example how to backport db migrations with alembic? | |
| 07:28:06 | opendevreview | Balazs Gibizer proposed openstack/placement master: Bump os-resource-classes deps to 1.0.0 https://review.opendev.org/c/openstack/placement/+/796593 | |
| 07:31:27 | gibi | stephenfin, melwitt: it is a trivial bump to keep the modules in sync ^^ | |
| 07:36:47 | opendevreview | Balazs Gibizer proposed openstack/placement master: Bump os-resource-classes requirements https://review.opendev.org/c/openstack/placement/+/796595 | |
| 07:45:43 | opendevreview | Yongli He proposed openstack/nova master: smartnic support - reject server move and suspend https://review.opendev.org/c/openstack/nova/+/779913 | |
| 07:45:45 | opendevreview | Yongli He proposed openstack/nova master: smartnic support - functional tests https://review.opendev.org/c/openstack/nova/+/780147 | |
| 07:47:06 | yonglihe | gibi, alex_xu had reviewed the smart nic patch set several rounds, and about to review another round, just after i add more functional/unit test. | |
| 07:58:38 | gibi | yonglihe: OK. I will try to look at the patches as promised on the meeting yesterday | |
| 07:59:08 | yonglihe | thanks. | |
| 08:20:50 | opendevreview | liujiong proposed openstack/nova master: Do not create attachment for old root volume https://review.opendev.org/c/openstack/nova/+/795950 | |
| 08:42:58 | gibi | lyarwood: FYI limestone is now disabled https://review.opendev.org/c/openstack/project-config/+/796590 due to mirror issues. We only saw https://review.opendev.org/c/openstack/project-config/+/796590 from limestone so that issue hopefuly removed from the active gate faliures | |
| 08:43:33 | gibi | I wanted to link to the bug https://bugs.launchpad.net/nova/+bug/1931864 | |
| 08:44:13 | opendevreview | Lee Yarwood proposed openstack/nova stable/wallaby: libvirt: Set driver_iommu when attaching virtio devices to SEV instance https://review.opendev.org/c/openstack/nova/+/796607 | |
| 08:54:41 | stephenfin | gibi: alembic is a bit different. You don't need placeholders since the migrations don't have to be applied linearly. Each migration encodes its predecessor inline, so you could backport the new migration and simply rework the other migrations either side | |
| 08:55:11 | stephenfin | I haven't spent a long time thinking about it though. We haven't backported a migration in 4 or 5 years now, iirc | |
| 08:57:21 | gibi | stephenfin: I got a pointer from slaweq how neutron did it supporting a downstream backport in https://review.opendev.org/c/openstack/neutron/+/601336/92/neutron/db/migration/alembic_migrations/versions/xena/expand/d863c3bdc0c5_add_active_allowed_address_pairs.py | |
| 08:57:40 | gibi | stephenfin: so they needed to prepare the patch on master to be conditional | |
| 08:57:57 | gibi | i.e. not to fail on if the change already applied | |
| 08:58:19 | gibi | I have to run now but we can talk about it later | |
| 08:58:36 | stephenfin | okay, no worries. We'll just have to document it, I suppose | |
| 09:12:55 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove dead code https://review.opendev.org/c/openstack/nova/+/786291 | |
| 09:12:56 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove 'nova.db.sqlalchemy.utils' https://review.opendev.org/c/openstack/nova/+/786292 | |
| 09:12:57 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Use module-level imports for sqlalchemy https://review.opendev.org/c/openstack/nova/+/786295 | |
| 09:12:57 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove unused DB methods https://review.opendev.org/c/openstack/nova/+/786293 | |
| 09:12:58 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Fold in indexes https://review.opendev.org/c/openstack/nova/+/786296 | |
| 09:12:59 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Fold in ForeignKey constraints https://review.opendev.org/c/openstack/nova/+/786297 | |
| 09:13:00 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove 'nova.db.base' module https://review.opendev.org/c/openstack/nova/+/786298 | |
| 09:13:01 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Copy docs from 'nova.db.*' to 'nova.db.sqlalchemy.*' https://review.opendev.org/c/openstack/nova/+/786299 | |
| 09:13:02 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Clean up migration code https://review.opendev.org/c/openstack/nova/+/786301 | |
| 09:13:02 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Synchronize function signatures https://review.opendev.org/c/openstack/nova/+/786300 | |
| 09:13:03 | opendevreview | Stephen Finucane proposed openstack/nova master: db: Use module-level imports for sqlalchemy (for real) https://review.opendev.org/c/openstack/nova/+/796519 | |
| 09:19:04 | opendevreview | Lee Yarwood proposed openstack/nova stable/victoria: libvirt: Set driver_iommu when attaching virtio devices to SEV instance https://review.opendev.org/c/openstack/nova/+/796611 | |
| 09:44:39 | opendevreview | Lee Yarwood proposed openstack/nova stable/ussuri: libvirt: Set driver_iommu when attaching virtio devices to SEV instance https://review.opendev.org/c/openstack/nova/+/796618 | |
| 09:49:01 | kashyap | sean-k-mooney[m]: Hey, remind me again: do you think we can set a different display device based on guest's capabilities? E.g. if the guest has a virtio-gpu driver, use "virtio-vga" and so on | |
| 10:06:43 | stephenfin | lyarwood, gibi: bauzas is out for all of this week, right? Could I ask you to work through that DB series before it goes into merge conflict again. It's very trivial, if that helps (mostly moving things around in prep for alembic) | |
| 10:06:57 | bauzas | no, I'm here | |
| 10:07:02 | alex_xu | gibi: I reviewed few around on first three patches, since the major logic on the the thrid one. | |
| 10:07:20 | bauzas | I was just having a conflict for the upstream meeting | |
| 10:07:40 | stephenfin | bauzas: oh, sorry /o\ in that case, I might ask you to take a look also, if you can :) | |
| 10:07:59 | bauzas | stephenfin: yup, I can do it | |
| 10:08:05 | stephenfin | great, ty | |
| 10:10:08 | stephenfin | elodilles_afk: lyarwood: melwitt: Now that we have the cherry-pick check to prevent us backporting a change out-of-order, would it make sense to start approving a whole series of backports at once and relying on said check to prevent out-of-order merges? | |
| 10:29:04 | lyarwood | stephenfin: sorry was on a call, happy to help with the DB series. We can but until the parent branch changes have landed the SHAs can still change but I guess that's the case either way. I'd be happy justifying +W'ing something if the parent is already W'd tbh. | |
| 10:29:33 | stephenfin | doesn't the cherry-pick script take care of that? | |
| 10:29:37 | stephenfin | the SHAs | |
| 10:29:51 | lyarwood | Yeah checking them, it doesn't automatically update anything | |
| 10:30:12 | lyarwood | I was agreeing that we may as well ACK things all the way down and rely on the script | |
| 10:30:21 | stephenfin | ah, okay, yeah, that's my thinking | |
| 10:30:34 | bauzas | in general, we prefer to hold stable changes until master merges | |
| 10:30:42 | bauzas | as indeed SHA1s can change | |
| 10:30:45 | lyarwood | right stephenfin's point is after that on stable | |
| 10:30:53 | stephenfin | oh, I'm not arguing for approving before master is merged | |
| 10:30:55 | lyarwood | instead of waiting for each branch to merge | |
| 10:30:58 | stephenfin | we should definitely wait for that | |
| 10:31:10 | lyarwood | there is a potential race at that point stephenfin | |
| 10:31:19 | lyarwood | the older branches having less CI | |
| 10:31:20 | bauzas | stephenfin: sorry if i misunderstood, your concern is about a series ? | |