On 1/24/2017 2:57 PM, Matt Riedemann wrote:
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
To recap the discussion we had in IRC today, we're moving forward with
the original plan of the *filter scheduler* always requesting VCPU,
MEMORY_MB and DISK_GB* regardless of the enabled filters. The main
reason being there isn't a clear path forward on straddling releases to
deprecate or make decisions based on the enabled filters and provide a
warning that makes sense.
For example, we can't deprecate the filters (at least yet) because the
*caching scheduler* is still using them (it's not using placement yet).
And if we logged a warning if you don't have the CoreFilter in
CONF.filter_scheduler.enabled_filters, for example, but we don't want
you to have it in that list, then what are you supposed to do? i.e. the
goal is to not have the legacy primitive resource filters enabled for
the filter scheduler in Pike, so you get into this weird situation of
whether or not you have them enabled or not before Pike, and in what
cases do you log a warning that makes sense. So we agreed at this point
it's just simpler to say that if you don't enable these filters today,
you're going to need to configure the appropriate allocation ratio
configuration option prior to upgrading to Ocata. That will be in the
upgrade section of the release notes and we can probably also work it
into the placement devref as a deployment note. We can also work this
into the nova-status upgrade check CLI.
*DISK_GB is special since we might have a flavor that's not specifying
any disk or a resource provider with no DISK_GB allocations if the
instances are all booted from volumes.
--
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
