<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-08-16 7:31 GMT+08:00 Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/15/2016 03:57 AM, Alex Xu wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
2016-08-15 12:56 GMT+08:00 Yingxin Cheng <<a href="mailto:yingxincheng@gmail.com" target="_blank">yingxincheng@gmail.com</a><br></span>
<mailto:<a href="mailto:yingxincheng@gmail.com" target="_blank">yingxincheng@gmail.com</a><wbr>>>:<div><div class="h5"><br>
<br>
Hi,<br>
<br>
I'm concerned with the dependencies between "os-capabilities"<br>
library and all the other OpenStack services such as Nova,<br>
Placement, Ironic, etc.<br>
<br>
Rather than embedding the universal "os-capabilities" in Nova,<br>
Cinder, Glance, Ironic services that will introduce complexities if<br>
the library versions are different, I'd prefer to hide this library<br>
behind the placement service and expose consistent interfaces as<br>
well as caps to all the other services. But the drawback here is<br>
also obvious: for example, when nova wants to support a new<br>
capability, the development will require os-capabilities updates,<br>
and related lib version bumps, which is inconvenient and seems<br>
unnecessary.<br>
<br>
<br>
+1 for the concern, this is good point. +1 for the hide os-capability<br>
behind the placement service and expose consistent interfaces.<br>
<br>
<br>
<br>
So IMHO, the possible solution is:<br>
* Let each services (Nova, Ironic ...) themselves manage their<br>
capabilities under proper namespaces such as "compute", "ironic" or<br>
"storage";<br>
<br>
<br>
Actually I think we won't catalog the capabilities by services, we will<br>
catalog the capabilities by resource types. Like nova and ironic may<br>
share some capabilities, due to they provider compute resource.<br>
<br>
<br>
* Let os-capabilities define as few as caps possible that are only<br>
cross-project;<br>
* And also use os-capabilities to convert service-defined or<br>
user-defined caps to a standardized and distinct form that can be<br>
understood by the placement engine.<br>
<br>
<br>
This solution sounds complex for me, you need define the capabilities<br>
many different places(in os-capabilities for cross-project caps, in each<br>
service for project-only caps), and this may leads to different service<br>
define same caps but with own naming. And due to the dependence is a<br>
library. When you upgrade the os-capabilities, you have to restart all<br>
the services.<br>
<br>
I'm thinking of another solution:<br>
<br>
1. os-capabilities just define the capabilities into the JSON/YAML files.<br>
2. We expose the capabilities through the REST API of placement engine,<br>
this REST API will read the capabilities from the JSON/YAML files<br>
defined by os-capabilities.<br>
<br>
This resolves some problems as below:<br>
1. your concern, hide the os-capabilities behind one single API<br>
2. when os-capabilities upgrade, you needn't update all the<br>
os-capabilities library for all control nodes. You only need update the<br>
os-capabilities for the node running placement engine. Due to the<br>
capabilities in the JSON/YAML files, you even needn't restart the<br>
placement engine service.<br>
<br>
But yes, this also can be done by glance metadata API.<br>
</div></div></blockquote>
<br>
Yeah, I think hiding the catalog of constant trait strings behind the placement API is probably a good thing to do.<br>
<br>
However, I envision that os-traits (I'm now calling it this...) will contain some modules for discovery of various traits on a resource provider as well as modules that can detect conflicts in a request for a list of traits. Those modules would clearly be something that various services would want to import, irrespective of the import of the constant trait string catalog.<br></blockquote><div><br></div><div>If we hide the trait strings behind the placement API, there will be an API endpoint for validate the request caps. In nova, we can access this API directly without os-traits.</div><div><br></div><div>One thing I'm not sure yet, we have different virt dirvers for different hypervisors, so whether all the virt drivers have same dependence between traits. For example, hyperV have gen1 and gen2 which support different caps, there are some caps are conflicts between gen1 and gen2. But maybe in another hypervisor, those caps aren't conflicts ether other. But I didn't find out a real use-case yet. I need dig into more.</div><div><br></div><div>There are two solutions in my mind</div><div>1. There aren't different dependence for traits, that is easy. The validation API in the placement engine API is enough.</div><div>2. There are different dependence for traits. We need API for compute node report those dependence. This isn't easy, we need model the dependence in the placement engine. This sounds like Chris will hate this way :)</div><div><br></div><div>Anyway I need to dig into more.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thoughts?<span class="HOEnZb"><font color="#888888"><br>
-jay</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>