Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-25
13:40:41 alex_xu artom: hah
13:40:43 artom alex_xu, thanks for taking a thorough look at that series, by the way :)
13:40:55 sean-k-mooney alex_xu: that said since it can be set per node it proably should be sent back
13:40:55 alex_xu np :)
13:41:31 alex_xu sean-k-mooney: ok, thanks
13:41:33 openstackgerrit Merged openstack/os-vif master: remove use of brctl from vif_plug_linux_bridge https://review.openstack.org/636822
13:41:45 artom sean-k-mooney, noted, thanks
13:42:44 sean-k-mooney if there was a good usecase for different values we should be schduling on it and we cant today except via host aggregates
13:44:15 sean-k-mooney we could expose it via a custom trait at some point but i think this is too virtdirer specific to warrent it.
13:45:33 sean-k-mooney technically different prioties of realtime tasks is a thing but i dont think it should be a thing in cloud. im much more comfortable with a boolean form that point of view. e.g. it supprot realtime instance or it doesnt
13:45:33 openstackgerrit Merged openstack/os-resource-classes master: Add normalize_name utility https://review.openstack.org/634258
13:47:14 zhubx007 mdbooth: Got your review. Is there any suggestion to fix the bug? If do not convert the qcow2 to raw here, the instance failed to boot. Thanks.
13:47:32 mdbooth zhubx007: I just added another comment on the review about that.
13:48:15 mdbooth I don't think you need to fix it, because if you leave force_raw_images with its default value of True then the image should be (safely) converted for you anyway.
13:48:31 alex_xu sean-k-mooney: that priorities is also indicated the host whether support realtime? so you mean at least there is way to find out a host support realtime
13:49:24 alex_xu ah, I see now, we won't fix realtime and normal workload on the same host, right? sean-k-mooney
13:49:30 alex_xu s/fix/mix
13:51:07 mdbooth zhubx007: Are you setting force_raw_images to false?
13:51:43 sean-k-mooney alex_xu: well right now you have to use host aggrates to split them
13:51:53 mdbooth If force_raw_images is True and you're hitting this, I think we should go back and open a bug about this to try to work out why before attempting a fix.
13:51:57 sean-k-mooney alex_xu: mainly because we dont know which host have a realtime kernel
13:52:22 alex_xu sean-k-mooney: I see now
13:53:46 zhubx007 mdbooth: :) wait for a minute. I check nova.conf file now.
13:53:50 sean-k-mooney if https://github.com/openstack/nova/blob/master/nova/conf/libvirt.py#L759-L763 did not have a default we could use the presence or absence of that config value to know if we should add a realtime trait to the compute node
13:54:01 sean-k-mooney but since it default to 1 we cant
13:54:32 sean-k-mooney we might want to change that in the future but not in stien
13:55:30 sean-k-mooney alex_xu: ^ likely we would have to add another config to not break backwards compatiblity but the detail should praobly be discussed in a short spec.
13:56:09 zhubx007 mdbooth: yes, force_raw_images is False
13:56:38 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226
13:57:13 yonglihe call for review, thanks, it's small one: https://review.openstack.org/#/c/621474/22
13:57:47 mdbooth zhubx007: Cool, that's your problem.
13:58:09 mdbooth zhubx007: As I say it does feel wrong that the we're making it the operator's responsibility to get that right.
13:58:17 alex_xu sean-k-mooney: agree, and we can transulate hw:.... to a required trait in placement request
13:58:40 mdbooth zhubx007: But that would be a much lower priority issue :) Patches welcome.
13:59:20 sean-k-mooney yep we could. ill write something up for train and add you to the reviews list.
13:59:36 alex_xu cool
13:59:37 cdent scheduler placement meeting in #openstack-meeting-alt now ish
14:01:12 openstackgerrit Ghanshyam Mann proposed openstack/nova master: DNM: Testing nova legacy jobs on bionic https://review.openstack.org/639017
14:01:41 zhubx007 mdbooth: yeah, you are right. but when setting force_raw_images to False, I think it is still an issue.
14:09:48 openstackgerrit Jan Gutter proposed openstack/os-vif master: Fix nits in brctl removal (vif_plug_linux_bridge) https://review.openstack.org/639099
14:10:16 mdbooth zhubx007: Right. That setting is incompatible with rbd imagebackend. It would be nice to, for eg, give an error at startup pointing it out. Or perhaps just switching it off automatically and logging a warning.
14:11:01 mdbooth zhubx007: In fact it's only useful for flat and qcow2 imagebackends. LVM would also have a problem with it.
14:12:57 stephenfin jangutter: Some small comments in that patch ^
14:15:56 openstackgerrit Jan Gutter proposed openstack/os-vif master: Fix nits in brctl removal (vif_plug_linux_bridge) https://review.openstack.org/639099
14:16:13 jangutter stephenfin: ask and ye shall receive.
14:16:20 sean-k-mooney jangutter: damb looks like i missed leaving the comment by a few seconds
14:16:54 sean-k-mooney jangutter: can ou add the comment too? thanks for doing this by the way
14:17:23 jangutter sean-k-mooney: hahaha, no worries. I don't have my Nagle algorithm turned on today.
14:17:34 stephenfin jangutter: is that correct?
14:17:48 stephenfin x, = (1, 2) gives a ValueError
14:17:59 stephenfin You'd need 'x, _'
14:18:20 jangutter stephenfin: frack, you're right.
14:18:44 jangutter stephenfin: just goes to show that code path is untested so badly.
14:18:51 stephenfin Oh, found an ancient change of mine. does this docs patch make sense to you, jaypipes? https://review.openstack.org/#/c/445436/
14:19:32 sean-k-mooney oh thats to nova i was like i dont remember that
14:23:14 openstackgerrit Jan Gutter proposed openstack/os-vif master: Fix nits in brctl removal (vif_plug_linux_bridge) https://review.openstack.org/639099
14:23:51 jangutter stephenfin, sean-k-mooney: 3rd time lucky Monday?
14:27:03 jangutter I think that code is dead since before I touched OpenStack, but I'm worried that breaking it will cause CERN to accidentally create a black hole or something.
14:30:23 openstackgerrit Ghanshyam Mann proposed openstack/nova stable/rocky: DNM: Testing nova legacy jobs on rocky still use xenial https://review.openstack.org/639107
14:31:57 sean-k-mooney jangutter: the linux bridge pluging is partcalarly archane as we spend much less time maintaining it. im hoping that by sharing code with the ovs plugin in train we can impove the quality of both
14:32:38 sean-k-mooney jangutter: i would also like to add an sriov plugin intree in train so we can finally remove the last of the vif.py legacy code from nova
14:32:55 jangutter sean-k-mooney: ++ on both of those.
14:33:43 sean-k-mooney we have avoided sharing code so people can copy a sub directly and use that as a base for a new plugin but instead i would like to create a cookiecutter template for that and document it
14:34:22 sean-k-mooney *sub directory
14:38:11 zhubx007 mdbooth: as you say, it is ok when I set force_raw_images to True. Whether it is great to add checking the image format when call import_image under rbd imagebackend because only raw is good for this backend.
14:39:23 openstackgerrit Yongli He proposed openstack/nova master: Add server sub-resource topology API https://review.openstack.org/621476
14:40:05 openstackgerrit sean mooney proposed openstack/os-vif master: make functional tests run on python 3 https://review.openstack.org/638053
14:40:06 openstackgerrit sean mooney proposed openstack/os-vif master: modify functional base.py to allow using vscode https://review.openstack.org/638058
15:04:20 mriedem jaypipes: efried: i'm +2 on the current bottom 4 bw provider series changes https://review.openstack.org/#/c/616240/ - nits to be sure but can be addressed in another follow up i think
15:04:41 mriedem i think the api change is the goal for stein https://review.openstack.org/#/c/636360/ so i'm trying to do a review push to get there this week
15:10:11 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Rework 'EBUSY' (SIGKILL) error handling code path https://review.openstack.org/639091
15:10:53 kashyap mriedem: Blast from the past ^
15:11:13 efried mriedem: ack. Trying to figure out if it's mathematically possible to have more fups than patches.
15:11:29 mriedem efried: i made a similar joke on one of these
15:11:32 mriedem 1:1 fups
15:11:52 efried I hate being unoriginal. Now I will have to kill you.
15:12:09 efried Never mind, I'll need you to review my code. You live.
15:16:15 gibi efried, mriedem: I working on a fup that will contain fixes up til https://review.openstack.org/#/c/573317
15:16:26 kashyap What is a "fup"?
15:16:33 gibi kashyap: Follow up
15:16:39 kashyap $> wtf is fup
15:16:39 kashyap My tool doesn't know it:
15:16:40 kashyap wtf: I don't know what `fup' means!
15:16:45 kashyap gibi: Ah, thanks.
15:16:50 efried or what you were thinking, depending.
15:16:54 sean-k-mooney fix up patch or follow up patch
15:17:02 sean-k-mooney kashyap: ^
15:17:21 kashyap Please, "follow-up" as keyword.
15:17:37 sean-k-mooney no one uses that^
15:17:39 kashyap As I accidentally looked at the definition of "fup" on Urban Dictionary ... and "you won't believe what happens next!"
15:17:49 kashyap sean-k-mooney: Yeah, yeah. I know it's just IRC slang
15:18:45 efried and led to all kinds of raunchy (well, for IBM, anyway) jokes.
15:18:45 efried Back in the day it was used by IBM support teams for APARs, in caps (FUP), simply shorthand for "follow up", as in "FUP with customer..."
15:18:51 sean-k-mooney yep and recent slang at that. but i dont think we need to add follow-up: someithg to the commits
15:19:17 kashyap I see
15:19:39 efried Agree with that; though I have to say I'm not a fan of commit titles like "Follow on for <change-id>" with nothing in the body of the message.
15:20:10 efried When I do these, I tend to do "FUP for <brief description>" and then enumerate links to specific comments I'm responding to in the body.
15:20:16 efried and of course, everybody should do it my way.
15:20:57 sean-k-mooney haha well that at least makes sense
15:21:23 efried example: https://review.openstack.org/#/c/600474/

Earlier   Later