<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 2 Oct 2018 at 17:10, Jim Rollenhagen <<a href="mailto:jim@jimrollenhagen.com">jim@jimrollenhagen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></div></blockquote><div><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I'm still unclear on the ironic side of this. I can see that config of some sort is stored in glance, and referenced upon nova server creation. Somehow this would be synced to ironic by the nova virt driver during node provisioning. The part that's missing in my mind is how to map from a config in glance to a set of actions performed by ironic. Does the config in glance reference a deploy template, or a set of ironic deploy steps? Or does ironic (or OpenStack) define some config schema that it supports, and use it to generate a set of deploy steps?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>// jim</div></div></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>