Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-30
14:58:29 mdbooth kashyap lyarwood: ^^^
14:58:50 mdbooth johnthetubaguy: I don't recall the details now, but I do recall investigating that thoroughly and being satisfied at the time
14:59:20 johnthetubaguy oops, I meant to ask lyarwood as well
14:59:38 mdbooth johnthetubaguy: I suspect the answer is in the libvirt domain xml docs for that element
14:59:39 kashyap johnthetubaguy: mdbooth: Trying to remember...
15:00:01 sfinucan johnthetubaguy: Would it matter?
15:00:23 johnthetubaguy sfinucan: if its not there, we will just assume every job hasn't ever finished
15:00:24 johnthetubaguy I think
15:00:50 sfinucan johnthetubaguy: aha - I read that incorrectly https://review.openstack.org/#/c/399735/19/nova/virt/libvirt/guest.py
15:01:16 mdbooth johnthetubaguy: Since at least libvirt 0.9.12, possibly longer: http://libvirt.org/formatdomain.html
15:01:22 mdbooth Search for 'mirror'
15:01:53 mdbooth sfinucan: Nah, it's required as a bug fix in fact
15:02:26 mdbooth johnthetubaguy: MIN_LIBVIRT_VERSION = (1, 2, 1)
15:02:33 mdbooth IOW, it's definitely always present
15:03:06 kashyap mdbooth: Yes, it's been there for the duration at least Matt notes above
15:03:12 kashyap Err, johnthetubaguy ^
15:03:28 johnthetubaguy cool, thanks folks
15:03:53 lyarwood johnthetubaguy, sfinucan ; I've not had time to improve the commit msg as yet btw so feel free to hold fire on this and I can make that point a little better there
15:03:53 johnthetubaguy "mirror" seemed odd to me, but the docs clear that up nicely, thanks
15:04:00 dansmith sdague: did you see the activity on this? https://review.openstack.org/#/c/424730/
15:04:54 johnthetubaguy lyarwood: oh boy, I totally didn't see the notes in the commit message somehow, that seems good
15:05:21 lyarwood johnthetubaguy: sfinucan did ask for a little more in his review that I'm happy to add if it's still required
15:05:40 johnthetubaguy lyarwood: there good point, but the fix seems more important
15:05:56 sfinucan lyarwood, johnthetubaguy Yeah, I'm happy to let it in as is
15:06:12 sfinucan (hence +2 - more of a nice-to-have)
15:06:47 kashyap johnthetubaguy: Yeah, the word 'mirror' comes from the QEMU QMP primitive 'drive-mirror' (even _that_ is not really an accurate word, as it synchronizes as it sees fit, but not "mirrors" immediately).
15:13:22 sdague dansmith: I hadn't yet
15:13:32 dansmith sdague: okay everything else is +A behind that
15:13:33 sdague what was the thing that failed when it was in a dedicated section?
15:13:45 dansmith sdague: we start a newton-based placement
15:13:50 dansmith because we do it before nova has upgraded
15:14:01 sdague oh... right
15:14:04 dansmith ...yeah :)
15:15:34 sdague ok, well, that's fine for now then. We can separate later and figure out about earlier installing code
15:15:46 sdague +A
15:16:12 dansmith yeah, thanks
15:17:30 jaypipes hmm, it's always unpleasantly surprising when you run tests expecting them to fail, but they pass...
15:22:04 mriedem blarg
15:25:07 mriedem oh sweet https://review.openstack.org/#/c/424730/
15:25:53 johnthetubaguy mriedem: jaypipes is looking at something for the iroinc patch
15:26:05 mriedem johnthetubaguy: cool
15:26:22 jaypipes johnthetubaguy: yeah, I'm on it.
15:26:33 jaypipes mriedem: trying to get it done before dentist appt at 11am.
15:26:45 mriedem johnthetubaguy: did we want to try and get https://review.openstack.org/#/c/335358/ in before rc1?
15:27:08 mriedem hate to put it off all release and then say it's too risky at the end
15:27:15 mriedem but i'm kind of feeling like it's too risky at this point
15:28:01 johnthetubaguy mriedem: too risky might be right :( I should take another peak at that
15:28:29 mriedem i know a certain someone in hungary will be asking about it
15:28:43 johnthetubaguy mriedem: it will need rebasing on top of bauzas's change, due to service version bump
15:28:50 mriedem yeah
15:29:18 johnthetubaguy mriedem: dang, yeah, its the error handling that scares me in that patch
15:29:37 johnthetubaguy feels like we land it in master as soon as we open, to let it cook for the whole cycle
15:31:18 mriedem johnthetubaguy: i agree
15:31:29 mriedem i'll fall on ildikov's sword
15:33:50 openstackgerrit Balazs Gibizer proposed openstack/nova: reno for notification-transformation-ocata https://review.openstack.org/426810
15:34:11 mriedem i need to go through the tag microversion bug fix thing, starting with the spec https://review.openstack.org/#/c/426030/
15:36:39 jordanP dims, mriedem here's a patch that would make the gate-tempest-dsvm-py35-ubuntu-xenial-nv job more reliable: https://review.openstack.org/#/c/426259 It only a one line change (excluding unit tests)
15:37:02 johnthetubaguy mriedem: yeah, I am curious on sdague' take on that, I could be over thinking it asking for the microversion
15:37:21 mriedem johnthetubaguy: this isn't the all_tenants policy thing
15:37:31 dims jordanP : yep. thanks for that! i had reviewed it earlier but forgot to +1
15:37:34 mriedem johnthetubaguy: this is the bug where we broke device tags after 2.37
15:37:52 johnthetubaguy mriedem: yeah, thats the one
15:37:59 mriedem johnthetubaguy: on the policy thing for all_tenants_visible, i think i'd like to discuss that one at the PTG
15:38:29 johnthetubaguy mriedem: yeah, I think that makes sense
15:39:34 bauzas sdague: mriedem: wooot https://review.openstack.org/#/c/424730/
15:41:30 mriedem pkoniszewski: did you want to see if you could recreate your reported bug and fix with this patch? https://review.openstack.org/#/c/424428/
15:41:34 mriedem it's huge for an rc1 blocker
15:44:47 jordanP mriedem, the patch I linked earlier is not related to "the policy thing for all_tenants_visible". It's just to enforce the same behavior on py27 and py35. Whether this behavior needs to change it another subject
15:45:25 openstack Launchpad bug 1658877 in OpenStack Compute (nova) "live migration failed with XenServer as hypervisor" [High,In progress] - Assigned to huan (huan-xie)
15:45:25 mriedem BobBall: was this a regression in ocata? or a latent bug? https://bugs.launchpad.net/nova/+bug/1658877
15:46:12 mriedem jordanP: i know
15:46:17 jordanP ok :)
15:47:54 mriedem bauzas: in https://etherpad.openstack.org/p/nova-ocata-rc1-todos for placement release notes i think we're covered unless you can think of something besides a prelude section mention
15:48:11 mriedem bauzas: i.e. i think https://review.openstack.org/#/c/417961/41/releasenotes/notes/resource_providers_scheduler_db_filters-16b2ed3da00c51dd.yaml is pretty solid
15:48:21 mriedem we just need prelude
15:48:38 mriedem we might also want some things in the placement devref about the scheduler integration and config required for comptues in ocata?
15:48:43 mriedem cdent: ^
15:49:22 cdent mriedem: you mean placement.rst or placement_dev.rst?
15:49:34 cdent (or both)
15:49:38 bauzas mriedem: yup, I was thinking of a prelude section
15:49:46 mriedem cdent: the former
15:49:49 bauzas mriedem: that's something I can write
15:50:25 mriedem cdent: more like notes for operators, i.e. nova-compute won't start with ocata code unless placement is configured in nova.conf,
15:51:08 mriedem and maybe just a general note that the filter scheduler will not use placement in ocata while there are <ocata computes, but that's going to be a hard fail in pike
15:52:36 mdbooth mriedem: I just sent this to the operators ML: http://lists.openstack.org/pipermail/openstack-operators/2017-January/012540.html
15:52:53 mdbooth Would that require a BP or similar? Or would a link to the ML post be sufficient?
15:54:46 mriedem mdbooth: bp to remove a broken feature?
15:54:52 mriedem mdbooth: i think we can just bug fix it in pike
15:55:06 mdbooth mriedem: That's what I hoped you'd say :)
15:55:07 mriedem mdbooth: i think cfriesen and the windriver people are using lvm
15:55:10 mriedem so might want to ask them about it
15:55:19 mdbooth cfriesen: Sparse lvm?
15:55:21 mdbooth mriedem: Thanks
15:56:03 mriedem cdent: L17 here if you want to sign up https://etherpad.openstack.org/p/nova-ocata-rc1-todos
15:57:01 purplerbot <bauzas> mriedem: that's something I can write [2017-01-30 15:49:49] [n 387]
15:57:01 cdent I thought bauzas said he'd take it: [t 387] ?
15:57:17 mdbooth Incidentally, the issue with it seems to be that it relies on a thinpool being created implicitly, which is created as 64MB on a default setup. This means that as soon as you write more than 64MB of data to your instance you start getting io errors. Which is nice.
15:57:41 mdbooth So a cirros instance works on initial boot, but not if you leave it for a bit.
15:57:44 cdent (happy to do it, just don't want to duplicate the effort)
15:57:45 ildikov johnthetubaguy: mriedem TBH I don't think that patch is that risky

Earlier   Later