Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-25
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/
15:22:44 sean-k-mooney i think this is fine too https://review.openstack.org/#/c/639099/ but a midpoint betwen the too is praobly good too.
15:23:14 kashyap efried: Yeah, I fully agree on "bad commit messages". Reminds me of this excellent guide written by DanPB many moons ago: https://wiki.openstack.org/wiki/GitCommitMessages
15:23:23 kashyap People should take that guide to the heart.
15:23:24 sean-k-mooney the disadvantage of both are you have to click the link/change id to see the context
15:24:02 sean-k-mooney kashyap: there are some thing in the bad examples that i dont fully agree with in that guide but i do reference it frequently
15:24:03 kashyap (And of course this excellent post from a certain Chris Beans: https://chris.beams.io/posts/git-commit/)
15:24:41 kashyap sean-k-mooney: The fundamental rule I follow in commit messages is: provide all the context right there in the commit message.
15:24:45 efried kashyap: I frequently reference the GitCommitMessages wiki page. (That link showed up purple for me :)
15:24:47 kashyap If you have to link to something, summarize it
15:25:20 kashyap (E.g. faciliate the poor suckers working without internet connection and are doing `git log` sleuthing)
15:25:34 kashyap efried: Cool :-)
15:25:53 kashyap sean-k-mooney: That point is actually point 2 in that Wiki page: "Do not assume the reviewer has access to external web services/site."
15:25:56 sean-k-mooney kashyap: one thing that i always tought that wiki discuoraged was bullet point list in the commit which i think are actully good style
15:26:14 sean-k-mooney yep
15:26:37 kashyap sean-k-mooney: Bullet points are fine -- as long as they are complete, and _coherent_ sentences
15:26:44 kashyap And not no-assed "thoughts"

Earlier   Later