| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-15 | |||
| 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 | |
| 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? | |
| 16:19:37 | mriedem | is that checks that the capabilities provided by the host compute ? | |
| 16:19:42 | mriedem | er https://developer.openstack.org/api-ref/compute/?expanded=show-hypervisor-statistics-detail#show-hypervisor-statistics | |
| 16:20:01 | mriedem | so capabilities:running_vms < 10 ? | |
| 16:20:11 | bauzas | mriedem: https://github.com/openstack/nova/blob/master/nova/tests/unit/scheduler/filters/test_compute_capabilities_filters.py#L72 | |
| 16:20:20 | bauzas | mriedem: ^ is the flavor extra specs | |
| 16:20:29 | bauzas | mriedem: but you can ask for anything in the HostState object | |
| 16:20:43 | bauzas | of course, cpu_info is one attribute of it | |
| 16:20:49 | mriedem | so the answer is, go look at the HostState code | |
| 16:20:54 | bauzas | mriedem: exactly | |
| 16:20:58 | mriedem | which is a shit answer | |
| 16:21:01 | bauzas | exactly | |
| 16:21:19 | bauzas | no, it's just something driven by hack | |
| 16:21:45 | bauzas | but until we get traits sorting, that's the only thing you can do | |
| 16:22:03 | bauzas | lovely, isn't it ? | |
| 16:22:10 | mriedem | bauzas: is the HostState fields that feed that filter finite? | |
| 16:22:15 | openstackgerrit | John Griffith proposed openstack/nova master: WIP/POC Implement new attach Cinder flow https://review.openstack.org/330285 | |
| 16:22:16 | mriedem | s/is/are/ | |
| 16:22:22 | bauzas | mriedem: absolutely not | |
| 16:22:25 | mriedem | gdi | |
| 16:22:35 | bauzas | mriedem: because you can use stats | |
| 16:22:44 | bauzas | and voila, you can report anything you want | |
| 16:23:17 | mriedem | but what feeds the stats? | |
| 16:23:24 | bauzas | I refrained in the past a long list of changes wanting to add more things in the HostState or filtering based on any cool attributes | |
| 16:23:55 | bauzas | the only answer I was able to provide before jaypipes saved the world with ResourceProviders and Traits was "go use stats" | |
| 16:24:20 | jaypipes | bauzas: s/saved the world/caused the world to burn to a crisp/ | |
| 16:25:14 | bauzas | jaypipes: you should just feel like http://api.theweek.com/sites/default/files/styles/tw_image_9_4/public/50692_article_full.jpg?itok=X1oW13j5&resize=1260x560 | |
| 16:25:28 | jaypipes | heh | |