Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-24
22:08:01 mriedem *scheduler report client
22:08:04 mriedem for disk inventory
22:08:05 bauzas mriedem: but what should we ask to the PlacementAPI if the flavor is 0 ?
22:08:42 bauzas mriedem: eg. https://review.openstack.org/#/c/417961/22/nova/scheduler/filter_scheduler.py@164
22:09:13 mriedem looking at https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L129
22:09:33 mriedem it looks like we wouldn't include the DISK_GB resource class if the flavor is 0 root_gb
22:10:00 mriedem bauzas: yeah what you have in there looks correct
22:10:29 bauzas mriedem: because we don't accept an amount of 0
22:10:33 bauzas in the PlacementAPI
22:11:04 bauzas anyway, my thoughts are: we all agree it's bad to disable those filters
22:11:17 bauzas people should rather use allocation ratios
22:11:28 bauzas and that, we all agreed multiple times in the past
22:12:01 bauzas what I'm advocating is a certain deprecation window for operators
22:12:30 bauzas asking them to make sure they set correct allocation ratios to their computes
22:12:46 bauzas that could be infinite
22:13:03 bauzas that's where I want to be pragmatic
22:13:09 mriedem i personally don't have a problem with that, if we're deprecating the Core/RAM/Disk filters at the same time
22:13:19 mriedem the thing is,
22:13:33 mriedem if we mark those as deprecated, people will probably remove them from their enabled_filters list
22:13:55 mriedem which then gets them into this situation where we don't request VCPU and log a warning saying you don't have the CoreFilter in enabled_filters
22:13:58 mriedem so it gets weird
22:14:03 amrith mriedem, andreykurilin I see that the requirements change has blocked novaclient 7.0.0
22:14:09 amrith is there a new client version coming?
22:14:15 mriedem amrith: working on it
22:14:23 amrith ok, thx mriedem
22:15:26 bauzas mriedem: the fact with those legacy filters is that johnthetubaguy pointed out that CachingScheduler still needs them
22:15:39 bauzas mriedem: so I haven't targeted to deprecate them
22:15:39 mriedem ok so we can't deprecate them,
22:15:47 bauzas exactly
22:16:08 mriedem and if CoreFilter isn't in the enabled_filters list for the filter scheduler, it's going to log a warning?
22:16:22 bauzas why so?
22:16:33 dansmith mriedem: we have to account for swap and ephemeral in DISK_GB, remember..
22:16:36 mriedem because long-term we don't want to rely on that
22:16:52 mriedem bauzas: i'm trying to figure out at what point this becomes an error,
22:16:56 mriedem and how you plan to signal that
22:18:07 bauzas mriedem: I was rather thinking of the contrary
22:18:35 bauzas mriedem: ie. signal that by Pike you shouldn't use the legacy filters *if and only if you run the FilterScheduler*
22:19:36 mriedem which means removing CoreFilter from the enabled_filters list right?
22:19:44 bauzas mriedem: yup
22:20:01 bauzas ideally, deployers should stop having the CoreFilter set by Pike
22:20:09 bauzas unless they use another scheduler driver
22:20:21 mriedem and when you make that a hard requirement, you'll remove any conditional check on the CoreFilter such that you're always requesting VCPU filtering of RPs in the filter scheduler?
22:20:32 bauzas yup
22:21:05 bauzas people in general don't disable all three legacy filters
22:21:14 bauzas so they would still get a warning for at least one
22:21:32 mriedem still,
22:21:33 mriedem "ideally, deployers should stop having the CoreFilter set by Pike"
22:21:49 mriedem so at runtime in Ocata, are you going to log a warning if CoreFilter is in enabled_filters?
22:22:16 bauzas mriedem: that's not part of my change yet but I could do that
22:22:21 mriedem but if you do that,
22:22:36 mriedem it means, 'remove CoreFilter from enabled_filters before pike'
22:22:47 mriedem which also means, you don't get an VCPU filtering with RPs in the filter scheduler
22:22:52 mriedem so it's a catch-22
22:22:58 mriedem s/an/any/
22:22:58 bauzas mmm good point
22:23:08 bauzas lemme reconsider that
22:23:25 bauzas okay, so your option
22:23:43 bauzas within the FilterScheduler, log a warning if one of the 3 filters is disabled
22:24:01 bauzas that's for Ocata
22:24:31 bauzas so people would need to change their ratios for that during Ocata and enable the filter in Ocata
22:25:33 bauzas now, in Pike we would assume that all clouds have those 3 filters enabled and we would remove the conditionals I just wrote
22:26:43 bauzas honestly, I dunno
22:26:57 bauzas maybe it's because it's becoming late to me and my brain is fried
22:27:51 bauzas dansmith: FWIW, devstack uses the flavor #42 which is having both root, ephemeral and swap set to 0
22:28:11 mriedem enabling the filters just to say, 'don't do this b/c we're going to stop caring about them for the filter scheduler' is very weird
22:28:51 bauzas mriedem: I agree, that doesn't sound a great plan
22:29:26 dansmith bauzas: yeah, I know.. I'm not sure what root=0 has to do with this discussion at all
22:30:03 bauzas dansmith: https://review.openstack.org/#/c/417961/22/nova/scheduler/filter_scheduler.py@164
22:30:43 mriedem bauzas: those are different issues,
22:32:41 openstackgerrit Steven Webster proposed openstack/nova: Release PCI devices on drop_move_claim() https://review.openstack.org/370374
22:34:45 mriedem bauzas: given the retarded dance we'd have to come up with just to say this stuff is changing, i think i'd prefer to just always request VCPU/RAM/DISK_GB as outlined in the spec and make it clear in the release notes that if you didn't have those filters enabled before, you need to adjust for that with allocation ratios now before upgrading to ocata
22:34:54 mriedem bauzas: and as dansmith said, we could also work that into the nova-status upgrade check
22:36:14 bauzas mriedem: okay, I then need to hurry up to change a few more things
22:36:36 bauzas and hope nobody won't complain too much
22:37:11 mriedem bauzas: and then reply to the ML thread signing away your consent
22:37:49 bauzas mriedem: tbc, I won't have the bandwidth for the nova-status check
22:38:00 bauzas mriedem: neither me notifying the operators they have to move on
22:38:32 mriedem bauzas: i can do nova-status
22:38:34 bauzas for what I see, I only have 1.5 day left for changing at least a couple of tests
22:38:48 bauzas at least some of the functional tests
22:38:59 bauzas mriedem: you're on vacation, remember :)
22:39:16 bauzas mriedem: well, I don't have a RV for that
22:43:00 mriedem jaypipes: how are things looking for this last patch in the resource classes series? https://review.openstack.org/#/c/404472/
22:43:34 bauzas sooooo, the grenade change didn't help the scheduler change
22:43:41 bauzas I'm depressed
22:44:33 mriedem jaypipes: er i guess it's no longer the last change in the series
22:46:31 bauzas let's be clear, given the grenade problem, I'm not feeling we could merge https://review.openstack.org/#/c/417961 by Ocata
22:46:35 bauzas anyway
22:46:53 bauzas I'll need to bail out for the night or I'm doomed
22:47:29 bauzas so in case folks have a bit of interest about https://review.openstack.org/#/c/417961 and are knowing grenade, feel free to help
22:54:10 andreykurilin stevemar: please, put W-1 at https://review.openstack.org/#/c/424847/1 . It breaks novaclient's gates
22:54:15 andreykurilin :(
22:54:49 andreykurilin it looks like we need to bump openstacksdk and openstackclient versions together
22:55:25 mriedem andreykurilin: reminder on https://review.openstack.org/#/c/418190/ in case you have to use it
22:55:40 stevemar andreykurilin: that'll blow the requirements teams minds
22:55:45 mriedem only thing on ^ is we'd have to cleanup the commit message
22:56:23 stevemar mriedem: fi-lgtm
22:57:02 stevemar andreykurilin: i rebased it, should be bumped out of the gate (don't think it even got that far)
22:57:26 dansmith bauzas: it's not starting the placement api, looks like
22:57:35 dansmith bauzas: I see no placement-api log

Earlier   Later