Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-25
10:33:16 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: libvirt: Ignore volume exceptions during post_live_migration https://review.opendev.org/691281
10:33:40 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: libvirt: Ignore volume exceptions during post_live_migration https://review.opendev.org/691282
10:34:07 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: libvirt: Ignore volume exceptions during post_live_migration https://review.opendev.org/691283
10:34:25 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: libvirt: Ignore volume exceptions during post_live_migration https://review.opendev.org/691284
11:22:49 sean-k-mooney aspiers: are you around for a quick question about amd cpus and openstack
11:24:29 sean-k-mooney aspiers: mainly have you tried to use cpu pinning and have you turned on SMT/hyperthreading when useing openstack? if so did it all just work fine? im ignoring the slighly dumb numa topology of eypc gen 1.
11:26:35 sean-k-mooney aspiers: i have no reason to belive that nova will need any modifcation to work with amd eypc cpu for normal vms but im closing a ticket downstream saying i am happy to rely on the testing done by libvirt and qemu in this area.
13:34:16 mriedem gibi: do you think you'll be able to get to these today? https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports-ussuri+status:open
13:35:02 ygk_12345 hi all
13:35:23 ygk_12345 can someone point me to any resource in understanding the code for nova wsgi.py file ?
13:35:35 gibi mriedem: if I don't have to solve the rollback of the parent_ifname ugliness there then yes I can fix your comments to clean up the patches
13:36:05 mriedem yeah i'm not asking for that
13:36:26 gibi mriedem: OK, then I will go and fix those patches up
13:45:27 mriedem ygk_12345: http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010307.html may be helpful
13:49:15 openstackgerrit Merged openstack/nova master: [Trivial] Add missing ws between words https://review.opendev.org/689921
13:57:22 mriedem lyarwood: very weird that your stein backport fails pep8 https://review.opendev.org/#/c/691282/ for an unused variable but it didn't on master or train,
13:57:28 mriedem something must have changed since train with flake8 rules
13:59:09 mriedem my guess would be something due to https://github.com/openstack/nova/commit/3e65f778bdb51e2cf0693f4e9b1b4539ea5c294c#diff-b91f3d5bd63fcd17221b267e851608e8
14:01:50 lyarwood mriedem: what the flying friday
14:01:59 mriedem pycodestyle doesn't check for F841
14:02:02 mriedem https://pycodestyle.readthedocs.io/en/latest/intro.html#error-codes
14:03:51 mriedem stephenfin: ^
14:04:54 sean-k-mooney mriedem: stephenfin is currently in japan watching the rugby world cup
14:05:01 mriedem yeah i know he's not around
14:06:13 bbobrov dansmith: hi, i will be fixing amd sev code
14:10:34 mriedem lyarwood: if you're able it would be good to move forward on these rocky backports today https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:stable/rocky+label:Code-Review=2
14:10:50 mriedem because those are also in queens https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:stable/queens
14:13:56 lyarwood mriedem: yup stuck in calls for a while but I'll take a look once I'm out
14:17:10 dansmith mriedem: thanks for that notification sample patch
14:17:30 dansmith mriedem: so onto the more progress-related notifications, I think we could do one of two things:
14:17:58 dansmith 1. Have the computes all emit a notification when they've downloaded an image, which won't include the aggregate
14:18:25 dansmith 2. Have the conductor emit one notification per compute after it reports what it did
14:18:59 dansmith 3. Have conductor emit a progress notification as it is doing it with numbers that can be turned into percentage (like 30% complete or N/M complete)
14:19:26 dansmith I can see benefits and drawbacks to all of those approaches
14:19:57 dansmith 1-2 don't let you predict completion, 3 doesn't given you much info, like which ones failed
14:20:55 openstackgerrit Eric Fried proposed openstack/os-traits master: Stop testing with py2 https://review.opendev.org/690997
14:22:06 openstackgerrit Eric Fried proposed openstack/os-resource-classes master: Stop testing with py2 https://review.opendev.org/690996
14:24:52 openstackgerrit Eric Fried proposed openstack/os-vif master: Drop python2 support and testing https://review.opendev.org/691364
14:28:09 mriedem dansmith: couldn't 2 and 3 be combined?
14:28:28 openstackgerrit Eric Fried proposed openstack/python-novaclient master: Stop supporting and testing python2 https://review.opendev.org/691365
14:28:36 dansmith mriedem: ah, so per compute, but with progress? sure
14:28:48 mriedem also, i think you can do 3 without 3 using the existing notification,
14:29:02 mriedem so you'd listen for aggregate.cache_images.start which passes the list of hosts being processed already,
14:29:21 mriedem then you listen for per-compute notifications for that aggregate, and since you know how many are in the aggregate from the first notification, you can do your own progress tracking
14:29:42 mriedem you know you're done when you get aggregate.cache_images.end
14:29:51 mriedem so i think i'd just go with 2
14:30:09 dansmith that is assuming you don't have multiple operations going at once and/or that you don't have overlapping aggregates, both of which I think are not reasonable
14:30:11 mriedem 1 isn't great if the compute is down
14:30:14 dansmith not reasonable assumptions I mean
14:30:39 mriedem the initial notification has the aggregate name in it though
14:30:54 mriedem so even if you have hosts that overlap aggregates i don't think that's a problem from a tracking pov
14:31:19 dansmith you have to have aggregate in each notification to link all that up
14:31:20 dansmith either way,
14:31:35 dansmith 2 with a total and complete count makes the most sense to me I think
14:31:50 mriedem having the aggregate in the per-compute notification is fine i think
14:31:53 dansmith I wasn't sure if once per compute was too much, but sounds like you're thinking that way
14:32:06 mriedem you'd have the aggregate, the compute, maybe the image(s) and the status
14:32:16 mriedem we could make it configurable
14:32:22 mriedem like we do for bdms in notifications
14:32:32 mriedem so by default we don't send all that noise, but if you need it it's there
14:32:53 mriedem or we wait until a consumer comes to us with their actual requirement for what they need to get out of thise
14:32:54 mriedem *this
14:33:08 dansmith you really kinda need to know what the status of the images are too if you want this to be coherent
14:33:22 dansmith well, I have one customer requirement so I have some of that
14:33:49 dansmith lemme run with 2+info and we can argue about the contents and/or what should be included by default or by config in gerrit
14:34:18 mriedem fetching the image status....that means doing yet another GET on each image after we've validated them in the API which would make me sad
14:34:28 dansmith no,
14:34:35 dansmith I mean the result of the operation from thecompute
14:34:51 mriedem oh yeah that's fine, i said that'd be in there above
14:35:02 dansmith yeah
14:40:23 dansmith mriedem: https://pastebin.com/cCYBiD3h
14:40:45 dansmith emitted from conductor after each host
14:42:25 openstackgerrit Eric Fried proposed openstack/os-traits master: Stop testing with py2 and switch to ussuri jobs https://review.opendev.org/690997
14:45:32 openstackgerrit Eric Fried proposed openstack/os-traits master: Stop testing with py2 and switch to ussuri jobs https://review.opendev.org/690997
14:46:52 openstackgerrit Eric Fried proposed openstack/os-resource-classes master: Stop testing with py2 https://review.opendev.org/690996
14:47:42 gregwork has anyone seen a situation where nova is not getting the update from cloudbase-init on the admin password on provision? eg. running nova get-password instance mykey.pem returns nothing occasionally
14:48:00 gregwork in the console log of the instance I see cloudbase set the admin password and notify metadata
14:49:09 mriedem dansmith: seems reasonable
14:55:23 mriedem gregwork: asking in #openstack-hyper-v might be more productive
14:55:35 openstackgerrit Eric Fried proposed openstack/os-vif master: Drop python2 support and testing https://review.opendev.org/691364
14:55:42 mriedem or poking through open/merged changes https://review.opendev.org/#/q/project:x/cloudbase-init
14:55:50 gregwork mriedem: i didnt even know that existed, thanks :)
14:59:13 dansmith gibi: you around?
14:59:24 gibi dansmith: yep
14:59:44 gibi dansmith: I saw your convo with Matt about the instance cache notification
14:59:47 dansmith gibi: I dunno if you noticed any of that between mriedem and I, but I'm moving on with more rich notifications for progress
15:00:12 gibi dansmith: I skimmed the convo (busy with fixing up patches) overall seems good to me
15:00:12 gregwork mriedem: hmmn that channel has 3 people in it including me :/
15:00:46 dansmith gibi: cool, so.. I guess I need a new action for the per-host notification, but it strikes me as a good candidate to instead have a new phase, like "progress" so... start..progress...progress...progress...end
15:00:52 dansmith gibi: I assume we don't have that for some reason
15:01:37 gibi dansmith: there is instance.update for example so I have nothing against adding progress as well
15:02:12 dansmith gibi: but that's an action, not a phase yeah?
15:03:06 gibi dansmith: hm. good point. your notification would be like image_cache.start, image_cache.progress ... image_cache.end
15:03:19 dansmith gibi: right, that's what would make the most sense to me
15:03:23 gibi dansmith: I have no problem with this either
15:03:55 mriedem gregwork: lots of the cloudbase people are in eastern europe i think
15:04:00 mriedem lpetrut is maybe your best bet
15:04:18 dansmith gibi: okay I'll add it and you can see what you think in the review
15:04:28 gregwork so this is definitely a clousbase agent problem and not a wierd nova issue i ran into ?
15:04:30 gibi dansmith: sure. I will check

Earlier   Later