| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-15 | |||
| 15:48:42 | nicolasbock | sfinucan, I'll have a look at it | |
| 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:29 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1766 | |
| 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 | they are the stats | |
| 16:13:41 | mriedem | yes? | |
| 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 | |
| 16:14:29 | bauzas | mriedem: not only the stats AFAIK | |
| 16:14:31 | mriedem | also, let's start quantifying efforts from now on by how much ass it requires | |
| 16:15:02 | dansmith | heh | |
| 16:15:04 | bauzas | mriedem: that's litterally : please match my flavor extra specs key with some HostState field having the same name, more or less namespaced | |
| 16:15:47 | mriedem | bauzas: we just have none of that defined anywhere though right? | |
| 16:15:58 | mriedem | like as an operator how would i know what the available capabilities are? | |
| 16:16:03 | mriedem | w/o reading the code | |
| 16:17:10 | mriedem | i'm surprised it's even in the default list of enabled filters | |
| 16:17:21 | bauzas | mriedem: that's just one of the hackiest filters we merged in the past with the worst external API | |
| 16:17:43 | bauzas | the API being the contract you make on your flavor extraspecs | |
| 16:18:18 | NostawRm | I'm not sure this is the right place for this, but I'm not really savvy on how nova uses everything all the fields it has available. I don't really see how 'accessIPv4/6' is being used, but would it make sense at all in netutils.py to get them and return that IP for metadata/configdrive if its in the list of IPs for a vif? | |
| 16:18:36 | NostawRm | Guess I don't want to start going down the rabbit hole unless it makes sense :P | |
| 16:18:51 | NostawRm | oh hrm, but it doesn't for most people, because for most people an access IP is a floating IP. | |
| 16:19:10 | mriedem | https://docs.openstack.org/developer/nova/filter_scheduler.html says | |
| 16:19:16 | mriedem | "checks that the capabilities provided by the host compute" | |
| 16:19:21 | bauzas | mriedem: see the UTs, you'll enjoy | |
| 16:19:24 | mriedem | but where would one find what those capabilities are? | |