Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-24
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
22:57:38 stevemar andreykurilin: how would bumping OSC min solve the issue?
22:58:00 andreykurilin mriedem: but why we have multiple networks with latest openstacksdk and do not have them with old version?
22:59:38 mriedem andreykurilin: because the sdk broke the filtering on available networks :)
22:59:47 andreykurilin mriedem: oh
23:00:00 mriedem at least i think that's what kevinbenton found when he looked at that issue before
23:00:18 mriedem his notes are in that patch
23:00:20 stevemar andreykurilin: mriedem can we just get the nova functional tests working with the newer version?
23:00:31 andreykurilin mriedem: can you update commit message?
23:00:40 stevemar i guess that's what https://review.openstack.org/#/c/418190/ does
23:00:45 mriedem stevemar: well shouldn't that be a major version bump on the sdk?
23:01:06 stevemar mriedem: they have a stance that since they are pre 1.0 they are allowed to break compatibility
23:02:09 stevemar mriedem: like how gmail was in beta for a decade
23:02:32 mriedem stevemar: jesus h c
23:02:38 stevemar osc and senlinclient *need* the latest version
23:02:39 bauzas dansmith: roger, I'll try to investigate tomorrow morning but I'm just exhausted
23:02:40 mriedem well they should shit or get off that pot
23:02:40 andreykurilin stevemar: I'm ok to merge mriedem fix for our gates and then look at the process of merging g-r update. I do not want to see g-r update at first, since we need to merge one patch before cutting new release
23:02:50 andreykurilin heh
23:02:57 stevemar mriedem: soon (tm)
23:03:04 stevemar andreykurilin: i would looove that

Earlier   Later