| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-19 | |||
| 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 | ok, my bad | |
| 11:07:36 | bauzas | so | |
| 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 | dpawlik: kashyap: I don't know what "It allows to hide the KVM hypervisor signature on the guest. | |
| 13:29:02 | mriedem | This enables disabling of some paravirualization features in the | |
| 13:29:02 | mriedem | guest as well as allowing certain drivers which test for the | |
| 13:29:02 | mriedem | hypervisor to load." means | |
| 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 | |
| 13:34:45 | mriedem | i.e. gantt 2.0 | |
| 13:34:54 | bauzas | cdent: I just think it needs to wait scheduler to be a library | |
| 13:34:57 | mriedem | we all agree that placement is generic and will be used by other projects | |
| 13:35:03 | cdent | bauzas: I've not felt like anyone is disagreeing, merely discussing | |
| 13:35:05 | kashyap | mriedem: The thing that exactly hides is this output that you normally see from the command `cpuid`: | |
| 13:35:17 | kashyap | $ cpuid | grep -i hypervisor_id | |
| 13:35:17 | kashyap | hypervisor_id = "KVMKVMKVM " | |
| 13:35:32 | mriedem | kashyap: that's within the guest? | |
| 13:35:36 | bauzas | cdent: but I do recall Jay and us being pretty clear on the fact that the scheduler code is not intended mid-term to be generic | |
| 13:35:36 | kashyap | mriedem: Yes | |
| 13:35:53 | cdent | mriedem: it's something ed said to me at some point in the conversation about "i don't think of the scheduler as 'nova'" and tickled my brain enough to write down explicitly | |
| 13:35:54 | bauzas | cdent: the idea is that placement is cross-project but scheduler is a nova-ism | |
| 13:36:09 | bauzas | (to reuse ed's wording) | |
| 13:36:21 | dpawlik | kashyap: yes (answer for your first question) | |
| 13:36:37 | cdent | bauzas: that may be the idea, but it may be that we don't want to build in things that make it hard to change our minds | |
| 13:36:38 | bauzas | so we could ship the scheduler code into a python module only used by conductors like I said in my reply | |
| 13:36:45 | kashyap | dpawlik: Are you depending exactly on the precise "-no-kvm" option? | |
| 13:37:05 | kashyap | dpawlik: If so, that is being considered for deprecation (in favor of "-cpu,kvm=off") | |
| 13:37:10 | bauzas | cdent: but for me, that sounds premature to discuss on your point, at least until we're fully down the path | |
| 13:37:25 | mriedem | bauzas: cdent: oh boy, ok, well, splitting nova-scheduler out or making it separate for other services to consume is not something i think most anyone besides maybe ed is thinking about | |