On Tue, Oct 2, 2018 at 11:40 AM Eric Fried <openst...@fried.cc> wrote:
> > What Eric is proposing (and Julia and I seem to be in favor of), is
> > nearly the same as your proposal. The single difference is that these
> > config templates or deploy templates or whatever could *also* require
> > certain traits, and the scheduler would use that information to pick a
> > node. While this does put some scheduling information into the config
> > template, it also means that we can remove some of the flavor explosion
> > *and* mostly separate scheduling from configuration.
> >
> > So, you'd have a list of traits on a flavor:
> >
> > required=HW_CPU_X86_VMX,HW_NIC_ACCEL_IPSEC
> >
> > And you would also have a list of traits in the deploy template:
> >
> > {"traits": {"required": ["STORAGE_HARDWARE_RAID"]}, "config": <RAID
> blob>}
> >
> > This allows for making flavors that are reasonably flexible (instead of
> > two flavors that do VMX and IPSEC acceleration, one of which does RAID).
> > It also allows users to specify a desired configuration without also
> > needing to know how to correctly choose a flavor that can handle that
> > configuration.
> >
> > I think it makes a lot of sense, doesn't impose more work on users, and
> > can reduce the number of flavors operators need to manage.
> >
> > Does that make sense?
>
> This is in fact exactly what Jay proposed. And both Julia and I are in
> favor of it as an ideal long-term solution. Where Julia and I deviated
> from Jay's point of view was in our desire to use "the hack" in the
> short term so we can satisfy the majority of use cases right away
> without having to wait for that ideal solution to materialize.
>
Ah, good point, I had missed that initially. Thanks. Let's do that.
So if we all agree Jay's proposal is the right thing to do, is there any
reason to start working on a short-term hack instead of putting those
efforts into the better solution? I don't see why we couldn't get that done
in one cycle, if we're all in agreement on it.
// jim
__________________________________________________________________________
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
