<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 25, 2015 at 10:55 AM, Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/25/2015 05:33 PM, Anne Gentle wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On Thu, Jun 25, 2015 at 7:10 AM, Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a><br></span><span class="">
<mailto:<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>>> wrote:<br>
<br>
    On 06/25/2015 04:42 AM, Ken'ichi Ohmichi wrote:<br>
     > 2015-06-25 17:25 GMT+09:00 Lucas Alvares Gomes<br></span>
    <<a href="mailto:lucasagomes@gmail.com" target="_blank">lucasagomes@gmail.com</a> <mailto:<a href="mailto:lucasagomes@gmail.com" target="_blank">lucasagomes@gmail.com</a>>>:<div><div class="h5"><br>
     >> Hi,<br>
     >><br>
     >>> If renaming "Ironic" to the other, is it still necessary to<br>
    keep the<br>
     >>> name in the header?<br>
     >>> There are some projects which are already renamed like Neutron,<br>
    Zaqar<br>
     >>> and the others.<br>
     >>> So "OpenStack-API-Version" which doesn't contain project name seems<br>
     >>> reasonable for me.<br>
     >><br>
     >> I don't think we should make decisions base on those cases,<br>
    these are<br>
     >> exceptions.<br>
     ><br>
     > I don't think so.<br>
     > Renames of projects have already happened too many time even if<br>
    we can<br>
     > say "they are exceptions".<br>
     > In big tent, the renames will happen more.<br>
     ><br>
     >> But even if it happens the name in the header is the least<br>
     >> problematic thing. When a project is renamed, apart from the massive<br>
     >> refactor in the code other things have to change, packaging, service<br>
     >> files, etc...<br>
     ><br>
     > Internal implementation(like packaging, service files, directory<br>
     > structures, etc) is not matter for end users at all.<br>
     > API header is an interface between services to end users.<br>
     > The area of influence of API header is much bigger than the<br>
    implementation.<br>
     ><br>
     > Now I can see the first Jay's point.<br>
     > Yeah, Nova and Ironic are implementations, and we cannot say "The<br>
     > implementation rename never happens." because Neutron has happened.<br>
     ><br>
     >> For the headers you could have both, one with the old<br>
     >> name and one with the new name for a while to give people time to<br>
     >> migrate and then remove the old name. Just like deprecating other<br>
     >> stuff, e.g a configuration option.<br>
     ><br>
     > That seems painful to end users.<br>
     > So what is disagreeing point against "OpenStack-API-Version" here?<br>
<br>
    My concern remains that there is no such thing as an<br>
    OpenStack-API-Version. There is no place to look it up. It's like asking<br>
    for the OpenStack Database Version. This is a construct which is project<br>
    scoped, and makes no sense outside of that project.<br>
<br>
    For someone that's extremely familiar with what they are doing, they'll<br>
    understand that <a href="http://service.provider/compute" rel="noreferrer" target="_blank">http://service.provider/compute</a> is Nova, and can find<br>
    their way to Nova docs on the API. But for new folks, I can only see<br>
    this adding to confusion.<br>
<br>
    Being extra, and possibly redundantly, explicit here eliminates<br>
    confusion. Our API is communication to our users, and I feel like at<br>
    every point we should err on the side of what's going to be the most<br>
    clear under the largest number of scenarios.<br>
<br>
<br>
We already have X-OpenStack-Request-ID as a header in the Compute v2.1<br>
API for helping to track requests and troubleshoot.<br>
<br>
So I agree with Sean that we need to think across more APIs but there is<br>
precedence set for "OpenStack-" as a keyword to look for in responses.<br>
<br>
Also I hadn't discovered X-OpenStack-Nova-API-Version until now -- and I<br>
don't think that we should use project names in end-user-facing<br>
messaging, ever. They then have to do a look up for "nova" among over 20<br>
project names. [1] Since that got unmarked experimental can it be<br>
re-marked experimental?<br>
</div></div></blockquote>
<br>
I'm not sure where the assumption comes from that people will know "compute" better than "nova". </blockquote><div><br></div><div>I have been supporting developer end users on the Rackspace cloud for nearly four years now. I gave a talk in Paris at the Summit about supporting developers. Developers using cloud resources expect to use computing power or storage capacity to accomplish a broader task. Nova and swift have nothing to do with their expectations.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In my experience I've never seen *users* referring to "the baremetal service", which is not surprising for people installing `openstack-ironic-*` packages, then using `ironic` utility or `ironicclient` python module to access the API, while using <a href="http://docs.openstack.org/developer/ironic/" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/ironic/</a> as documentation. We probably should change all of these before we can safely assume that users would prefer "the baremetal service".<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
My suggestion:<br>
<br>
X-OpenStack-Compute-API-Version<br>
X-OpenStack-Containers-API-Version<br>
X-OpenStack-Baremetal-API-Version<br>
X-OpenStack-Blockstorage-API-Version<br>
X-OpenStack-Image-API-Version<br>
X-OpenStack-Identity-API-Version<br>
</blockquote>
<br></span>
The same question as above: what to do with services that do not have a blessed name (e.g. my ironic-inspector)?<br></blockquote><div><br></div><div>This "ironic-inspector" has just come across my path. Can you talk more about what people do with it? Inspect compute nodes for bare metal capability?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
I'm going to get VERY specific about how we name projects and the<br>
service they provide in projects.yaml. We simply cannot put users<br>
through the hell of "what's the boomstick project and why does it not<br>
have a version I need?"<br>
<br>
Anne<br>
<br>
1.<br>
<a href="https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names</a><br>
2.<br>
<a href="https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml" rel="noreferrer" target="_blank">https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml</a><br>
<br>
<br>
<br>
             -Sean<br>
<br>
    --<br>
    Sean Dague<br>
    <a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
    __________________________________________________________________________<br>
    OpenStack Development Mailing List (not for usage questions)<br>
    Unsubscribe:<br>
    <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></span>
    <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><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>
<br>
<br>
<br>
<br>
--<br>
Anne Gentle<br>
Rackspace<br>
Principal Engineer<br>
</span><a href="http://www.justwriteclick.com" rel="noreferrer" target="_blank">www.justwriteclick.com</a> <<a href="http://www.justwriteclick.com" rel="noreferrer" target="_blank">http://www.justwriteclick.com</a>><span class=""><br>
<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>
<br>
</span></blockquote><div class="HOEnZb"><div class="h5">
<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Anne Gentle</div><div>Rackspace</div><div>Principal Engineer</div><div><a href="http://www.justwriteclick.com" target="_blank">www.justwriteclick.com</a></div></div></div>
</div></div>