On 1/24/2017 2:38 PM, Sylvain Bauza wrote:
It's litterally 2 days before FeatureFreeze and we ask operators to change their cloud right now ? Looks difficult to me and like I said in multiple places by email, we have a ton of assertions saying it's acceptable to have not all the filters. -Sylvain
I'm not sure why feature freeze in two days is going to make a huge amount of difference here. Most large production clouds are probably nowhere near trunk (I'm assuming most are on Mitaka or older at this point just because of how deployments seem to tail the oldest supported stable branch). Or are you mainly worried about deployment tooling projects, like TripleO, needing to deal with this now?
Anyone upgrading to Ocata is going to have to read the release notes and assess the upgrade impacts regardless of when we make this change, be that Ocata or Pike.
Sylvain, are you suggesting that for Ocata if, for example, the CoreFilter isn't in the list of enabled scheduler filters, we don't make the request for VCPU when filtering resource providers, but we also log a big fat warning in the n-sch logs saying we're going to switch over in Pike and that cpu_allocation_ratio needs to be configured because the CoreFilter is going to be deprecated in Ocata and removed in Pike?
[1] https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/resource-providers-scheduler-db-filters.html#other-deployer-impact
-- Thanks, Matt Riedemann __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
