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