Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-16
13:47:04 BobBall I've just fixed the key error (inline) can can push a patch - just running pep8 to make sure I haven't done something stupid
13:47:41 BobBall As we don't have a +2 from John and the CI will need a recheck anyway I'm quite happy to push this and replace the existing change?
13:48:14 BobBall Sorry for not spotting the CI had returned -1: The change is owned by a team member from PRC and I'm not getting CI vote reports
13:48:24 BobBall Happy to go with whatever route you recommend on this one ofc
13:52:17 mriedem BobBall: +2 on it now
13:52:26 mriedem i left comments but those can be dealt with in a follow up
13:52:32 BobBall I'll put the KeyError fix in a follow up.
13:52:33 mriedem johnthetubaguy: are you still happy with https://review.openstack.org/#/c/424428/ ?
13:53:03 mriedem BobBall: i'm good if you want to push that change up now too
13:54:33 BobBall mriedem: Do you want me to change the default driver as well in this follow on change? (i.e. is the follow-on destined for Pike, or do you want to try and approve for Ocata?)
13:54:57 mriedem BobBall: the default vif_driver change won't be backported
13:55:11 mriedem the keyerror thing could be for ocata, so i'd leave those separate
13:55:21 BobBall Will do.
13:56:45 mriedem bauzas: lyarwood: i'm going to request a newton release, it contains an online data migration (not a schema migration) to fix a bug when upgrading from mitaka. i was just going to version this as 14.0.4 but wanted to ask first since last time we had a db migration there was a frackus at red hat about it not being a minor version update
13:56:58 mriedem *fracas
13:57:24 johnthetubaguy mriedem: I duno, I dug into that whole 'nicira-iface-id' a few times, annoyed I didn't see the whole bridge thing, that makes more sense though, make the doubt whether I am happy with it
13:57:52 mriedem johnthetubaguy: sounds like BobBall has a fix locally for the keyerror thing which could go into that patch now if we want
13:57:56 BobBall BTW - we can't continue the loop if the network doesn't have a mapping - this must be fatal; we can return the exception No mapping from source network though
13:57:59 mriedem doesn't matter to me, might as well if it's ready
13:58:14 johnthetubaguy mriedem: yeah, duno, just a .get() would fix it
13:58:26 mriedem johnthetubaguy: that's true, it would result in the exception
13:58:35 BobBall I've added a .get() and then an "if neutron_id is None or neutron_id not in ..." as my fix, and a UT to make sure it raises.
13:58:47 bauzas p!spy
13:58:49 johnthetubaguy yeah
13:59:01 mriedem BobBall: the existing "if neutron_id not in vif_uuid_map.keys():" will handle the None case
13:59:19 johnthetubaguy +1 mriedem
13:59:21 mriedem i think the get() is all we need
13:59:33 lyarwood mriedem: hey sorry, yeah I think that was more because someone missed that the migration had already landed before we GA'd
13:59:42 BobBall Well a dictionary *could* have None in the keys... but I agree that's very unlikely.
13:59:58 BobBall and would be indicative of a totally different bug.
14:00:17 mriedem i don't think it would happen in this case because of https://review.openstack.org/#/c/424428/11/nova/virt/xenapi/vmops.py@2390
14:00:19 BobBall I just like to be more verbose and be sure that we know that None is an error rather than two errors potentially resulting in a weird pass
14:00:50 mriedem i'm fine if you want to be cautious
14:01:16 BobBall So shall I post a follow-up or a replacement?
14:01:46 lyarwood mriedem: https://review.openstack.org/#/c/408725/ right?
14:02:17 mriedem lyarwood: yeah
14:02:25 mriedem BobBall: might as well do a replacement
14:02:32 mriedem new patch set on the existing change
14:02:42 mriedem i'll be around to shephard it into ocata
14:03:34 bauzas mriedem: well, not sure if it would be a .z version
14:04:04 BobBall Will do. Just running another couple of tests to make sure I didn't do something really stupid.
14:04:04 mriedem it's not a new feature
14:04:09 bauzas mriedem: in case we need more than just upgrading the packages
14:04:18 bauzas mriedem: yeah, I know
14:04:30 mriedem bauzas: it's basically there to catch any upgrade issues from mitaka to newton
14:04:33 bauzas mriedem: but I wonder how we could signal that just upgrading is not enough
14:04:36 mriedem not from upgrading from 14.0.3 to 14.0.4
14:04:48 mriedem because if you hit this bug on upgrade to newton you're already broken
14:04:50 lyarwood bauzas: we can document this in our own releasenotes tbh
14:04:57 bauzas mmmm
14:05:07 mriedem bauzas: upgrading is enough, this is the 13.0.0->14.0.4 case
14:05:12 mriedem not 14.0.3->14.0.4
14:05:16 bauzas I see
14:05:19 bauzas well
14:05:19 lyarwood yeah I'm fine with this being in a 14.0.4 release tbh
14:05:27 bauzas mriedem: then okay
14:05:29 openstackgerrit Thomas Bechtold proposed openstack/nova master: Log exception when hypervisor version check fails https://review.openstack.org/434927
14:05:59 bauzas mriedem: if people just do 14.0.3 to .4, they don't need to call the online data migration, yup ? If so, +1 with me
14:06:24 bauzas sorry, I misunderstood the impact then
14:08:26 mriedem that's fine, this was a confusing one
14:13:00 mriedem BobBall: johnthetubaguy: i'm going to be away for awhile, would be good if john can be happy with the change once it's posted, then i'll handle the +W and backport stuff when i'm in the office later
14:13:32 BobBall Thanks mriedem. Should be posted in ~15 minutes I guess (just waiting for stack.sh to complete then I can test)
14:21:25 nicodemus_ hello
14:21:36 openstackgerrit Artom Lifshitz proposed openstack/nova master: Plumbing for tagged nic attachment https://review.openstack.org/415622
14:21:38 openstackgerrit Artom Lifshitz proposed openstack/nova master: Libvirt support for tagged volume attachment https://review.openstack.org/418100
14:21:41 openstackgerrit Artom Lifshitz proposed openstack/nova master: Plumbing for tagged volume attachment https://review.openstack.org/391941
14:21:42 openstackgerrit Artom Lifshitz proposed openstack/nova master: API support for tagged device attachment https://review.openstack.org/376021
14:21:44 openstackgerrit Artom Lifshitz proposed openstack/nova master: Libvirt support for tagged nic attachment https://review.openstack.org/415520
14:21:54 nicodemus_ I have a question regarding https://bugs.launchpad.net/nova/+bug/1646181
14:21:54 openstack Launchpad bug 1646181 in OpenStack Compute (nova) newton "NFS: Fail to boot VM out of large snapshots (30GB+)" [Medium,Fix committed] - Assigned to Kashyap Chamarthy (kashyapc)
14:22:46 nicodemus_ Is it possible/makes sense to increase cpu_time to a higher value than 8, in the case or really large images (80GB+)?
14:27:08 bhagyashris alex_xu: Hi,
14:30:42 bhagyashris alex_xu: I want to discuss regarding the backup api. have free time?
14:36:22 kashyap nicodemus_: If you have a test env. mind trying it and see?
14:36:45 kashyap nicodemus_: The current default isn't working for you?
14:38:16 nicodemus_ kashyap, it's not a test env, it's productive... but could give it a try
14:39:17 nicodemus_ I've applied the fix when the customer reported the issue, but the issue seems to still be present with very large images
14:39:48 nicodemus_ (it's a Mitaka deployment)
14:41:43 kashyap nicodemus_: Yeah, in that case, I'm curious what you'll see if you increase the timeout.
14:44:54 nicodemus_ kashyap, I'll give it a try and see what happens. Though it's failing on volume-backed instances, so maybe this is not the root cause.
14:45:13 kashyap nicodemus_: Can you please make a comment with full details in the bug, once you complete your test?
14:45:28 nicodemus_ kashyap, sure
14:59:28 openstackgerrit Bob Ball proposed openstack/nova master: Fix live migrate with XenServer https://review.openstack.org/424428
14:59:50 BobBall Sorry that took so long johnthetubaguy ^^ my live migrate env got broke by upgrading devstack and the slave not being a placement-client... :)
14:59:58 mriedem johnthetubaguy: BobBall: wild thought, but we could take this opportunity to deprecate the xen vif_driver option in ocata
15:00:20 mriedem BobBall: johnthetubaguy: my thinking is, deprecate in ocata, remove in pike, and pick the vif_driver based on the use_neutron boolean
15:00:40 mriedem we should probably at least change the default to the xen ovs vif driver in ocata because we changed the default value of use_neutron=True in ocata
15:00:49 mriedem so the xen vif driver config default is broken (by default)
15:01:18 johnthetubaguy I would have through bridge and ovs work with both, I guess thats not true?
15:01:26 johnthetubaguy thought
15:02:25 mriedem like neutron + linuxbridge?
15:02:42 mriedem i'm told the xen vif bridge driver is deprecated and only for nova-net
15:04:42 mdbooth_ lyarwood: I'm also just looking at that DiskFilter change, btw. The if requested > 0 seems kinda arbitrary, as presumably the real problem is that the total is wrong?
15:06:05 mdbooth lyarwood: So IIUC you'd be able to create a BFV instance, but not an instance with ephemeral root disk smaller than the actual available space.
15:06:18 owalsh mriedem: FYI https://bugs.launchpad.net/nova/+bug/1665370 - the newton & ocata api db migrations conflict
15:06:18 openstack Launchpad bug 1665370 in tripleo "api db_sync fails on upgrade due to duplicate migration files" [Critical,Triaged] - Assigned to Steven Hardy (shardy)
15:06:23 mdbooth In either case you should be able to create, but the latter case would still be prevented.
15:06:39 mdbooth lyarwood: Unless I missed something, which is possible. Still looking.
15:07:24 mriedem owalsh: guh, pretty soon i'm in meetings for the next 2 hours
15:07:30 mriedem dansmith: melwitt: can you take a look at ^?

Earlier   Later