Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-30
13:45:05 johnthetubaguy edleafe: I think what you have should work, although not 100% sure it gets us enough to push it into ocata
13:45:23 edleafe johnthetubaguy: me neither
13:45:47 johnthetubaguy edleafe: if we claimed the new resources we are reporting, then I think that would be good to have
13:45:52 edleafe johnthetubaguy: was really hoping to discuss with jaypipes before we move forward
13:46:29 edleafe johnthetubaguy: I'm not sure that we claim all of them - just the VCPU-rleated ones
13:46:33 johnthetubaguy edleafe : yup, makes sense
13:46:55 jaypipes edleafe: heyo
13:47:06 edleafe hi yerself
13:55:45 edleafe Nova Scheduler subteam meeting in 5 minutes in #openstack-meeting-alt
13:57:23 openstackgerrit Jordan Pittier proposed openstack/nova: Fix unspecified bahavior on GET /servers/detail?tenant_id=X as admin https://review.openstack.org/426259
13:58:29 openstackgerrit Maciej Szankin proposed openstack/nova: config options: remove libvirt imagecache https://review.openstack.org/378497
13:58:37 johnthetubaguy edleafe: oh, I should clarify, we don't claim the new custom one right now, which seems problematic to me.
13:59:27 edleafe johnthetubaguy: agreed
14:55:14 openstackgerrit Maciej Szankin proposed openstack/nova: conf: resolved TODOs in compute configuration https://review.openstack.org/426793
14:58:06 johnthetubaguy sfinucan: mdbooth: is there always a disk.mirror attribute? re https://review.openstack.org/#/c/399735
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

Earlier   Later