| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-16 | |||
| 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 | mriedem | it's not a new feature | |
| 14:04:04 | BobBall | Will do. Just running another couple of tests to make sure I didn't do something really stupid. | |
| 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 | lyarwood | yeah I'm fine with this being in a 14.0.4 release tbh | |
| 14:05:19 | bauzas | well | |
| 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 | 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:21:54 | nicodemus_ | I have a question regarding https://bugs.launchpad.net/nova/+bug/1646181 | |
| 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 | 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:18 | owalsh | mriedem: FYI https://bugs.launchpad.net/nova/+bug/1665370 - the newton & ocata api db migrations conflict | |
| 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 | 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: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: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 | |