Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-01-27
17:33:44 stephenfin yeah, makes sense in hindsight
17:37:14 tosky sean-k-mooney: thanks for both :)
19:18:32 openstackgerrit Merged openstack/nova stable/pike: Avoid redundant initialize_connection on source post live migration https://review.opendev.org/683008
19:27:28 KeithMnemonic Eureka, that BDM patch on stable/pike finally merged. Thanks a ton for all of your endless help mriedem: , melwitt: and of course hemna:
19:39:04 melwitt cool KeithMnemonic
20:13:59 openstackgerrit Lee Yarwood proposed openstack/nova master: zuul: Add Fedora based jobs to the experimental queue https://review.opendev.org/701231
20:14:08 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP libvirt: Use virDomainBlockCopy to swap volumes with >= 5.10.0 https://review.opendev.org/696834
23:18:24 efried dansmith: remind me (again) which direction we're allowed to have mismatched versions: controller newer than compute or vice versa?
23:22:30 sean-k-mooney controler newer then compute i think
23:22:54 sean-k-mooney we expect the contol plane to be upgraded first
23:25:04 efried k
23:26:44 sean-k-mooney in either case the sender is ment to back level to the max version supported by the reciver if memory serves. greade upgrade the contol plane first so that is what we test.
23:27:28 efried I'm trying to understand the upgrade implications of the extra spec validation thing.
23:27:45 sean-k-mooney ah ok
23:28:53 sean-k-mooney that does rais an intersting question. if the extra specs were ovo should you allow the flaovr to be back leveled if a unsupporte extra spec was requested.
23:29:26 sean-k-mooney i have not review that proposal by the way so that is jsut me specualting but i would lean towrads no
23:29:32 efried I think it's simpler than that.
23:30:23 efried Ultimately an extra spec that's used on/by the compute (which is many of them) is being validated at the API.
23:30:50 sean-k-mooney yes at least initally
23:31:23 efried and if the versions are mismatched, we could have an extra spec that the control plane (because newer) understands, but the compute won't. If the developer of that extra spec is doing their job right, they'll have tied it to a request filter so you would never land on that compute, so probably no big deal.
23:31:48 efried But the other way around is also possible. If we deprecate/remove support for an extra spec, the control plane thinks it's invalid while the compute still supports it.
23:32:15 efried I guess that means you have to wait *two* cycles before you get to add the validator that forbids the removed extra spec.
23:32:16 efried or something.
23:33:07 sean-k-mooney ya althoguh im not sure we have ever remvoed an extra spec
23:33:28 sean-k-mooney i can think of one or two i woudl consider removing but i dont think we have ever actully done it
23:33:50 sean-k-mooney and actully i have reviewd https://review.opendev.org/#/c/682655/1/specs/ussuri/approved/flavor-extra-spec-validators.rst but it was last cycle
#openstack-nova - 2020-01-28
00:13:19 dansmith efried: compute is the only thing allowed to be old
00:13:25 efried ack
00:13:59 dansmith efried: the controllers are always required to enforce the version rule, so if it's something that the compute might not be able to do, it needs to check the version and refuse, downlevel, or find a compute that *can* handle it
00:14:24 efried right, but the point of this validation is that it's done at flavor creation time -- there's no compute in the picture.
00:14:53 efried sorry, you were answering my actual question, thanks.
00:15:21 dansmith there's compute at boot time, so you can create a newer flavor, you just need to refuse to boot an instance from it when there are no computes able to handle the request
00:16:40 efried right
00:17:16 efried we just need to be careful not to enforce a new rule that strictifies something until we're sure all the computes are upgraded. Kind of thing.
00:17:51 dansmith not sure what you mean exactly..
00:18:28 dansmith you want to ban creation of the flavor with something if some computes are still old? that's definitely okay if it's appropriate, just not required if it's a spec that just specifies something about the instance
00:20:11 efried I'm saying if we decide to, I don't know, deprecate and remove the 'shared' hw:cpu_policy, it would be reasonable to think you could change the validator accordingly to bounce new flavors with hw:cpu_policy=shared. But you can't, because old computes can (and should be allowed to) still handle 'shared'.
00:20:42 efried (I know that's not a good example, just trying to explain the issue.)
00:22:18 sean-k-mooney am we proably would want a config option of some kind to to contol how deprecations are treated
00:22:48 sean-k-mooney so warn by default and make it an error if you opt in.
00:23:14 sean-k-mooney or something but i thnk we can cross that bridge when we have a example that requires it
00:24:11 efried Well, I definitely think we should have a granny switch that turns the whole validator on or off.
00:24:23 efried I don't know about per-key, if that's what you're suggesting.
00:24:42 sean-k-mooney i was more thinkg a strict vs compatiblity mode thing
00:24:55 sean-k-mooney rather then per key
00:26:34 sean-k-mooney if we wanted to deprecate something then we would mark it as such in the validtor and consier it an error in stict mode but just warn on it in compatibliyt mode. then if we drop support entirely we can graduate to always an error becasue we know it will not be supprotin in n+X releases
00:26:52 sean-k-mooney that said im not sure we need to do that
00:27:15 sean-k-mooney if the extra spec is not support by a compute anymore its just ignored
00:27:51 dansmith efried: right so that's an example where controlling the flavor definition based on compute levels would be good.. where changing the flavor impacts the way computes behave, as opposed to just something that affects the instance like a new disk controller or something
00:28:40 efried yikes.
00:29:12 dansmith yikes/
00:29:15 dansmith I'm agreeing with you
00:29:24 dansmith I mean, I think :D
06:29:53 HagunKim Hello, Nova! I have a question. Sometimes my VMs are deleted unexpectedly. What conf or log should I check??
06:29:53 HagunKim Here is nova-compute log when a vm is deleted. I removed date, req. id, instance id.
06:29:53 HagunKim INFO nova.compute.manager [instance: intance id] Terminating instance
06:29:53 HagunKim INFO nova.virt.libvirt.driver [-] [instance: intance id] Instance destroyed successfully.
06:29:54 HagunKim INFO nova.compute.manager [-] [instance: intance id] VM Stopped (Lifecycle Event)
06:29:54 HagunKim INFO nova.compute.manager [instance: intance id] During sync_power_state the instance has a pending task (deleting). Skip.
06:29:55 HagunKim INFO nova.virt.libvirt.driver [instance: intance id] Deleting instance files /var/lib/nova/instances/instance_id_del
06:29:55 HagunKim INFO nova.virt.libvirt.driver [instance: intance id] Deletion of /var/lib/nova/instances/instance_id_del complete
06:29:56 HagunKim INFO nova.compute.manager [instance: intance id] Took 23.99 seconds to destroy the instance on the hypervisor.
08:29:07 gibi HagunKim: with the request_id from your log I would grep the nova logs to see what other events lead to the deletion of the instance
08:29:22 bauzas good morning Nova
08:31:23 gibi bauzas: good morning
08:31:44 bauzas gibi: how are you ? I was a bit on and off last week
08:34:04 gibi bauzas: thanks I'm pretty OK, spent half of my last week downstream with helping planning some internal REST APIs. Do you still need to spend a lot of time downstream?
08:34:17 bauzas gibi: this week, nope
08:34:26 bauzas working on specs and the cold migration issue
08:34:32 bauzas (for GPUs)
08:34:51 bauzas if you have things to be reviewed by me, tell me
08:35:30 openstackgerrit Merged openstack/nova-specs master: support live migration with virtual persistent memory https://review.opendev.org/695863
08:36:17 gibi bauzas: I think there is a small test issue in your placement audit https://review.opendev.org/#/c/670112 but besides that it is pretty close. And the placement fixture enahncement top of that needs a squash / respin
08:37:20 gibi bauzas: on my side the qos live migration needs some review. The bootom patch was commented by dansmith so there we need a re-review from dansmith but you can be the second review if you wish https://review.opendev.org/#/c/702261/
08:37:23 bauzas gibi: sure, lemme know which test issue you found :)
08:37:42 bauzas and /me clikcs on the qos live migration series :)
08:38:55 gibi bauzas: there is two test failure in the functional test in the placement audit patch https://834f0f74916383443a4f-1960c95d24ebbbc2bc76dbab48507616.ssl.cf1.rackcdn.com/670112/13/check/nova-tox-functional-py36/61deb16/testr_results.html
08:39:01 gibi bauzas: thanks
08:39:16 gibi bauzas: you can also hit me with patches to review
08:39:49 bauzas gibi: ah shit, I thought it was a functional test race
08:39:55 bauzas since we had issues last week
08:40:23 bauzas gibi: and sure, but my point is that I'd also like to review specs and changes
08:40:42 bauzas gibi: so if you see other changes that you'd get second eyes...
08:41:23 gibi bauzas: sure I will let you know
09:34:40 openstackgerrit Kobi Samoray proposed openstack/nova master: Avoid fetching metadata when no subnets found https://review.opendev.org/679247
09:44:53 openstackgerrit Kobi Samoray proposed openstack/nova master: Avoid fetching metadata when no subnets found https://review.opendev.org/679247
09:48:04 openstackgerrit Kobi Samoray proposed openstack/nova master: Support large network queries towards neutron https://review.opendev.org/704520
11:12:24 openstackgerrit Stephen Finucane proposed openstack/os-resource-classes master: setup.cfg: Configure 'python-requires' https://review.opendev.org/704533
11:12:28 openstackgerrit Stephen Finucane proposed openstack/os-traits master: setup.cfg: Configure 'python-requires' https://review.opendev.org/704534
11:12:29 openstackgerrit Stephen Finucane proposed openstack/os-traits master: setup.cfg: Remove unused 'build_sphinx' configuration https://review.opendev.org/704535
11:17:00 openstackgerrit Vladyslav Drok proposed openstack/nova master: Make RBD imagebackend flatten method idempotent https://review.opendev.org/704330
11:25:41 openstackgerrit Kobi Samoray proposed openstack/nova master: Avoid fetching metadata when no subnets found https://review.opendev.org/679247
11:27:34 openstackgerrit Kobi Samoray proposed openstack/nova master: Avoid fetching metadata when no subnets found https://review.opendev.org/679247
11:27:52 openstackgerrit Kobi Samoray proposed openstack/nova master: Support large network queries towards neutron https://review.opendev.org/704520
12:01:10 HagunKim gibi: Thanks for your reply. But I found nothing with request_id. I will change log level to debug and see it again.
12:05:18 gibi not even in other nova services like nova api?
12:15:42 bauzas HagunKim: just use the os-instance-actions API
12:16:31 bauzas HagunKim: https://docs.openstack.org/api-ref/compute/#servers-actions-servers-os-instance-actions
12:19:07 HagunKim bauzas: Can I use that api for removed instances?
12:19:22 bauzas "Action information of deleted instances can be returned for requests starting with microversion 2.21."

Earlier   Later