| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-02 | |||
| 02:56:21 | mriedem | including filtering on DISK_GB | |
| 02:56:40 | mriedem | https://review.openstack.org/#/c/417961/41/nova/scheduler/filter_scheduler.py@139 | |
| 02:57:52 | melwitt | okay, cool | |
| 02:58:19 | melwitt | well, that's a win, glad to see that | |
| 02:58:52 | mriedem | https://review.openstack.org/#/c/427367/ adds some upgrade notes to the placement devref | |
| 02:58:55 | mriedem | might help you catch up a bit | |
| 02:59:17 | melwitt | thanks | |
| 02:59:22 | mriedem | i missed pretty much all of the moving instance create to conductor, but after the last 24 hours of bugs i feel like i've caught up :) | |
| 03:00:10 | melwitt | I wonder how it makes sure volume backed instance doesn't request the flavor's amount of disk when rebuilding etc | |
| 03:00:33 | melwitt | haha, yeah really | |
| 03:11:05 | mriedem | got some other cells v2 related docs changes here, small ones https://review.openstack.org/#/q/topic:man+project:openstack/nova+status:open | |
| 03:54:26 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix typo in help for discover_hosts_in_cells_interval https://review.openstack.org/427997 | |
| 04:21:23 | mriedem | gibi: https://review.openstack.org/#/c/427647/ apparently the cinder people have figured out how to short circuit sending notifications if they aren't enabled | |
| 04:22:01 | mriedem | https://review.openstack.org/#/c/426547 | |
| 05:03:30 | archies | @team, I am facing an interesting issue while attaching a volume. In libvirt the error is "operation failed: open disk image file failed" | |
| 05:03:33 | archies | Any idea? | |
| 05:42:57 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add release note for filter/sort whitelist https://review.openstack.org/427978 | |
| 05:53:07 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add release note for filter/sort whitelist https://review.openstack.org/427978 | |
| 06:01:20 | trinaths | Hi- While enabling VM with huge pages, I get the following error. Insufficient compute resources: Requested instance NUMA topology cannot fit the given host NUMA topology. I’m using devstack (stable/newton) and nova (6.0.0). I have configured hugepages and flavors following the guide at http://docs.openstack.org/admin-guide/compute-huge-pages.html . Here is the configuration of the host. http://paste.openstack.org/sh | |
| 06:11:05 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add release note for filter/sort whitelist https://review.openstack.org/427978 | |
| 07:16:58 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add release note for filter/sort whitelist https://review.openstack.org/427978 | |
| 07:30:55 | markus_z | mikal: Would you maybe take a look at this newton backport? https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton+topic:%22bug+1455252%22 | |
| 07:31:25 | markus_z | mikal: ^ lyarwood already checked it. | |
| 07:43:48 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Enable cold migration with target host(1/2) https://review.openstack.org/408955 | |
| 08:35:29 | gibi | Q~. | |
| 08:35:43 | gibi | sorry ^^ | |
| 08:35:54 | gibi | mriedem: thanks for the link, I will check the cinder solution | |
| 08:49:33 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Enable cold migration with target host(2/2) https://review.openstack.org/408964 | |
| 08:59:39 | gema | can someone point me in the right direction regarding how to update this page: http://docs.openstack.org/developer/nova/feature_classification.html | |
| 08:59:54 | gema | are there any requirements in terms of testing that need to be met or is this manually maintained? | |
| 09:05:02 | BobBall | johnthetubaguy: OK - so the XenServer CI problem is that https://review.openstack.org/#/c/396269/ merged breaking support for the Ubuntu we're using. | |
| 09:15:07 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Remove redundant bdm serial mangling and saving during swap_volume https://review.openstack.org/427364 | |
| 09:16:48 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add functional tests for cold migration to same host https://review.openstack.org/414926 | |
| 09:16:52 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add functional tests for cold migration to same host https://review.openstack.org/414926 | |
| 09:19:48 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Add parameters in cold migrate action https://review.openstack.org/410042 | |
| 09:19:54 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Add parameters in cold migrate action https://review.openstack.org/410042 | |
| 09:21:56 | johnthetubaguy | BobBall: really :S | |
| 09:22:06 | BobBall | Indeed. | |
| 09:23:00 | johnthetubaguy | BobBall: how did that break the uploads from inside the XenAPI plugin? | |
| 09:23:22 | BobBall | It broke Cinder which meant that the glance upload couldn't create the volume it was going to upload to | |
| 09:23:49 | johnthetubaguy | but I didn't think the xenapi plugin is used for any cinder volumes? | |
| 09:24:19 | johnthetubaguy | oh, it breaks all glance uploads in the destination sense? | |
| 09:24:38 | BobBall | uhhhh ok now you've got me confused... | |
| 09:29:48 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Add parameters in cold migrate action https://review.openstack.org/410042 | |
| 10:04:39 | mdbooth | lyarwood: Thinking about https://review.openstack.org/#/c/427364/ | |
| 10:05:36 | mdbooth | Specifically about the chunk in libvirt driver which you delete that we discussed yesterday | |
| 10:05:59 | mdbooth | I think the fundamental issue there is that libvirt volume drivers mutate connection_info | |
| 10:06:50 | mdbooth | The example which is specifically called out is LibvirtISCSIVolumeDriver. This adds the local device path that created to connect to the remote iscsi volume to connection_info. | |
| 10:07:21 | lyarwood | mdbooth: that's still added after my change | |
| 10:07:27 | mdbooth | But this isn't strictly related to the volume connection. | |
| 10:07:37 | lyarwood | mdbooth: we pass the modified connection_info back to the compute layer and update the BDM with it | |
| 10:07:41 | mdbooth | lyarwood: Yeah, I'm being expansive here :) | |
| 10:07:44 | lyarwood | ah | |
| 10:07:46 | lyarwood | :D | |
| 10:08:23 | mdbooth | So, anyway, I think the bug here is in LibvirtISCSIVolumeDriver and all other places which mutate connection_info | |
| 10:08:23 | openstackgerrit | Tomi Juvonen proposed openstack/nova-specs master: Add Host Details https://review.openstack.org/428070 | |
| 10:08:30 | mdbooth | They need to stash that metadata somewhere else. | |
| 10:08:52 | mdbooth | I also disapprove of even looking inside connection_info, tbh | |
| 10:09:05 | lyarwood | mdbooth: yeah that's all going to change with cinder v3 anyway | |
| 10:09:15 | mdbooth | If we could have cinder pass it to us as an opaque packed C struct, that would be awesome | |
| 10:09:28 | mdbooth | The only thing you can do with this data is give it back to cinder | |
| 10:09:29 | lyarwood | mdbooth: but I can't see how that relates to this issue tbh | |
| 10:09:59 | mdbooth | It relates because it means we *can't* refetch connection info from cinder after cinder also mutates it | |
| 10:10:29 | mdbooth | Because Nova futzes with it, we're now stuck trying to second guess one or the other. | |
| 10:11:05 | lyarwood | mdbooth: ah right you're talking about the cinder retype situation | |
| 10:11:20 | mdbooth | cinder volume migration | |
| 10:11:31 | lyarwood | mdbooth: yeah same thing | |
| 10:11:49 | mdbooth | volume migration is meaningful to me :) | |
| 10:12:03 | lyarwood | mdbooth: I need to drop now, can we pick this up when I get back? | |
| 10:12:08 | mdbooth | lyarwood: Sure thing. | |
| 10:12:23 | lyarwood | mdbooth: cool | |
| 10:13:21 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Fix access_ip_v4/6 filters params for servers filter https://review.openstack.org/428071 | |
| 10:13:57 | gmann | johnthetubaguy: mriedem alex_xu seems like we missed another bit in filter/sort thing - https://bugs.launchpad.net/nova/+bug/1661195 | |
| 10:13:57 | openstack | Launchpad bug 1661195 in OpenStack Compute (nova) "Servers filter by access_ip_v4 does not filter servers" [Undecided,In progress] - Assigned to Ghanshyam Mann (ghanshyammann) | |
| 10:14:18 | gmann | johnthetubaguy: alex_xu mriedem this is fix - https://review.openstack.org/428071 | |
| 10:14:45 | johnthetubaguy | gmann: oh, you mean we should allow them, because we used to allow them | |
| 10:15:02 | gmann | but different filed name in filter and sort than what API represent is odd to me | |
| 10:15:16 | gmann | johnthetubaguy: i think so, or no ? | |
| 10:15:32 | johnthetubaguy | gmann: don't they now match what the API has? | |
| 10:15:34 | gmann | i may be missed the discussion on that if any | |
| 10:16:15 | gmann | johnthetubaguy: oh so you mean new list will match the what API has either it used to work before or not | |
| 10:17:08 | johnthetubaguy | gmann: the whole plan is the filter name matches what the API names are now, rather than matching the DB | |
| 10:17:29 | gmann | johnthetubaguy: yea | |
| 10:18:08 | gmann | johnthetubaguy: ok, i think m going in opposite way :) | |
| 10:18:15 | gmann | johnthetubaguy: i agree on that point | |
| 10:18:49 | gmann | johnthetubaguy: but bug seems now accessIPv4 work on filter or not as DB fileds are different for those? | |
| 10:19:26 | gmann | johnthetubaguy: and sort has 'access_ip_v4' not accessIPv4 so it is issue on sort list then | |
| 10:19:46 | johnthetubaguy | gmann: so we must have accessipv4 and accessipv6 as thats what in the API, in both filter and sort | |
| 10:20:31 | gmann | johnthetubaguy: yea and those should work as filter. because i doubt currently those works as we did not add translation layer for those | |
| 10:20:32 | johnthetubaguy | gmann: but... for backwards compatibility, we should probably also allow access_ip_v4 and access_ip_v6, and mark them for removal in a future microversion | |
| 10:20:39 | mdbooth | Can anybody confirm that schema migrations are intended to be idempotent? Specifically that I should be able to run db_sync multiple times? | |
| 10:20:44 | johnthetubaguy | gmann: yeah, we should add a test for both | |
| 10:20:47 | johnthetubaguy | mdbooth: thats correct | |
| 10:21:00 | gmann | johnthetubaguy: yea, that was actually i was thinking initially | |
| 10:21:07 | gmann | johnthetubaguy: cool, | |
| 10:21:32 | gmann | johnthetubaguy: ll update | |
| 10:21:36 | johnthetubaguy | gmann: cool | |
| 10:22:07 | johnthetubaguy | gmann: we should give that the tag, and get it on mriedem's etherpad I think | |
| 10:22:25 | johnthetubaguy | RC potential thing | |
| 10:22:36 | mdbooth | johnthetubaguy: Thought so, thanks. I'm seeing an error in 216_havana creating the instances table, specifically line 1046 where it calls instances.create() raises an error containing: (1050, u"Table 'instances' already exists") | |