Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-25
16:02:32 edleafe bauzas: at least curse in French
16:02:45 bauzas so, just to be clear, lemme restate for the audience
16:02:47 dansmith even worse in what way? that it's a change?
16:03:07 bauzas in Newton, we totally accept that we can return a destination that doesn't satisfy the vCPU requirements
16:03:31 bauzas that's worst because that's changing the scheduler behaviour
16:03:48 edleafe Returning a destination is an implementation detail, not a behavior
16:04:09 bauzas placing an instance on a target is a behavioural choice
16:04:15 dansmith bauzas: but the whole point of placement is making better decisions right?
16:04:19 edleafe If anything, the change should reduce the number of retries
16:04:21 dansmith not less opinionated ones, but better ones
16:04:48 edleafe dansmith: jinx (sorta)
16:04:53 dansmith aye
16:06:32 bauzas edleafe: dansmith: the fun with that is that the problem still remains for RAMFilter
16:06:51 dansmith but really,
16:06:55 bauzas even if we say "fair enough, we don't need to advert operators to modify their ratios for cpu"
16:07:01 bauzas the problem remains for ram
16:07:02 dansmith overcommitting the whole node in a single VM is just nuts
16:07:10 dansmith eve more nuts than cpu
16:07:27 dansmith if we want to offer an insanity_mode config option, then let's do it
16:07:35 dansmith and make it clear what it is
16:07:49 dansmith I'll write the patch
16:08:23 bauzas I'm still wondering why we never used CoreFilter in that case
16:08:41 dansmith all I really care about is getting this patch in so we're not kicking it to another release
16:08:42 edleafe dansmith: "If you want to stick your fork into the electrical socket..."
16:08:51 dansmith edleafe: that can go in the help text
16:09:12 bauzas so you gonna rev'd my change?
16:09:30 dansmith it doesn't affect your change, right? it'd be a reporting change
16:09:48 dansmith but yes, if I need to write that patch to move us forward I'll do it
16:10:46 edleafe I think that's the wrong approach
16:11:18 edleafe It's not breaking anything
16:11:34 dansmith edleafe: you think what is wrong? allowing insanity_mode?
16:11:46 edleafe dansmith: yes
16:12:10 edleafe If someone is actively relying on this, they *should* fail
16:12:14 dansmith edleafe: IMHO, I'd wait for people to complain and then do it to get them out of hot water
16:12:15 edleafe and they should feel bad
16:12:18 dansmith hah
16:12:40 dansmith but if bauzas is going to rage quit now, then I could be persuaded to add it now
16:12:47 dansmith but I agree, it seems like making better choices to me
16:12:53 bauzas I'm not rage quitting, just exhausted
16:13:01 dansmith johnthetubaguy: were you one of the concerned porties/
16:13:02 dansmith jeez
16:13:03 dansmith *parties?
16:13:12 bauzas because in particular, my f**** change is hitting a functional test issue
16:13:20 bauzas based on that particular assumption
16:13:30 dansmith bauzas: that's trivial to fix right?
16:13:42 dansmith that functional test is reporting something that depends on the broken behavior to work, right?
16:13:52 bauzas honestly? I dunno
16:14:10 bauzas we could fix up what the compute reports
16:14:18 bauzas that sounds the better approach
16:14:38 bauzas but those whole tests are so opininiated about what should fail and what should succeed
16:14:38 dansmith bauzas: you mean what compute reports in that functional test, yes?
16:14:46 bauzas dansmith: yup
16:14:54 edleafe bauzas: So you think that the test is absolutely correct in what it's testing?
16:15:20 bauzas edleafe: I just think that functional test is fine by me, it's just not taking care of other resources
16:15:23 edleafe bauzas: or could it be making the same incorrect assumption?
16:15:43 bauzas edleafe: since we default verifying those resources, we could have to change the tests
16:15:43 dansmith bauzas: but that test is relying on overcommitting the node with a single vm right?
16:15:47 edleafe Tests are code, and all code has bugs
16:16:05 bauzas dansmith: yup, it was just taking care of RAM previously
16:16:13 dansmith right, so the test is wrong
16:16:16 dansmith let's fix and move on
16:16:45 dansmith I, for one, am fairly concerned about what happens if we don't merge this code this cycle
16:16:48 dansmith I dunno about anyone else
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?

Earlier   Later