Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-30
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 mriedem BobBall: was this a regression in ocata? or a latent bug? https://bugs.launchpad.net/nova/+bug/1658877
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: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 cdent I thought bauzas said he'd take it: [t 387] ?
15:57:01 purplerbot <bauzas> mriedem: that's something I can write [2017-01-30 15:49:49] [n 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
15:59:39 mriedem cdent: i thought bauzas was going to do the release note prelude section
15:59:41 mriedem but either way
16:00:29 cdent mriedem: if it's not clear when I finish what I'm doing right now, I'll take a stab
16:01:26 mdbooth mriedem: Is this an rc1 potential bug as in your etherpad: https://review.openstack.org/#/c/383859/13
16:01:27 bauzas mriedem: cdent: I can do both, I don't care that much
16:01:40 bauzas mriedem: cdent: I was mentioning the prelude section but anyway
16:01:53 mriedem mdbooth: it's not a regression right?
16:02:06 mdbooth mriedem: Nope, but it's a bug.
16:02:14 mriedem mdbooth: sure, but we have lots of bugs
16:02:23 mdbooth mriedem: Right, but this one has a well-tested fix.
16:02:23 mriedem mdbooth: having said all of that, i was planning on trying to get that one in yet
16:02:29 mdbooth Thanks
16:07:56 ildikov johnthetubaguy: mriedem: so just to ensure we're on the same page, the plan now is to get that remove check_attach patch landed, when master opens for Pike?
16:08:21 mriedem ildikov: that's what i would prefer
16:08:27 mriedem since we're 4 days from rc1
16:09:01 ildikov I guess as the new Cinder API changes will be tied to a version etc. we don't necessarily have to land it a cycle earlier
16:09:17 ildikov as it makes those changes easier to do and follow
16:10:12 ildikov mriedem: so I can annoy you to hell with this, when master opens then?
16:10:27 ildikov mriedem: as it's been two cycles now... :/
16:10:41 ildikov mriedem: and it's really just a bugfix on its own
16:11:26 mriedem yeah, but to be fair, it's also super latent behavior
16:12:37 ildikov mriedem: I see this as one more reason to remove :)
16:13:04 artom mriedem, so I wrote the spec for the device role tagging bug: https://review.openstack.org/#/c/426030/
16:13:40 artom I poked johnthetubaguy to review it, dunno how much bandwidth he has to spare - it'd be awesome if we can fix this for ocata to avoid a cycle without device tagging (yeah, the client the can version pinned, I know)

Earlier   Later