<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Oct 1, 2018 at 6:38 PM Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/01/2018 06:04 PM, Julia Kreger wrote:<br>
> On Mon, Oct 1, 2018 at 2:41 PM Eric Fried <openstack@fried.cc> wrote:<br><br><snip> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> That said, what if it was:<br>
> <br>
> openstack config-profile create --name BOOT_MODE_UEFI --json -<br>
> {<br>
> "type": "boot_mode_scheme",<br>
> "version": 123,<br>
> "object": {<br>
> "boot_mode": "uefi"<br>
> },<br>
> "placement": {<br>
> "traits": {<br>
> "required": [<br>
> "BOOT_MODE_UEFI"<br>
> ]<br>
> }<br>
> }<br>
> }<br>
> ^D<br>
> <br>
> And now you could in fact say<br>
> <br>
> openstack server create --flavor foo --config-profile BOOT_MODE_UEFI<br>
> <br>
> using the profile name, which happens to be the same as the trait name<br>
> because you made it so. Does that satisfy the yen for saying it once? (I<br>
> mean, despite the fact that you first had to say it three times to get<br>
> it set up.)<br>
> <br><snip><br>
> <br>
> I feel like it might be confusing, but totally +1 to matching required <br>
> trait name being a thing. That way scheduling is completely decoupled <br>
> and if everything was correct then the request should already be <br>
> scheduled properly.<br>
<br>
I guess I'll just drop the idea of doing this properly then. It's true <br>
that the placement traits concept can be hacked up and the virt driver <br>
can just pass a list of trait strings to the Ironic API and that's the <br>
most expedient way to get what the 90% of people apparently want. It's <br>
also true that it will add a bunch of unmaintainable tribal knowledge <br>
into the interface between Nova and Ironic, but that has been the case <br>
for multiple years.<br>
<br>
The flavor explosion problem will continue to get worse for those of us <br>
who deal with its pain (Oath in particular feels this) because the <br>
interface between nova flavors and Ironic instance capabilities will <br>
continue to be super-tightly-coupled.<br>
<br>
For the record, I would have been happier if someone had proposed <br>
separating the instance configuration data in the flavor extra-specs <br>
from the notion of required placement constraints (i.e. traits). You <br>
could call the extra_spec "deploy_template_id" if you wanted and that <br>
extra spec value could have been passed to Ironic during node <br>
provisioning instead of the list of placement constraints (traits).<br>
<br>
So, you'd have a list of actual placement traits for an instance that <br>
looked like this:<br>
<br>
required=BOOT_MODE_UEFI,STORAGE_HARDWARE_RAID<br>
<br>
and you'd have a flavor extra spec called "deploy_template_id" with a <br>
value of the deploy template configuration data you wanted to <br>
communicate to Ironic. The Ironic virt driver could then just look for <br>
the "deploy_template_id" extra spec and pass the value of that to the <br>
Ironic API instead of passing a list of traits.<br>
<br>
That would have at least satisfied my desire to separate configuration <br>
data from placement constraints.<br>
<br>
Anyway, I'm done trying to please my own desires for a clean solution to <br>
this.<br></blockquote><div><br></div><div>Jay, please don't stop - I think we aren't expressing ourselves well, or you're missing something, or both. I understand this is a frustrating conversation for everyone. But I think we're making good progress on the end goal (whether or not we do an intermediate step that hacks on top of traits). We all want a clean solution to this.</div><div><br></div><div>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.</div><div><br></div><div>So, you'd have a list of traits on a flavor:</div><div><br></div><div>required=HW_CPU_X86_VMX,HW_NIC_ACCEL_IPSEC</div><div><br></div><div>And you would also have a list of traits in the deploy template:</div><div><br></div><div>{"traits": {"required": ["STORAGE_HARDWARE_RAID"]}, "config": <RAID blob>}</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Does that make sense?</div><div><br></div><div>// jim</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best,<br>
-jay<br>
<br>
__________________________________________________________________________<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></div>