| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-28 | |||
| 18:48:07 | mriedem | yup, the issue is that https://review.openstack.org/#/c/458537/ isn't aware of grenade being singleconductor | |
| 18:48:27 | mriedem | because, jesus, live migration + grenade + superconductor...crazy | |
| 18:52:05 | sean-k-mooney | so the fix is the run nova-compute with /etc/nova/nova-cpu.conf ? | |
| 18:52:38 | mriedem | no | |
| 18:55:29 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix live migration grenade ceph setup https://review.openstack.org/508271 | |
| 18:55:30 | mriedem | i think this is the fix ^ | |
| 18:58:04 | sean-k-mooney | hum that should work however it may be better to always use a seperate config for nova compute so that it does not chage regardless of the config. | |
| 18:58:09 | mriedem | i don't think zuul is running any jobs right now though so, i guess we'll find out later | |
| 18:58:33 | mriedem | sean-k-mooney: oh i'm sure this is air tight and will never require changes again :) | |
| 18:58:52 | sean-k-mooney | :) | |
| 18:59:25 | sean-k-mooney | by the way https://github.com/openstack/nova/search?utf8=%E2%9C%93&q=TODO%28+Queens&type= that was not the only todo with remove in queens ... | |
| 19:00:37 | sean-k-mooney | stephenfin: i belive this one is all yours https://github.com/openstack/nova/blob/762c89f85a4aeceb7bed5e80edc70a239872b757/nova/cmd/manage.py#L141 | |
| 19:01:04 | tssurya | mriedem, dansmith, melwitt : random off-topic : saw the nova cellv2 meeting logs from yesterday, so sorry I could not attend (was afk due to bad time zone timings) it and for wasting some precious seconds during the meeting; but thanks for the ping. Also from next time I will keep you posted earlier on if I am not attending. | |
| 19:01:31 | sean-k-mooney | wait i just confused myself queens comes after pike... | |
| 19:01:44 | dansmith | tssurya: not a problem and no need to keep us notified of your schedule, I just made a point of pinging you because we had fooled you with our hangout the week prior | |
| 19:02:05 | melwitt | no worries tssurya. yep, what dansmith said | |
| 19:02:55 | tssurya | dansmith, melwitt : cool :) thanks! | |
| 19:05:03 | mriedem | tssurya: i got to thinking, | |
| 19:05:09 | mriedem | cern is upgrading to pike right now right? | |
| 19:05:14 | mriedem | and cells v2 was required in ocata, | |
| 19:05:34 | mriedem | so it would be nice if you could give us some info on how cern upgraded to ocata and rolled out cellsv2 even though they are using cells v1 | |
| 19:05:47 | mriedem | like, was cern in ocata just a single giant cells v2 cell? | |
| 19:06:03 | tssurya | mriedem : no cern is still on newton, it is going to upgrade to ocata | |
| 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 | dansmith | sean-k-mooney: get in line :) | |
| 19:10:27 | openstack | Launchpad bug 1720175 in os-vif "Move "ips" field from Subnet object to VIF object" [High,Triaged] | |
| 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 | |