| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-28 | |||
| 19:06:04 | mriedem | or, is cern actually migrating to cells v2 | |
| 19:06:16 | mriedem | i saw something the other day saying they were upgrading glance to pike | |
| 19:06:19 | mriedem | maybe that's just glance> | |
| 19:06:20 | mriedem | ? | |
| 19:06:27 | tssurya | mriedem : yes its just glance | |
| 19:06:31 | mriedem | gah! | |
| 19:06:37 | tssurya | mriedem : nova is still on newton | |
| 19:06:59 | mriedem | is that because of the complications with migrating nova to ocata? | |
| 19:07:01 | sean-k-mooney | tssurya: so cern is migrating to cellsv2 now also | |
| 19:07:04 | tssurya | mriedem : however we will soon upgrade to cells v2 :) | |
| 19:07:24 | mriedem | tssurya: ok, i hope there will be copious amounts of blog posts and such on what the plan was and how it goes | |
| 19:07:56 | tssurya | mriedem , sean-k-mooney : yes belmiro is about to come up with a plan for doing this soon | |
| 19:08:20 | sean-k-mooney | mriedem: we are waiting for cern to fully migrate to cellsv2 before removing cellsv1 and nova networks correct | |
| 19:08:33 | dansmith | not just cern | |
| 19:08:45 | dansmith | until pike it wasn't even a possibility for multiple cells, | |
| 19:09:24 | mriedem | sean-k-mooney: at the ptg we said if we have dan's efficient instance list stuff in queens, we remove cells v1 and nova-net in rocky | |
| 19:09:28 | dansmith | and many will have issues with multiple cells until queens | |
| 19:09:30 | sean-k-mooney | well yes but as the bigest user of cells they are a good litmus test that such a migration works at scale | |
| 19:09:31 | mriedem | and we're on a good path to doing that | |
| 19:10:21 | sean-k-mooney | mriedem: ah ok. part of my interest is there is some legacy nova network datamodels in os-vif | |
| 19:10:26 | sean-k-mooney | https://bugs.launchpad.net/os-vif/+bug/1720175 | |
| 19:10:27 | openstack | Launchpad bug 1720175 in os-vif "Move "ips" field from Subnet object to VIF object" [High,Triaged] | |
| 19:10:27 | dansmith | sean-k-mooney: get in line :) | |
| 19:10:56 | sean-k-mooney | currently nothing uses it but its from when we imported the network models for nova | |
| 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 | |