Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-06-15
16:21:55 sean-k-mooney really ok i thought that was focal
16:22:04 gmann from victoria we moved to focal
16:22:07 sean-k-mooney hopefully that wont be hard to fix then
16:22:35 sean-k-mooney Could not find the requested service libvirtd-ro.socket: host
16:22:43 sean-k-mooney ok so likely hte service names are different
16:22:59 sean-k-mooney both that should be a quick fix
16:23:14 gibi OK I think we generated ideas about the way forwards
16:23:23 gibi anything else about stable?
16:23:38 elodilles nothing from me
16:24:29 gibi OK moving on
16:24:44 gibi skipping the libvirt subteam topic as bauzas is absent, but he said nothing to report
16:24:50 gibi #topic Open discussion
16:24:57 gibi there is one item on the agenda
16:25:04 gibi (yonglihe)smartnic support need one extra core reviewer , we have alex now, anyone else could help? thanks : https://review.opendev.org/c/openstack/nova/+/779913 (yongli could not attending due to time slot...)
16:25:58 gibi looking at the patches I think alex_xu haven't reviewed them
16:26:18 gibi or at least not recently
16:26:50 gibi as I reviewed these in the past I can be the second core
16:27:05 gibi but I will wait for Alex to to the first rounds
16:27:50 gibi any comment?
16:28:38 sean-k-mooney i can proably take another look at that although i kind of wanted
16:28:48 sean-k-mooney someone else who can review the code to be on board with it
16:28:58 sean-k-mooney oh that the implemtion not the spec
16:29:06 gibi yep the spec is approved
16:30:24 sean-k-mooney well i can try and review the code i guess but maybe stephenfin or bauzas could take a look?
16:30:59 stephenfin I can give it a shot
16:31:18 gibi OK thanks I think this is more than enough :)
16:31:25 gibi any other topic for today?
16:32:23 stephenfin oh, one
16:32:28 stephenfin specless BP approval
16:32:31 stephenfin for https://blueprints.launchpad.net/nova/+spec/remove-sqlalchemy-migrate
16:32:40 stephenfin I thought I had done this before, but clearly not
16:32:53 stephenfin that's the spec to track replacing sqlalchemy-migrate with alembic
16:33:18 sean-k-mooney you mean blueprint
16:33:22 sean-k-mooney or is there actully a spec
16:33:53 stephenfin sorry, blueprint, yeah
16:33:57 sean-k-mooney i assume you want to track it as a specless blueprint
16:34:00 sean-k-mooney ok
16:34:23 opendevreview Lee Yarwood proposed openstack/nova stable/ussuri: zuul: Start to migrate nova-live-migration to zuulv3 https://review.opendev.org/c/openstack/nova/+/795432
16:34:49 gibi stephenfin: do you forsee any complication that might warrant a spec?
16:35:09 stephenfin not at the moment, no. It's very simple if tedious so far
16:35:28 sean-k-mooney in the ptg we said """create a contributor doc showing how a migration will look like after the change. Document how to backport a migration to stable""" and """figure out if alembic collapsing migrations can this cause timeouts for big migrations"""
16:35:34 stephenfin if I encounter something that I think warrants discussion, I'll happily write one then
16:35:44 sean-k-mooney did we we figure out the latter
16:36:06 stephenfin I haven't managed to rewrite all the migrations yet, so no
16:36:19 sean-k-mooney i think that was the only concern we had e.g. how does it scale
16:36:25 sean-k-mooney ok
16:36:43 opendevreview Lee Yarwood proposed openstack/nova master: gate: Remove test_evacuate.sh https://review.opendev.org/c/openstack/nova/+/796523
16:36:46 stephenfin though neutron's use of this suggests we'll be fine (famous last words :))
16:36:47 sean-k-mooney i suspect as well as what we currently use or at least well enough for neutron
16:36:53 stephenfin yup
16:37:18 sean-k-mooney i dont really have any open quetsion that woudl warrent a spec
16:37:31 sean-k-mooney provided you provide the contib doc as part of the series
16:38:12 gibi any objection against approving it as specless bp?
16:39:12 gibi then it is approved
16:39:19 gibi any other topic for today?
16:39:27 stephenfin hurrah
16:39:29 stephenfin not from me
16:40:15 sean-k-mooney am one
16:40:19 gibi any feedback on having the meeting on this channel?
16:40:29 sean-k-mooney gibi: when did you want to do the next spec review day
16:40:38 dansmith ++ on meeting in channel :)
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 Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-15-16.00.log.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 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

Earlier   Later