Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-02-16
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 ^?
15:07:47 mdbooth The code which populates this from the driver gets it directly from the storage, so my current working assumption is an incorrect interim calculation in resourcemanager
15:08:04 owalsh mriedem: should be a simple fix, I can push a patch
15:08:18 mriedem owalsh: i'm not sure we can just start renaming db migrations
15:08:59 dansmith owalsh: yeah, hang on a sec
15:09:02 dansmith not sure how this could have happened
15:09:16 mriedem right, how would grenade not explode?
15:09:42 mriedem owalsh: it's 21 in stable/newton https://github.com/openstack/nova/tree/stable/newton/nova/db/sqlalchemy/api_migrations/migrate_repo/versions
15:10:02 mriedem and 28 in ocata https://github.com/openstack/nova/tree/stable/ocata/nova/db/sqlalchemy/api_migrations/migrate_repo/versions
15:10:13 dansmith mriedem: because grenade uses old/ and new/
15:10:24 dansmith mriedem: it's because you didn't put it in the placeholder in master too and then backport *that*
15:11:20 dansmith I should have caught that
15:11:48 mriedem oh i see
15:11:52 mriedem 21 in master is the issue
15:11:55 dansmith owalsh: so you were going to copy the migration the same place in ocata and remove that placeholder right?
15:12:41 mriedem ok bug is marked for ocata rc2
15:12:51 mriedem i'm entering the roundtable danger zone, bbiab
15:13:23 owalsh dansmith: yea, assuming it's not too late to rename ocata migrations
15:13:47 mriedem we can rename it and backport it
15:13:52 dansmith owalsh: so, tbh, I'm not sure we've ever actually done this
15:14:02 dansmith mriedem: that won't really fix people in the field, actually
15:14:36 dansmith mriedem: if they have ocata now, and then update to this, they'll get two migrations for #21
15:14:48 owalsh other option is to remove the 021 placeholder in ocata and turn 028 into a no-op
15:14:50 dansmith I guess if they use a proper package manager then it should remove the old one and install the new one
15:15:00 dansmith owalsh: I don't think that helps
15:15:23 dansmith owalsh: and we definitely don't want to do that in case someone was at #27 right now
15:15:42 lyarwood mdbooth: sorry just reading up, so iirc negative totals are valid right? BFV instances using flavors with local disk space etc? That's why I asked that the author add the examples where we can hit this into the commit message.
15:15:56 dansmith owalsh: so I think you have to do the rename in ocata, add a release note about it, and we will have to depend on packaging to properly clean up the two #21s
15:16:22 lyarwood mdbooth: ah but that's going to be > 0, I see your point
15:17:14 mdbooth lyarwood: That's only a working assumption, btw. Plenty of scope to be entirely wrong :)
15:20:26 cfriesen what's the process for documenting a known issue in stable/newton? (It'll be affected by bug 1644248 but we're not fixing it.)
15:20:26 openstack bug 1644248 in OpenStack Compute (nova) ocata "Nova incorrectly tracks live migration progress" [High,In progress] https://launchpad.net/bugs/1644248 - Assigned to Matt Riedemann (mriedem)
15:22:41 owalsh dansmith: hmm, anyone on #27 will need #28 so it needs to remain, but it also has to tolerate the case where the migration was already performed in newton #21
15:22:52 dansmith owalsh: right, it has to be in both places
15:23:05 dansmith owalsh: but it should be idempotent so that's fine right? otherwise a backport of it doesn't work at all
15:23:52 owalsh dansmith: ok, then the only Q is where packaging does the right thing here. I'll take a look
15:24:01 owalsh s/where/whether/
15:24:42 dansmith owalsh: yeah, so I'm pretty sure we've done this at least once in the far past, but I'm not positive.. so if that did happen, packaging must have done the right thing as I don't remember ever having to consider this rename issue before
15:28:36 mriedem dansmith: can't we just have the same migration in ocata at 21 and 28?
15:28:43 mriedem it's idempotent
15:28:45 dansmith mriedem: yes
15:28:57 mriedem ok
15:29:18 dansmith mriedem: but anyone with ocata installed would get two different #21s if the packaging didn't remove the 21_placeholder and replace with with 21_do_stuff
15:29:19 dansmith that's he concern

Earlier   Later