Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-25
16:17:10 dansmith so I'm really not looking to settle for not landing it for anything other than a major problem
16:17:33 bauzas dansmith: I don't disagree at all
16:17:46 bauzas I'm just focusing on the right path to success
16:18:29 johnthetubaguy dansmith: +1, I think we have to land it, warts and all
16:18:53 dansmith johnthetubaguy: so is RAX one that would care about not being able to overcommit the node with a single instance?
16:19:21 johnthetubaguy so I should be very specific on my concern
16:19:28 johnthetubaguy right now we don't run the core filter
16:19:40 johnthetubaguy so the overcomit raito is not set correctly
16:19:52 johnthetubaguy thats easily fixable, but does bend our upgrade rules a bit
16:20:25 dansmith johnthetubaguy: ah I see.. we start honoring a config variable that you may not have had to set before.. that's a rather small bend...
16:20:26 johnthetubaguy the 10vCPU VM on an 8pCPU host doesn't worry me
16:20:44 dansmith johnthetubaguy: it's also hard to know how we'd communicate that if we were giving a cycle for reprecation
16:21:02 dansmith johnthetubaguy: also, overcommit on cpu is set to something large by default isn't it?
16:21:07 dansmith 16 and 1.5
16:21:18 dansmith so people with defaults are probably in the sane range already I'd imagine
16:21:40 johnthetubaguy true, that is quite high already
16:22:05 dansmith bauzas: are you working on fixing the test?
16:22:07 johnthetubaguy the complexity is certainly less than having to check if the core filter is enabled
16:22:37 bauzas dansmith: indeed
16:22:47 dansmith johnthetubaguy: and more intuitive than having to enable a legacy filter to make the math work like you (should) expect for the new system
16:23:19 dansmith bauzas: okay I'll reply to the ML thread then
16:23:26 bauzas dansmith: https://github.com/openstack/nova/blob/master/nova/tests/functional/test_server_group.py#L683 is an example of what I mean by "opiniated"
16:28:30 sfinucan diana_clarke: Left a comment on https://review.openstack.org/#/c/421333. I can move onto the rest of the series once that's addressed
16:33:49 bauzas dansmith: are you done with replying to my email ? because I can do that by me, I found the solution for the test
16:33:55 dansmith just did
16:33:58 bauzas okay
16:34:24 bauzas I'm just considering how to patch correctly the FakeDriver within that testcase
16:34:47 dansmith can't you change the request instead of the fake driver?
16:35:19 bauzas dansmith: I would neither change the fake driver itself or the request
16:35:31 bauzas dansmith: the test is RAM-bounded, I'd like to keep it
16:35:50 bauzas so my solution is to have enough CPU-filled computes
16:36:15 bauzas so the test would still assume which host would fail and which not but still only based on one metric, which is RAM
16:36:25 bauzas that's the less invasive
16:36:31 dansmith seems easiest to just request 100% of the compute to fill it, bu okay
16:37:17 bauzas dansmith: it's sending 3 requests with the same big flavor with the assumption that only RAM would fail
16:37:48 cfriesen has anyone heard of virt.libvirt.guest.Guest.get_vcpus_map() failing with "exception: Requested operation is not valid: cpu affinity is not supported" ? Normally this works fine, I just saw it once during a stress test.
16:38:27 sahid cfriesen: are you in TCG?
16:38:56 sahid you should to verify first in you have well configured nova.conf to use kvm
16:39:03 sahid should verify
16:40:46 cfriesen sahid: this is real hardware with kvm
16:41:26 cfriesen sahid: most of the time it works fine on this system, but I saw this log once during a test of multiple live migrations.
16:42:18 sahid cfriesen: hum.. so i would suggest to verify whether the intel VT module is well loaded, it's probably something around that
16:43:19 sahid if it's not configuration issue, virt_type=kvm, the module well loaded so you will probably have to report a bug since that seems weird
16:43:51 cfriesen sahid: I'm pretty sure that the compute node stayed up and running during the test, but I'll check.
16:44:21 sahid cfriesen: also are you trying to run something related to NUMA ?
16:44:58 cfriesen sahid: this is on Mitaka, so I'm not sure how useful a bug report would be. CPU pinning would be enabled, so it'll be setting up InstanceNUMATopology
16:46:59 cfriesen actually, checking the logs more closely this message occurred multiple times...will dig a bit further, see if I can find a pattern.
16:50:16 sfinucan vladikr: The reno in https://review.openstack.org/#/c/405951/ is a little confusing
16:50:20 bauzas dansmith: thanks for your email, appreciated
16:50:45 bauzas dansmith: I'm about to find a solution, but since we also have the grenade issue, just lemme know if you wanna recheck anytime
16:50:45 andreas_s thorst_, FYI https://review.openstack.org/#/c/425279/
16:50:59 andreas_s thorst_, it's not as nice than yours, but it does the job automatically
16:51:03 sfinucan Per my understanding, we want this feature because we want the set the VLAN tag inside the guest OS
16:51:05 vladikr sfinucan, hmm, okay.. how can I clarify it?
16:51:16 andreas_s thorst_, basically it's the generated file included into an rst...
16:51:25 dansmith bauzas: I already did earlier but the gate is pretty slammed
16:51:34 bauzas ok
16:51:36 sfinucan ...but there's no way to access this from inside the instance without this feature
16:51:41 sfinucan vladikr: Is that correct?
16:52:10 cfriesen sahid: It appears to be a race between the resource audit and an instance that is just starting up. I suspect the domain hasn't yet gotten to a state where it will properly respond to this request.
16:52:34 cfriesen sahid: will need to reproduce on newer code before opening a bug report.
16:53:56 vladikr sfinucan, pretty much, I think. We can't set anything in side the guest. We want this field to be exposed so the guest so it will set the vlan on a virtual interface - if it need it to be set
16:54:53 openstackgerrit Ed Leafe proposed openstack/nova: placement: RT now adds proper Ironic inventory https://review.openstack.org/404472
16:55:09 vladikr sfinucan, so we just want to add additional parameter to the device metadata (that we have exposed to the guests with the device tagging work)
16:55:20 sahid cfriesen: ok cool, just as a sidenote since you spoke about live-migration: https://review.openstack.org/#/c/419479/
16:55:28 edleafe cdent: Fixed your concern ^^
16:56:03 cdent edleafe: thanks. was I crazy or insightful?
16:56:39 edleafe Those are not mutually exclusive
16:56:42 sfinucan vladikr: Right. So this sentence would suggest otherwise >>> "the VLAN configuration for the guest's virtual interfaces associated with such devices, can only be done within the guest instance itself."
16:57:01 sfinucan at least to me, that suggests the guest can now configure VLANs for these interfaces
16:57:06 cdent edleafe: was I right or wrong?
16:57:31 edleafe cdent: you were right
16:57:52 vladikr sfinucan, well it says that if you have assigned an sriov device to the guest you will get a virtual interface inside the guest
16:58:14 cfriesen sahid: thanks for the reference
16:58:25 sfinucan vladikr: Right, and it's the guest's responsibility to set the VLAN field on that virtual interface?
16:58:28 vladikr sfinucan, the guest can now configure the vNIC using the devices metadata
16:58:32 vladikr yea
16:58:37 sfinucan Gotcha
16:58:50 sfinucan That's what I thought, but I wasn't 100% :)
16:59:47 openstackgerrit Pawel Koniszewski proposed openstack/nova: Mark live_migration_downtime_steps/delay as deprecated for removal https://review.openstack.org/408002
17:02:56 vladikr sfinucan, :) maybe it's just too much information there- not sure how to make it better
17:07:04 sfinucan vladikr: Left a comment suggesting as much https://review.openstack.org/#/c/405951/12
17:07:18 vladikr sfinucan, great, thanks
17:12:48 cdent edleafe, bauzas, dansmith: because we haven't had enough to read about the resource tracker today, here's some analysis of things it might be doing less than perfectly with regard to the placement api: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110953.html
17:13:06 cdent some of those are probably well known, but still worth thinking about so we avoid too many requests
17:21:33 openstackgerrit Gábor Antal proposed openstack/nova: Transform instance.live_migration_rollback notification https://review.openstack.org/402124
17:22:26 openstackgerrit Pushkar Umaranikar proposed openstack/nova: Adopts keystoneauth with glance client. https://review.openstack.org/412634
17:25:14 edleafe cdent: yeah, was just reading that
17:25:17 openstackgerrit Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 map_instances https://review.openstack.org/421404
17:25:17 openstackgerrit Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 map_cell_and_hosts https://review.openstack.org/421420
17:25:18 openstackgerrit Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 verify_instance https://review.openstack.org/421436
17:25:18 openstackgerrit Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 simple_cell_setup https://review.openstack.org/421333
17:25:19 openstackgerrit Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 map_cell0 https://review.openstack.org/421384
17:25:19 openstackgerrit Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 delete_cell https://review.openstack.org/421459
17:25:20 openstackgerrit Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 discover_hosts https://review.openstack.org/421442
17:25:20 openstackgerrit Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 list_cells https://review.openstack.org/421458
17:25:21 openstackgerrit Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 create_cell https://review.openstack.org/421444
17:26:09 edleafe cdent: A lot of those were because of the belts & braces approach to make sure we didn't miss things
17:26:32 cdent some of them
17:26:46 cdent but there's outright wrongness with the tracked_instances thing

Earlier   Later