<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-08-15 12:56 GMT+08:00 Yingxin Cheng <span dir="ltr"><<a href="mailto:yingxincheng@gmail.com" target="_blank">yingxincheng@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hi,</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm concerned with the dependencies between "os-capabilities" library and all the other OpenStack services such as Nova, Placement, Ironic, etc.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Rather than embedding the universal "os-capabilities" in Nova, Cinder, Glance, Ironic services that will introduce complexities if the library versions are different, I'd prefer to hide this library behind the placement service and expose consistent interfaces as well as caps to all the other services. But the drawback here is also obvious: for example, when nova wants to support a new capability, the development will require os-capabilities updates, and related lib version bumps, which is inconvenient and seems unnecessary.</div></div></blockquote><div><br></div><div>+1 for the concern, this is good point. +1 for the hide os-capability behind the placement service and expose consistent interfaces.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">So IMHO, the possible solution is: </div><div class="gmail_extra">* Let each services (Nova, Ironic ...) themselves manage their capabilities under proper namespaces such as "compute", "ironic" or "storage";</div></div></blockquote><div><br></div><div>Actually I think we won't catalog the capabilities by services, we will catalog the capabilities by resource types. Like nova and ironic may share some capabilities, due to they provider compute resource.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">* Let os-capabilities define as few as caps possible that are only cross-project;</div><div class="gmail_extra">* And also use os-capabilities to convert service-defined or user-defined caps to a standardized and distinct form that can be understood by the placement engine. </div><div class="gmail_extra"><br></div></div></blockquote><div><br></div><div>This solution sounds complex for me, you need define the capabilities many different places(in os-capabilities for cross-project caps, in each service for project-only caps), and this may leads to different service define same caps but with own naming. And due to the dependence is a library. When you upgrade the os-capabilities, you have to restart all the services.</div><div><br></div><div>I'm thinking of another solution:</div><div><br></div><div>1. os-capabilities just define the capabilities into the JSON/YAML files.</div><div>2. We expose the capabilities through the REST API of placement engine, this REST API will read the capabilities from the JSON/YAML files defined by os-capabilities.<br></div><div> </div><div>This resolves some problems as below:</div><div>1. your concern, hide the os-capabilities behind one single API</div><div>2. when os-capabilities upgrade, you needn't update all the os-capabilities library for all control nodes. You only need update the os-capabilities for the node running placement engine. Due to the capabilities in the JSON/YAML files, you even needn't restart the placement engine service.</div><div><br></div><div>But yes, this also can be done by glance metadata API.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"></div><div class="gmail_extra"><br></div><div class="gmail_extra">My two cents,</div><div class="gmail_extra">Yingxin</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>
<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>