| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-20 | |||
| 13:34:19 | d4rks1d3 | Does anyone know the reason why the nova.sqlite is in the nova folder in the compute node? Does anyone know if it is possible to use it with the data coming in through the nova-compute service? | |
| 13:34:22 | d4rks1d3 | Thnaks | |
| 13:36:53 | noonedeadpunk | hi everyone | |
| 13:37:48 | TheJulia | melwitt: fun! :( Thanks for looking at it on Friday evening. I think a few different people are now working on it | |
| 13:41:03 | cdent | d4rks1d3: sounds like you may have an unconfigured [database]/connection string | |
| 13:41:11 | noonedeadpunk | does anybody experienced problems with live migration on libvirt? As I'm having not more than 8mbit for live migration on 17.0.5 on one installation. Probably I've missed something... These all configs related to live migration http://paste.openstack.org/show/728424/ | |
| 13:41:49 | d4rks1d3 | cdent: my openstack is working fine, however i do not know if it possible to fill this database | |
| 13:41:52 | d4rks1d3 | this is my question | |
| 13:43:14 | cdent | you don't want that database. you should use the sqlite command line tool to see if there is anything in it, and if so how recent it was added. if it was recent, something is configured in correctly and you're gather data in the wrong place. If not, it may be that it is an artifact from the install process and you can ignore it | |
| 13:43:55 | d4rks1d3 | cdent: the database is completly empty | |
| 13:44:19 | d4rks1d3 | However I want to have this database with the data that is comming throught the nova-compute | |
| 13:58:05 | efried | Scheduler meeting in two minutes in #openstack-meeting-alt | |
| 14:01:53 | openstackgerrit | Vladyslav Drok proposed openstack/nova master: Use placement microversion 1.26 in update_from_provider_tree https://review.openstack.org/593628 | |
| 14:36:39 | mriedem | dansmith: some general thoughts on batch strategy in https://review.openstack.org/#/c/593131/ | |
| 14:37:46 | dansmith | mriedem: yeah I think we're thinking in the same direction | |
| 14:37:55 | dansmith | I can come up with complicated things that might be good, | |
| 14:38:03 | dansmith | but we need to decide how much we want to implement in the dark | |
| 14:38:21 | dansmith | if we go with your idea for strategy, I guess we could just implement one or two and then expand to more | |
| 14:38:45 | mriedem | if we did something like that, | |
| 14:38:52 | mriedem | i'd do distributed and fixed | |
| 14:38:58 | mriedem | where fixed is configurable batch size | |
| 14:39:00 | dansmith | I guess I can also see someone wanting "weighted" where we count the number of instance mappings in each cell and pull more from the heavier cells | |
| 14:39:13 | dansmith | yeah | |
| 14:39:49 | mriedem | definitely hard to say, especially without running each through some perf testing like Kevin_Zheng and yikun are doing | |
| 14:39:54 | dansmith | yup | |
| 14:39:59 | efried | batch, please | |
| 14:40:38 | mriedem | dansmith: have you chatted with tssurya about this at all? | |
| 14:40:44 | dansmith | mriedem: I would think distributed and fixed are obvious things we need so we should be able to go with those regardless and then test out some of the other options | |
| 14:40:48 | mriedem | since cern maps projects to cells, i wonder if this doesn't really affect them | |
| 14:40:48 | dansmith | mriedem: nope | |
| 14:40:55 | dansmith | yeah I expect it doesn't | |
| 14:41:18 | dansmith | there may be some projects in multiple cells, but it doesn't really affect you until you get to lots of cells per project | |
| 14:41:22 | mriedem | they might notice a slight difference (<=1s) if a project has instances in >1 cell | |
| 14:41:24 | dansmith | and they might cut down max_limit too | |
| 14:41:28 | dansmith | yep | |
| 14:41:53 | mriedem | yeah let's do distributed and fixed, and default to distributed | |
| 14:42:30 | dansmith | ack | |
| 14:42:58 | dansmith | I'm pleasantly surprised that this worked out as easy as it did, because I was really dreading having to implement this | |
| 14:44:52 | mriedem | i'm pleasantly surprised you already did it.... | |
| 14:44:57 | mriedem | b/c i didn't want to | |
| 14:48:14 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge extended availability zone response into server controller https://review.openstack.org/502859 | |
| 14:48:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge config drive extension response into server controller https://review.openstack.org/584223 | |
| 14:48:16 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge extended server attributes extension response https://review.openstack.org/584590 | |
| 14:48:17 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge keypair extension response into server view builder https://review.openstack.org/584748 | |
| 14:48:18 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge server usage extension response into server view builder https://review.openstack.org/585262 | |
| 14:48:19 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge security groups extension response into server view builder https://review.openstack.org/585475 | |
| 14:48:20 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Merge extended_status extension response into server view builder https://review.openstack.org/592092 | |
| 14:57:11 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove ChanceScheduler https://review.openstack.org/576384 | |
| 15:13:03 | tssurya | dansmith, mriedem: yea it wouldn't affect us much | |
| 15:13:36 | mriedem | vdrok: is this also broken for rocky? https://review.openstack.org/#/c/593628/ | |
| 15:13:41 | mriedem | in that we might need an rc3? | |
| 15:14:25 | mriedem | tssurya: it should in the --all-tenants case | |
| 15:14:40 | mriedem | but maybe you don't care about performance of that | |
| 15:14:58 | tssurya | mriedem: yea we usually use some other filters like project or name before that | |
| 15:15:50 | dansmith | tssurya: cool, I figured as much | |
| 15:16:41 | vdrok | mriedem: yup I think so :( | |
| 15:16:56 | mriedem | http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Invalid%20inventory%20for%20'CUSTOM_BAREMETAL'%20on%20resource%20provider%5C%22%20AND%20message%3A%5C%22The%20reserved%20value%20is%20greater%20than%20or%20equal%20to%20total%5C%22&from=7d | |
| 15:17:05 | mriedem | melwitt: likely have another bug fix for rc2 | |
| 15:19:22 | dansmith | mriedem: she was looking at that on friday, IIRC | |
| 15:19:42 | mriedem | ok rc2 hasn't merged yet, so i -1ed the release request | |
| 15:22:38 | cdent | yay! to ChanceScheduler going by by | |
| 15:24:13 | stewie925 | sorry guys, I am looking for an openstack channel to bring up an openstack-gerrit issue? | |
| 15:27:46 | jroll | stewie925: #openstack-infra would be best | |
| 15:29:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use placement microversion 1.26 in update_from_provider_tree https://review.openstack.org/593628 | |
| 15:33:11 | mriedem | dansmith: if you want i can report a perf bug for the batch size instance list stuff | |
| 15:33:20 | dansmith | mriedem: I want | |
| 15:33:34 | mriedem | you want it you got it! | |
| 15:33:43 | mriedem | the hottest band in the land, KISS! | |
| 15:40:00 | mriedem | dansmith: https://bugs.launchpad.net/nova/+bug/1787977 | |
| 15:40:00 | openstack | Launchpad bug 1787977 in OpenStack Compute (nova) "Inefficient multi-cell instance list" [Medium,Triaged] - Assigned to Dan Smith (danms) | |
| 15:40:03 | dansmith | thanks | |
| 15:52:41 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Use placement microversion 1.26 in update_from_provider_tree https://review.openstack.org/593678 | |
| 15:52:43 | mriedem | dansmith: for rc2 ^ | |
| 16:25:09 | openstackgerrit | Merged openstack/nova master: Remove mox in libvirt/test_driver.py (5) https://review.openstack.org/570842 | |
| 16:33:40 | johnsom | Hi nova folks. I'm getting failures with stable/rocky devstack that is blocking some gates. Would someone have a minute to take a look? http://logs.openstack.org/55/593455/1/check/neutron-lbaasv2-dsvm-api/33e93f3/logs/devstacklog.txt.gz#_2018-08-20_16_04_21_951 | |
| 16:34:04 | johnsom | And http://logs.openstack.org/55/593455/1/check/neutron-lbaasv2-dsvm-api/33e93f3/logs/screen-n-cpu.txt.gz#_Aug_20_16_02_14_425974 | |
| 16:35:52 | johnsom | The later is n-cpu exiting with a critical error | |
| 16:46:54 | dansmith | johnsom: it can't talk to conductor | |
| 16:47:52 | melwitt | . | |
| 16:48:05 | johnsom | I have been digging through logs for a while. It seems to be repeatable across gate hosts. | |
| 16:55:34 | johnsom | It looks like compute service list shows two nova-conductors in the up status. Any pointers where else I should look in the logs? There aren't any errors I see in the n-cond log file | |
| 16:59:59 | openstackgerrit | Konstantinos Samaras-Tsakiris proposed openstack/nova-specs master: Placement model for passthrough devices https://review.openstack.org/591037 | |
| 17:06:24 | kosamara | efried sean-k-mooney: ^^ | |
| 17:06:31 | efried | ack | |
| 17:07:08 | sean-k-mooney | kosamara: currently reivew an sriov bond spec but ill take a look at that next | |
| 17:42:16 | openstackgerrit | Dan Smith proposed openstack/nova master: Make instance_list perform per-cell batching https://review.openstack.org/593131 | |
| 17:42:17 | openstackgerrit | Dan Smith proposed openstack/nova master: List instances from all cells explicitly https://review.openstack.org/593717 | |
| 18:50:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix soft deleting vm fails after "nova resize" vm https://review.openstack.org/546920 | |
| 19:08:01 | melwitt | mriedem: ack on the new patch needed for rc2 | |
| 19:09:33 | openstackgerrit | Merged openstack/nova master: Merge extended availability zone response into server controller https://review.openstack.org/502859 | |
| 19:09:42 | melwitt | problem was reported on friday, when I dug into the logs, I saw that version 1.26 wasn't being sent for the call to allow reserved == total, but didn't realize on the original patch the change missed another call site that needed 1.26 | |
| 19:10:18 | melwitt | glad the fix was found | |
| 19:23:54 | gryf | hi. there is a code in review for some time now. can I get some attention from core reviewers? https://review.openstack.org/#/c/536351 | |
| 19:27:08 | efried | gryf: I think johnthetubaguy ought to have another look at ^ and see if his concerns have been addressed. Other cores will be reluctant to approve the patch with another core's -1 on it. | |
| 19:27:50 | melwitt | dansmith: could you take a look at the proposed fix? ^ it seems to make sense but I'm not that familiar with the particulars of resource reporting considering overcommit | |
| 19:28:22 | dansmith | melwitt: oh yeah I looked at this last week but never said anything | |
| 19:28:35 | dansmith | melwitt: tbh, I'm not sure why we should change that at the moment | |
| 19:28:54 | dansmith | it's just reporting a different value for something we don't look at during scheduling anyway | |
| 19:30:34 | melwitt | they're saying it's being rejected at the check_can_live_migrate_source stage, not related to scheduling | |
| 19:31:02 | melwitt | the disk value is being rejected | |