| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-15 | |||
| 14:54:46 | ftersin | mdbooth: could you estimate when you become able to work on the reviews? | |
| 14:55:33 | mdbooth | ftersin: I'd hoped this week, but now I'd guess maybe early next week. Tuesday-ish? | |
| 15:00:48 | ftersin | mdbooth: i think that not so much time is left in Pike for such big work. Because that it'd be perfect if we start in the closest future | |
| 15:01:40 | openstackgerrit | Moshe Levi proposed openstack/os-vif master: hardware offload support for openvswitch https://review.openstack.org/460278 | |
| 15:04:11 | sfinucan | moshele: Will do | |
| 15:14:43 | cfriesen | dansmith: can "nova-manage db online_data_migrations" run with nova-conductor not running? | |
| 15:14:57 | dansmith | of course | |
| 15:16:48 | cfriesen | thanks | |
| 15:19:12 | sfinucan | nicolasbock: Hey - sorry, was in a meeting | |
| 15:19:31 | sfinucan | I don't think there's too much to be done right now. asettle is gone for the week so the spec is stuck | |
| 15:19:48 | sfinucan | Maybe just review that spec and see if you agree with it. I'll do the same myself tomorrow | |
| 15:28:48 | tasker | morning! I'm tracking down a problem with evacuation in Mitaka and came across https://review.openstack.org/#/c/385086/, which mentions commit c15ed42. I cannot find that commit anywhere. Similarly, Artom is mentioning (in more than one bug / review) that "since event dispatching is fixed" this is not a problem anymore, but saying so without reference. Can someone put their finger on these patches? | |
| 15:29:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add Cinder v3 detach to swap_volume https://review.openstack.org/456971 | |
| 15:30:28 | tasker | is Artom referring to this one? https://review.openstack.org/#/c/371048/ | |
| 15:35:55 | mriedem | tasker: probably | |
| 15:47:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Provide original fault message when BFV fails https://review.openstack.org/467715 | |
| 15:48:36 | nicolasbock | sfinucan, no problem | |
| 15:48:42 | nicolasbock | sfinucan, I'll have a look at it | |
| 15:52:29 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1766 | |
| 15:52:29 | mriedem | dansmith: i just found that if we try to create a server with tagged devices and it lands on a host that doesn't support that, it's going to abort the build rather than reschedule | |
| 15:52:34 | mriedem | doesn't that seem...wrong? | |
| 15:52:54 | dansmith | um, why? | |
| 15:52:58 | mriedem | in thinking about the "95% of reschedules are due to claim contention" thing | |
| 15:53:14 | dansmith | it's an abort not a reschedule right? | |
| 15:53:15 | mriedem | why wouldn't we reschedule to try another host | |
| 15:53:45 | dansmith | because you likely picked a flavor that has you on a specific hypervisor type anyway, so reschedule would just waste resources until you run out of retries | |
| 15:54:38 | mriedem | seems like a big assumption | |
| 15:54:51 | mriedem | i don't need a special flavor to create a server with nic/bdm tags | |
| 15:55:19 | mriedem | granted, the chances of hitting a xen host and failing and then hitting a libvirt host are probably slim anyway | |
| 15:55:27 | mriedem | or chances of having a mixed compute env to start with anyway | |
| 15:55:36 | mriedem | *mixed hypervisor | |
| 15:57:17 | jaypipes | is it wrong that ever since Trump got elected, I can't stop myself from saying "Melania Witt" every time I see melwitt's IRC nick? :( | |
| 15:57:32 | mriedem | heh, just thinking out loud, my compute is managing vcenter, and consecutive_build_service_disable_threshold defaults to 10, and someone tries to create a server with tagged devices, | |
| 15:57:41 | mriedem | after 10 tries that compute and my entire vcenter behind it is disabled now | |
| 15:58:27 | dansmith | mriedem: the point is, I think that most people end up with flavors that correspond to hypervisors if they have multiple in their cloud, | |
| 15:58:40 | dansmith | mriedem: and the reason we don't support device tagging is because the hypervisor driver doesn't support it | |
| 15:58:47 | dansmith | mriedem: so rescheduling the same flavor isn't going to help | |
| 15:59:04 | mriedem | yeah - yo'ure kind of screwed in the non-mixed hyperivsor vmware case above | |
| 15:59:08 | mriedem | but then you disable the config option | |
| 15:59:24 | mriedem | or make the vcenter driver support tagged devices | |
| 15:59:31 | dansmith | right, so I don't really see any situation where rescheduling on that failure makes sense | |
| 15:59:35 | dansmith | it's a config/support issue | |
| 16:01:16 | mriedem | do the driver capabilities feed into the ComputeCapabilitiesFilter? | |
| 16:01:27 | mriedem | i've never been able to read that filter code and understand it | |
| 16:01:46 | dansmith | um, I dunno | |
| 16:02:04 | dansmith | you mean to avoid scheduling to nodes that claim not to support this thing? | |
| 16:02:10 | dansmith | I don't think this is one of those things, but I guess it could be | |
| 16:02:47 | mriedem | something like that | |
| 16:02:55 | mriedem | i think ComputeCapabilitiesFilter checks compute node stats | |
| 16:03:01 | mriedem | which is the nova.compute.stats.Stats object i guess | |
| 16:03:09 | dansmith | sure, but I'm not sure I see this as a huge deal :) | |
| 16:03:44 | mriedem | it's not a huge deal b/c it's always been a mess | |
| 16:03:52 | mriedem | it just ties back into the capabilities api stuff | |
| 16:04:06 | mriedem | and the fact you can request something and end up on a host that doesn't support it and then it's NoValidHost | |
| 16:04:21 | dansmith | no, | |
| 16:04:25 | dansmith | you won't get novalidhost there | |
| 16:05:08 | dansmith | but yeah, I agree it'd be nice to avoid that situation, I just mean going to some extreme like exporting a stat just for this flag to eliminate this for device tagging (and not all the other things generic capabilities would solve) doesn't seem worth it tome | |
| 16:06:20 | mriedem | i guess you don't get NoValidHost, you get an instance in ERROR state with a BuildAbortException recorded as the fault | |
| 16:06:23 | mriedem | anywho | |
| 16:06:28 | dansmith | yeah | |
| 16:06:47 | bauzas | sorry, got distracted but just saw this thread | |
| 16:07:08 | bauzas | yeah, we already have some filters for matching with hypervisors "capabilities" | |
| 16:07:21 | bauzas | one for matching flavors against it, and the other for images | |
| 16:07:50 | bauzas | say you have a flavor, you can restrict it to some computes based on their "capabilities" | |
| 16:07:56 | bauzas | ie. old traits style | |
| 16:08:10 | dansmith | yeah this isn't quite that.. similar but not exactly | |
| 16:08:15 | dansmith | from the filtering side I mean | |
| 16:08:18 | bauzas | but sshhhttt, or jaypipes would tableflip :p | |
| 16:09:08 | dansmith | this would be something where we'd have to add the capability or trait of "can do device metadata" to what they or their image asked for | |
| 16:09:23 | dansmith | since they shouldn't have to ask for a trait of device-metadata _and_ set the device metadata themselves | |
| 16:09:58 | bauzas | dansmith: you mean the matching ? | |
| 16:10:14 | bauzas | dansmith: not sure I get you | |
| 16:10:20 | dansmith | not sure I get /you/ ;) | |
| 16:10:24 | bauzas | hah | |
| 16:10:41 | bauzas | pourtant je parle bien | |
| 16:10:42 | bauzas | :p | |
| 16:10:43 | mriedem | bauzas: my point or question is, | |
| 16:10:54 | mriedem | https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L124 does not get exposed/used in ComputeCapabilitiesFilter right? | |
| 16:11:18 | mriedem | like "supports_attach_interface" seems kind of important to know for filtering | |
| 16:11:32 | mriedem | well, not really for filtering since it's something you do to an existing instance | |
| 16:11:38 | dansmith | mriedem:not really | |
| 16:11:39 | dansmith | yeah | |
| 16:11:44 | mriedem | so once you're on a host, you're screwed if it doesn't support that | |
| 16:11:45 | dansmith | you don't know you need that ahead of time necessarily | |
| 16:11:52 | bauzas | sec, verifying filters | |
| 16:12:04 | dansmith | I'm quite sure those virt caps are not reflected anyhere | |
| 16:12:10 | dansmith | they're just used as feature flags inside compute manager | |
| 16:12:13 | mriedem | right i didn't think so | |
| 16:12:23 | bauzas | dansmith: that's correct | |
| 16:12:48 | mriedem | i've always thought we could easily stash these in the compute node record and check them in the api, which would be a poor man's capabilities api thing | |
| 16:12:59 | mriedem | and i think that's kind of how the cinder volume backend capabilities stuff works | |
| 16:13:32 | bauzas | mriedem: dansmith: so the "capabilities" that are exposed in the HostState are not the above | |
| 16:13:34 | mriedem | but, i don't really want to go down that path right now | |
| 16:13:39 | mriedem | bauzas: right | |
| 16:13:41 | mriedem | yes? | |
| 16:13:41 | mriedem | they are the stats | |
| 16:13:42 | dansmith | not sure I'm in favor of half-assing the capabilities thing since it's pretty critical | |
| 16:13:52 | mriedem | dansmith: sure, i don't want to half ass it either, | |
| 16:13:58 | mriedem | there is currently 0 ass working on it | |
| 16:14:04 | dansmith | yeah | |