| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-28 | |||
| 19:13:39 | sean-k-mooney | dansmith: gladly, i just have to keep remining people that os-vif is used with nova net too so we cant break it eventhough we dont gate on it for the os-vif repo :) | |
| 19:14:13 | dansmith | sean-k-mooney: I'm just saying there's a lot of stuff we get to remove when we drop n-net, and you're late to that party :P | |
| 19:15:30 | efried | mriedem I have reason to believe that it is impossible to use anything other than the public interface for cinderclient in Nova. | |
| 19:15:56 | sean-k-mooney | haha yes though not that late i have wanted to kill nova-net since neutron was still quantum but in fairness to nova net it proably was a better choice for large deployment back then. | |
| 19:16:15 | efried | (mriedem or point me to someone else who would have the inclination to walk through this with me) | |
| 19:17:19 | mriedem | efried: ok? | |
| 19:17:52 | efried | mriedem D'oh, nope, buried in the bowels, the 'interface' kwarg overrides 'endpoint_type'. | |
| 19:18:10 | efried | It's just way non-obvious from the first four layers of calls. | |
| 19:18:15 | efried | Carry on. | |
| 19:18:16 | mriedem | sean-k-mooney: dansmith: don't forget that if we wait long enough, edge will require nova-net again | |
| 19:18:37 | sean-k-mooney | edge? | |
| 19:18:55 | sean-k-mooney | as in cloud edge computing | |
| 19:19:10 | mriedem | yes | |
| 19:20:48 | sean-k-mooney | ah well it might actullly work well in that model in multihost mode untill a telco trys to add sfc to nova net | |
| 19:36:39 | mriedem | stvnoyes: ok comments inline https://review.openstack.org/#/c/463987/ | |
| 19:36:45 | mriedem | once those test things are cleaned up i'm +2 | |
| 20:00:01 | stvnoyes | cool. thx | |
| 20:05:13 | catintheroof | hi guys, quick question, when CoreFilter is enabled on the scheduler nodes, is cpu_allocation_ratio allowed per compute node ? | |
| 20:09:23 | mriedem | catintheroof: i believe that means you can configure the cpu_allocation_ratio per compute service or just take the default in the scheduler filter for all nodes | |
| 20:09:33 | mriedem | the help text for the config option says the same | |
| 20:10:30 | dansmith | speaking of that, did we deprecate those filters in pike such that we can remove them now? | |
| 20:11:16 | mriedem | i think only the exact ones | |
| 20:11:35 | dansmith | I thought we were going to deprecate the regular ones too | |
| 20:11:49 | mriedem | caching scheduler | |
| 20:11:59 | mriedem | we removed ram and disk filters from the default enabled_filters list, | |
| 20:12:00 | dansmith | oh | |
| 20:12:07 | mriedem | but didn't deprecate them b/c of caching scheduler, which doesn't use placement | |
| 20:12:24 | dansmith | we could make them only loadable if the driver is set to caching maybe? | |
| 20:12:27 | mriedem | at least that's what i'm reading in the release notes | |
| 20:12:42 | mriedem | anything is possible, | |
| 20:12:48 | mriedem | although any out of tree scheduler drivers might break on that | |
| 20:12:52 | mriedem | and we allow those | |
| 20:13:12 | dansmith | an out-of-tree driver that uses our filters? | |
| 20:13:16 | mriedem | sure | |
| 20:13:18 | mriedem | like, | |
| 20:13:24 | mriedem | maybe i extend CachingScheduler | |
| 20:13:32 | mriedem | because i like to have fun | |
| 20:13:44 | dansmith | out of tree filters and weighers I can see, but.. whole drivers? | |
| 20:13:59 | mriedem | it's a thing i guess, and we broke it in ocata, | |
| 20:14:05 | mriedem | and had to fix that in pike and backport | |
| 20:14:11 | mriedem | since we never deprecated that ability formally | |
| 20:14:15 | dansmith | with an out of tree driver you're going to end up with fubar'd placement and such | |
| 20:14:35 | mriedem | do we default to use placement or not... | |
| 20:14:46 | mriedem | USES_ALLOCATION_CANDIDATES = True | |
| 20:14:49 | mriedem | we default to use placement | |
| 20:15:28 | mriedem | btw, | |
| 20:15:31 | dansmith | I guess I'm not sure where the seam is, are you saying that we do the claim late enough that it's run for every driver? | |
| 20:15:40 | mriedem | it seems a bit nutty that we join on system_metadata when listing all instances with details | |
| 20:16:01 | dansmith | we used to have to have that join for flavor info | |
| 20:16:06 | mriedem | yeah, i figured, | |
| 20:16:08 | mriedem | but that's long gone | |
| 20:16:19 | mriedem | do you still have your perf box env setup? | |
| 20:16:31 | dansmith | I think it will come back up ready, lemme see | |
| 20:16:47 | dansmith | I was also thinking of another thing I could do: | |
| 20:16:52 | mriedem | for the scheduling thing, if the driver says USES_ALLOCATION_CANDIDATES=False, we don't ask placement for anything | |
| 20:16:57 | dansmith | put duplicate cell entries in for the same cell to cause us to list across more cells for free | |
| 20:17:09 | mriedem | and we don't attempt to claim in the scheduler | |
| 20:17:28 | dansmith | we could make those filters refuse to load if driver is set to the filter scheduler, just flip the logic | |
| 20:17:44 | dansmith | I mean log deprecation now, and fail in rocky | |
| 20:17:57 | mriedem | that seems ok | |
| 20:18:37 | dansmith | we really need to be removing the honoring of the limits provided by those filters from compute anyway I think | |
| 20:18:50 | dansmith | we've not really done any culling of stuff that is now handled by placement from compute/rt | |
| 20:20:20 | mriedem | speaking of culling | |
| 20:20:22 | mriedem | _get_all_instance_metadata | |
| 20:20:24 | mriedem | in compute api | |
| 20:20:31 | mriedem | apparently the only things that use that, aren't used by anything else | |
| 20:22:20 | mriedem | i'm going through https://review.openstack.org/#/c/505418/ btw | |
| 20:22:25 | mriedem | hence asking random questions | |
| 20:23:19 | dansmith | thank you | |
| 20:23:53 | dansmith | my devstack setup came back so I'll poke at sysmeta | |
| 20:27:09 | mriedem | ok comments inline | |
| 20:27:23 | dansmith | mriedem: is that one of the tests I pulled out to the cells class in an earlier patch? | |
| 20:27:27 | mriedem | nope | |
| 20:27:28 | mriedem | just looked | |
| 20:27:40 | dansmith | okay | |
| 20:27:59 | mriedem | checking to see if anything else covers that | |
| 20:28:05 | mriedem | we tend to duplicate a lot of our unit tests | |
| 20:30:16 | mriedem | _get_all_instance_metadata is only used by methods that were for the ec2 api | |
| 20:31:03 | mriedem | ec2api repo doesn't call them though | |
| 20:34:07 | dansmith | hmm, got worried for a sec | |
| 20:34:24 | dansmith | baseline was taking 10s instead of 6s from yesterday | |
| 20:34:47 | dansmith | but after the reboot the devstack@dstat.service was consuming two cores for some reason | |
| 20:34:50 | dansmith | hopefully that's why | |
| 20:39:05 | mriedem | ok we return metadata during GET /servers/{server_id} which makes sense, so still need to join on that | |
| 20:39:11 | mriedem | and flavor for flavor, and info_cache for IPs, | |
| 20:39:19 | mriedem | but system_metadata should be able to be nuked from the join in the API | |
| 20:41:07 | mriedem | oh | |
| 20:41:09 | mriedem | geez | |
| 20:41:14 | mriedem | we join on security_groups... | |
| 20:41:25 | mriedem | for no good reason | |
| 20:41:42 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove unused get_all_instance_*metadata methods https://review.openstack.org/508299 | |
| 20:42:43 | mriedem | gmann: Kevin_Zheng: shouldn't JOINED_TABLE_QUERY_PARAMS_SERVERS include 'tags'? | |
| 20:43:32 | dansmith | hrm, still running slow | |
| 20:44:01 | mriedem | if we removed system_metadata from the default join list in the API, if it was used somewhere, we'd see the "lazy-loading ..." message in the API logs though right? | |
| 20:44:58 | dansmith | yes | |
| 20:50:16 | mriedem | gmann: Kevin_Zheng: oh nvm it can't because "tags" is an actual query parameter | |
| 20:50:33 | dansmith | for a single list operation via curl I really shouldn't be hitting keystone more than once right? | |
| 20:50:53 | mriedem | hmmm | |
| 20:51:05 | mriedem | going to neutron? | |
| 20:51:22 | mriedem | we pass the token to neutron and it has to auth? | |