Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-19
10:30:52 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for os-interface endpoint instead of stevedore https://review.openstack.org/459979
10:31:08 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for server-tags instead of stevedore https://review.openstack.org/461645
10:31:24 openstackgerrit Stephen Finucane proposed openstack/nova master: Use plain routes list for server-migrations endpoint instead of stevedore https://review.openstack.org/461646
10:35:32 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove useless API tests https://review.openstack.org/461011
10:56:04 openstackgerrit Sylvain Bauza proposed openstack/nova master: Scheduler returning alternatives per destination https://review.openstack.org/465175
10:56:05 openstackgerrit Sylvain Bauza proposed openstack/nova master: WIP: Allocate instance by the conductor https://review.openstack.org/460455
10:56:05 openstackgerrit Sylvain Bauza proposed openstack/nova master: Delete existing allocations when retrying https://review.openstack.org/460433
11:00:18 cdent bauzas: thanks for expanding the commit message on the retrying change. Can you confirm my understanding: the goal is to delete transient allocations (which aren't currently using physical resources) as soon as we know they are going to be eventually deleted, so that something else can try to consume them sooner.
11:00:20 cdent Is that right?
11:01:43 bauzas cdent: the goal is to propose hosts that can be acceptable per filters/weighers in case the original host is not being accepted when the conductor posts the allocations
11:02:29 bauzas cdent: given we have placement that verifies allocations, it's fine to propose hosts that are not fulling matching with the *new* situation, but at least have been verified as matching with the other requests
11:02:33 cdent I'm speaking specifically about the allocations that could have been cleared up later at the time NoValidHost happens
11:02:52 bauzas cdent: so, there are 2 cases
11:03:10 bauzas cdent: 1/ if the conductor posts an allocation but gets a "sorry" from placement
11:03:56 bauzas cdent: 2/ if the allocation is done correctly, but then the compute exceptionnally has an exception (because of libvirt-ish so else) and then reschedules the instance to the conductor
11:04:37 bauzas cdent: if scheduler gives back a NoValidHosts to conductor, then the conductor will behave like the existing
11:05:11 bauzas (unless I misunderstood your problem, which is definitely something possible :D )
11:07:10 bauzas cdent: oh , you mean about the need for https://review.openstack.org/#/c/460433/10 ?
11:07:13 bauzas (sorry my bad)
11:07:22 bauzas I thought you were talking of the need for alternatives
11:07:23 cdent I'm talking about my question on ps 8 on https://review.openstack.org/#/c/460433 about why we are deleting allocations early (instead of waiting to handle them on NoValidHost) and trying to confirm my understanding of your adjustments to the commit message there
11:07:36 bauzas so
11:07:36 bauzas ok, my bad
11:07:50 bauzas the problem is with transient allocations like I said
11:07:55 bauzas imagine the scenario
11:08:05 cdent basically if you can confirm "so that something else can try to consume them sooner" is correct, I'm satisfied
11:08:12 bauzas Ironic and 2 concurrent instances
11:08:20 bauzas instance 1 is scheduled to hostA
11:08:31 bauzas then the allocation will be made against hostA
11:08:36 bauzas but then it's rescheduled
11:08:48 bauzas concurrently, instance2 is scheduled
11:09:05 bauzas given allocation is posted against hostA, placement won't provide hostA as a valid target
11:09:24 bauzas which is a sad panda, because we know it's being rescheduled
11:09:51 bauzas cdent: does that fit with your concerns ?
11:10:19 bauzas tbh, I'm not super attached to that patch, I just think it helps some possible race condition
11:11:29 cdent when instance1 tries to go to hostA but then is rescheduled, what does that mean about the current state of hostA as a good target for any allocations?
11:11:30 bauzas cdent: FWIW, I'm not trying to focus my efforts on updating https://review.openstack.org/#/c/460455/ now that we have alternatives
11:12:07 bauzas cdent: instance being rescheduler doesn't necessarly imply that the host where the instance was set to is necessary bad
11:12:30 bauzas cdent: we discussed that at Summit, and we identified (ops too) that most of the time, it's uncorrelated with resource constraints
11:12:32 cdent but it could be, right?
11:14:04 cdent I guess I take a relatively conservative position on this stuff: I think we can avoid inaccuracies and confusion by holding allocations a bit longer, at the cost of less packing. But it seems that people are more interested in packing?
11:14:54 bauzas cdent: that's a good point
11:15:45 bauzas cdent: from what I recall from the summit, people wanted to make sure we were not removing some host because of a resource constraint, because they said most of the time it's because of X or Y
11:16:03 bauzas cdent: were you at the cells 2 forum session where most of the crux was discussed there ?
11:16:21 bauzas cdent: as dan asked whether they were interested in stopping to reschedules
11:16:32 bauzas cdent: most of the present folks were horrified by that
11:16:47 bauzas anyway, I need to disappear for a bit
11:17:00 cdent i had to be somewhere else for that one, but i heard a summary later
11:17:10 cdent me too, I'll keep thinking about it. thanks for the info.
11:19:38 bauzas np
11:29:28 openstackgerrit Hironori Shiina proposed openstack/nova master: Ironic: Support boot from Cinder volume https://review.openstack.org/215385
11:44:04 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Document 'nova-manage db online_data_migrations' https://review.openstack.org/464634
12:58:08 mriedem o/
12:59:58 mriedem sdague: this gets the grenade live migration job going again (limited) https://review.openstack.org/#/c/466097/ and this gets the live migration back and forth testing going in that job https://review.openstack.org/#/c/466033/
13:01:14 sdague mriedem: +A
13:01:18 mriedem thanks
13:06:02 dpawlik mriedem: Hi. I changed as you suggest in PS https://review.openstack.org/#/c/459753
13:06:44 bauzas mriedem: I replied on your status email about the claims discussion
13:06:57 bauzas mriedem: AFAIUI, we already had a consensus :)
13:09:34 mriedem bauzas: i see that
13:10:34 mriedem dpawlik: ok, it's not a bug though, it's a feature, so it should have a blueprint
13:16:36 dpawlik mriedem: ack
13:17:44 cdent bauzas, mriedem: I threw my own crazy talk 2c into the mix too because I'm lonely and want to make friends.
13:24:15 mdbooth mriedem: Do we have a pattern for internal code assertions other than assert() ? We don't seem to have too many assert()s in our code.
13:24:38 mdbooth mriedem: I ask in the context of https://review.openstack.org/#/c/443951/ where I've recommended he use assert() rather than raise an exception
13:25:43 mriedem mdbooth: not really
13:26:16 mdbooth mriedem: Ok, cool. Was just wary of asking him to fix that, only to have him respin yet again because we do something else.
13:26:18 cdent mdbooth++ for assert in programming error case
13:27:44 dpawlik mriedem: https://blueprints.launchpad.net/nova/+spec/add-kvm-hidden-feature
13:27:52 mriedem mdbooth: did you see my beautiful code dive through attaching a volume during bfv and attach_volume? what a mess.
13:27:59 dpawlik I will change PS commit message soon
13:28:09 mriedem kashyap: are you aware of this kvm hidden feature thing?
13:28:10 mriedem ^
13:28:17 mdbooth mriedem: I did :) I took a short cut to convincing myself that was correct.
13:28:33 mriedem mdbooth: at some point i should probably write that up in the devref, but...
13:28:39 kashyap I think I know what it means from the title
13:28:45 openstackgerrit Alex Szarka proposed openstack/nova master: Add method for verify multiple notifications https://review.openstack.org/465526
13:29:01 mdbooth mriedem: Logically, that method makes no sense unless the volume is connected
13:29:02 mriedem hypervisor to load." means
13:29:02 mriedem guest as well as allowing certain drivers which test for the
13:29:02 mriedem This enables disabling of some paravirualization features in the
13:29:02 mriedem dpawlik: kashyap: I don't know what "It allows to hide the KVM hypervisor signature on the guest.
13:29:16 mriedem mdbooth: which one? get_config?
13:29:21 mdbooth Yeah
13:29:26 mriedem mdbooth: yeah it's super tightly coupled,
13:29:37 mdbooth If the connector hasn't connected it, we can't tell libvirt where it's connected
13:29:38 kashyap mriedem: Okay, I'm aware of what it is, it means:
13:29:39 mriedem we should almost just refactor to have connect_volume always return get_config...
13:29:46 mriedem but we have that live migration case
13:30:37 kashyap mriedem: It just lets one _hide_ the fact that it is a KVM guest
13:30:53 kashyap But removing the CPUID signature for guest that is running w/ KVM acceleration
13:31:12 kashyap dpawlik: Are you referring to the "-no-kvm" QEMU command-line option, right?
13:31:13 mriedem hide it from what?
13:31:37 kashyap mriedem: Hide it from whatever programs that depend on that output to identify: "Yes, this is a KVM guest"
13:31:59 mriedem alright
13:33:26 kashyap It is possible via the confusingly-named, QEMU command-line option '-cpu,kvm=off'
13:34:13 kashyap Which doesn't turn off KVM acceleration itself, merely the *signature* of it
13:34:28 kashyap You might wonder what exactly the **** is this "signature"?
13:34:29 bauzas cdent: FWIW, I'm not disagreeing with you on the long-term direction to see claims closer
13:34:39 mriedem cdent: so reading https://review.openstack.org/#/c/465171/3//COMMIT_MSG@30 i didn't realize that what ed is trying to do is make the nova-scheduler something that other projects are going to use

Earlier   Later