Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-06-15
16:40:39 sean-k-mooney gibi: and i think it worked ok
16:40:51 gmann ++
16:40:57 gibi sean-k-mooney: 6th of July maybe?
16:41:24 stephenfin meeting in the channel seems sensible so far, yup
16:41:26 sean-k-mooney ya that gives a few days befor m2 on the 12th
16:41:27 gibi that is a bit more than a week before the freeze
16:41:29 sean-k-mooney so works for me
16:41:36 stephenfin as does that date
16:42:05 sean-k-mooney oh m2 is the 15th
16:42:07 sean-k-mooney ya
16:42:25 sean-k-mooney ok that was all i wanted to ask
16:42:38 gibi if nothing else then thanks for joining.
16:42:53 gibi I give the channel back :)
16:42:57 opendevmeet Minutes: https://eavesdrop.opendev.org/meetings/nova/2021/nova.2021-06-15-16.00.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 Log: https://eavesdrop.opendev.org/meetings/nova/2021/nova.2021-06-15-16.00.log.html
16:42:57 gibi #endmeeting
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 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-15-16.00.html
16:42:57 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-15-16.00.txt
16:42:57 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-15-16.00.log.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 pjakuszew ok, then my main focus is requestspec flavor object
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: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: Remove unused DB methods https://review.opendev.org/c/openstack/nova/+/786293
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: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: Synchronize function signatures https://review.opendev.org/c/openstack/nova/+/786300
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: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.

Earlier   Later