Earlier  
Posted Nick Remark
#openstack-nova - 2019-03-18
13:44:06 openstackgerrit Sylvain Bauza proposed openstack/nova master: libvirt: Use 'writeback' QEMU cache mode for Nova instances https://review.openstack.org/641981
13:44:20 bauzas kashyap: ^
13:44:30 bauzas it blocks the CI
13:44:59 efried wow, I'm still not seeing how that attribute gets set from that conf option.
13:45:52 kashyap Also the whole cache modes help text needs an update (as a separate change), based on a lengthy e-mail chain with the QEMU Block Layer folks.
13:46:09 kashyap Err, disregard that duplicate
13:51:58 kashyap efried: See this:
13:51:59 kashyap LOG.warning('Invalid cachemode %(cache_mode)s specified '
13:51:59 kashyap if cache_mode not in self.valid_cachemodes:
13:51:59 kashyap disk_type, sep, cache_mode = mode_str.partition('=')
13:51:59 kashyap for mode_str in CONF.libvirt.disk_cachemodes:
13:52:02 kashyap 'for disk type %(disk_type)s.',
13:52:04 kashyap {'cache_mode': cache_mode, 'disk_type': disk_type})
13:52:07 kashyap continue
13:52:10 kashyap self.disk_cachemodes[disk_type] = cache_mode
13:52:12 efried n-sch meeting in 8 minutes in #openstack-meeting-alt
13:52:50 efried kashyap: Yeah, but I still don't see how that's feeding into the self._disk_cachemode attr
13:57:05 mriedem is it just me or does this seem somewhat risky to be rushing in right before rc1?
13:57:14 mriedem given the complication
13:57:39 openstackgerrit Lance Bragstad proposed openstack/nova master: Remove obsolete policy configuration details from docs https://review.openstack.org/643949
13:59:15 mriedem in other news, i'm +2 on gibi's bw provider nova docs https://review.openstack.org/#/c/642064/
13:59:31 bauzas mriedem: what do you make you feel rushing ?
13:59:52 bauzas kashyap's change ? If so, I just stopped the gate run given your good comments
13:59:57 bauzas and I'm fine with discussing it
14:00:18 mriedem we're a few days from RC1, this is a latent bug, and does not seem trivial
14:00:24 mriedem hence it seems risky to me,
14:00:28 kashyap mriedem: I'm fine delaying it
14:00:31 bauzas fair enough, we can take time
14:00:39 bauzas I didn't wanted to rush
14:00:41 mriedem i.e. i don't know if this is totally fine with NFS deployments (not that i particularly care about NFS)
14:00:59 mriedem i know writeback is recommended for rbd users, so is there a bias here?
14:01:02 kashyap mriedem: On that topic, it is. I ran this past the QEMU Block Layer folks over a lengthy thread
14:01:16 mriedem kashyap: yeah i trust you've done your homework
14:01:19 kashyap See the commit message for on the question of NFS
14:01:20 mriedem given the commit message
14:01:37 mriedem well, which commit message?
14:01:44 kashyap 1 sec
14:01:52 mriedem i guess you mean https://review.openstack.org/#/c/640781/9//COMMIT_MSG
14:01:55 mriedem which i also commented on
14:02:03 mriedem but again, those are different patches
14:02:34 mriedem one is image conversion and one is the disk config for local disks yeah?
14:02:36 kashyap mriedem: Ah, just saw your comment. So, that applies to both the patches
14:02:56 kashyap So I should add remark in the patch that changes it for the Nova instances?
14:03:18 kashyap s/?//
14:03:51 mriedem probably, but it's saying that if the host crashes during writes to NFS, it doesn't matter - but with writethrough each write gets an fsync yeah?
14:03:53 kashyap I checked with Kevin Wolf, he said in _both_ cases: (a) for image conversion; and (b) for Nova instances
14:03:54 mriedem and with writeback they wouldn't
14:03:59 mriedem so you'd lose those writes on NFS right?
14:04:04 kashyap ... 'writeback' is fine even in NFS.
14:04:21 kashyap mriedem: Yes, with 'writethrough', each write gets an fsync().
14:04:21 mriedem does this all assume some minimum version of qemu for that safety behavior?
14:04:28 mriedem b/c as noted, danpb wrote this code
14:05:18 kashyap mriedem: Yes, danpb also incidentally saw and said: "Nova is using the wrong cache mode in both cases, conversion & for guests"
14:05:23 kashyap On minimum version --
14:05:56 bauzas mriedem: apologies if you felt I trampled your -1 by a new PS, it was just for stopping the gate run, i should have added my own -1 with it
14:06:02 kashyap mriedem: We have it since QEMU 1.1 (released in 2012). I noted it in the commit message with references: see lines 67-71
14:07:50 mriedem kashyap: ack yeah ok i glossed over that
14:08:16 mriedem but that is also true in the non-image conversion case?
14:09:03 kashyap mriedem: Yest that's what the QEMU Block Layer folks said. Let me confirm once more.
14:10:09 kashyap mriedem: Okay, yes. even for non-image conversion case, 'writeback' is correct.
14:10:29 mriedem so let me ask another way, in what case would anyone use writethrough?
14:10:38 kashyap Good question
14:11:20 kashyap mriedem: You'd use it if your guest OS really really sucks and doesn't issue fluses where data must be safe on disk.
14:11:25 kashyap But note:
14:12:46 kashyap Such "suck OSes" are things RHEL-4 or even older versions of Windows
14:13:17 kashyap FWIW, the commit message and the text I've written is also reviewed by QEMU folks; I wasn't riffing on it :-)
14:15:53 mriedem i'm not sure there is a way to make this configuration per-guest in nova,
14:15:54 mriedem but ok
14:16:10 mriedem i.e. i'm not aware of an image property to override the configuration
14:16:24 kashyap Me neither
14:24:57 kashyap mriedem: Replied on the commit on your note about DanPB's 2012 commit.
14:27:53 openstackgerrit Lance Bragstad proposed openstack/nova master: Clarify policy short-comings in policy enforcement doc https://review.openstack.org/643960
14:30:12 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add functional test to check the addition of an interface to a linux bridge https://review.openstack.org/643964
14:37:31 mriedem lbragstad: replied in https://review.openstack.org/#/c/643949/1/doc/source/reference/policy-enforcement.rst@117 - that's a good question for which i'm not sure i have a good answer,
14:37:39 mriedem i'm inclined to say we could just remove that section
14:37:46 mriedem but maybe run it by the patrole/ops people first
14:41:35 gmann tssurya: sure, i will check today.
14:41:57 lbragstad mriedem sweet
14:42:20 openstackgerrit OpenStack Release Bot proposed openstack/os-resource-classes stable/stein: Update .gitreview for stable/stein https://review.openstack.org/644028
14:42:22 openstackgerrit OpenStack Release Bot proposed openstack/os-resource-classes stable/stein: Update UPPER_CONSTRAINTS_FILE for stable/stein https://review.openstack.org/644029
14:42:24 openstackgerrit OpenStack Release Bot proposed openstack/os-resource-classes master: Update master for stable/stein https://review.openstack.org/644030
14:42:33 openstackgerrit OpenStack Release Bot proposed openstack/os-traits stable/stein: Update .gitreview for stable/stein https://review.openstack.org/644031
14:42:35 openstackgerrit OpenStack Release Bot proposed openstack/os-traits stable/stein: Update UPPER_CONSTRAINTS_FILE for stable/stein https://review.openstack.org/644032
14:42:37 openstackgerrit OpenStack Release Bot proposed openstack/os-traits master: Update master for stable/stein https://review.openstack.org/644033
14:42:46 openstackgerrit OpenStack Release Bot proposed openstack/os-vif stable/stein: Update .gitreview for stable/stein https://review.openstack.org/644034
14:42:48 openstackgerrit OpenStack Release Bot proposed openstack/os-vif stable/stein: Update UPPER_CONSTRAINTS_FILE for stable/stein https://review.openstack.org/644035
14:42:51 openstackgerrit OpenStack Release Bot proposed openstack/os-vif master: Update master for stable/stein https://review.openstack.org/644036
14:43:38 lbragstad mriedem i'm not sure how much review spam you want - but i was planning on following up each section in 643960 with it's own patch
14:44:28 mriedem context in greater detail."
14:44:28 mriedem has a section dedicated to describing the underlying cause and historical
14:44:28 mriedem yeah i assumed that was coming since it says "Each issue
14:47:25 lbragstad if that's too verbose - i can propose it in one patch, too
14:49:55 mriedem lbragstad: a question and some nits in https://review.openstack.org/#/c/643960/
14:50:57 lbragstad awesome - i'll take a look
14:53:35 kashyap mriedem: So, on cache mode change for Nova guests: (a) The existing Nova help text is broken: it claims "writethrough" as the default, it is not the case; (b) My patch doesn't change the _default_ -- see my last comment here: https://review.openstack.org/#/c/641981/7
15:00:15 kashyap It seems you've added that help text from an IBM help doc (commit: 3d9a76bd71159a3e8ce0acdb27ec76381b1024fc)
15:00:47 mriedem kashyap: yes, i fleshed out the help from libvirt and ibm help docs because before that it was a one-line unhelpful help string
15:01:11 kashyap mriedem: Yeah, I see your intention was good. I'm trying to find the new URL of that IBM doc
15:01:36 kashyap Because QEMU's default has been 'writeback' (for guests) for ages; not sure why the IBM doc claimed it to be 'writethrough'
15:02:05 mdbooth Can anybody tell me which package provides the 'openssl' binary on Ubuntu?

Earlier   Later