<div dir="ltr">Hi,<div><br></div><div>I have two questions that previously were briefly discussed. Both of them still cause discussions within advanced services community, so I'd like to make final clarification in this email thread.</div>
<div><br></div><div>1. Usage of "Service Type Framework"</div><div>I think right now there is a consensus that letting user to choose a vendor is not what neutron should do. To be more specific, having public 'provider' attribute on a resource may create certain problems </div>
<div>for operators because it binds resource and implementation too tightly that it can't be maintained without changing user configuration.</div><div>The question that was discussed is if it's ok to remove this public attribute and still use the rest of framework?</div>
<div>I think the answer is yes: the binding between resource and implementing driver is ok if it's read-only and visible only to admin. This still serves as hint for dispatching requests to driver and also may help operator to troubleshoot issues.</div>
<div>I'd like to hear other opinions on this because there are patches for vpn and fwaas that use STF with the difference described above.</div><div><br></div><div>2. Choosing implementation and backend </div><div>This topic was briefly touched at design session dedicated to flavors.<br>
</div><div><br></div>
<div>Current proposal that was discussed on advanced services meetings was to employ 2-step scheduling as described in the following sample code:</div><div><a href="https://review.openstack.org/#/c/83055/7/neutron/tests/unit/test_flavors.py" target="_blank">https://review.openstack.org/#/c/83055/7/neutron/tests/unit/test_flavors.py</a> line 38-56<br>

</div><div><br></div><div>In my opinion the proposed way has the following benefits:</div><div>- it delegates actual backend choosing to a driver. </div><div>This way different vendors may not be required to agree on how to bind resource to a backend or any kind of other common implementation stuff that usually leads to lots of discussions.</div>
<div>- allows different configurable vendor-specific algorithms to be used when binding resource to a backend<br></div><div>- some drivers don't have notion of a backend because external entities manage backends for them</div>
<div><br></div><div>Another proposal is to have single-step scheduling where each driver exposes the list of backends</div><div>and then scheduling just chooses the backend based on capabilities in the flavor.</div><div><br>
</div><div>I'd like to better understand the benefits of the second approach (this is all implementation so from user standpoint it doesn't make difference)</div><div><br></div><div>So please add your opinions on those questions.</div>
<div><br></div><div>My suggestion is also to have a short 30 min meeting sometime this or next week to finalize those questions. There are several patches and blueprints that depend on them.</div><div><br></div><div>Thanks,</div>
<div>Eugene.</div></div>