<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 16, 2013 at 9:46 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On 05/16/2013 08:18 PM, Andrew Laski wrote:<br>
> On 05/16/13 at 10:27am, Russell Bryant wrote:<br>
>> On 05/16/2013 10:11 AM, Andrew Laski wrote:<br>
>>> On 05/14/13 at 09:18am, Christopher Yeoh wrote:<br>
>>>> <snip><br>
>>>> In a closely related issue there is also a blueprint covering promoting<br>
>>>> APIs to core and vice-versa and we'll need to get a consensus around<br>
>>>> this as well, so if anyone has any suggestions, please make them.<br>
>>><br>
>>> I'm assuming that core means on by default, and guaranteed to be on<br>
>>> because there's some enforcement of it being loaded. If this is not the<br>
>>> case then disregard the rest of this post, but if it is I would like to<br>
>>> propose an alternative.<br>
>>><br>
>>> Since everything will essentially be an extension in v3 what if core was<br>
>>> just the default configuration value for extensions that should be<br>
>>> loaded. And there would be nothing preventing them from being turned<br>
>>> off through configuration.<br>
>><br>
>> I really think we should force a base API to be present. We can do our<br>
>> users a huge favor by setting a core API that is *always* present, and<br>
>> that will always work in a consistent manner, assuming a reasonably<br>
>> capable compute driver is in use. This is how we ensure a base level of<br>
>> consistency among all OpenStack clouds.<br>
><br>
> I'm actually not against this. But if there's a forced API I think it<br>
> should be somewhat minimal. And promotion to core might occur because<br>
> some functionality is deemed fairly essential to Nova, not necessarily<br>
> because it's popular.<br>
<br>
</div></div>Agreed, though all things essential to Nova are also likely to be<br>
popular. :-)<br>
<div class="im"><br>
> And I think consistency can be enforced by refstack and trademark<br>
> guidelines, and doesn't necessarily need to be enforced by Nova.<br>
<br>
</div>I definitely do not want to punt this problem to the board of directors.<br>
I think setting some baseline of consistency is a technical issue and<br>
should be exclusively handled by the technical community.<br>
<div class="im"><br>
> More than anything I just want to have the conversation about what core<br>
> means, which is always a heated topic in this community. I have my own<br>
> opinion on it but really I would like to see us all to be on the same<br>
> page when making decisions about what should or should not be core,<br>
> whatever page that is.<br>
<br>
</div>+1, definitely important to have this well defined before v3 is finalized.<br>
<div class=""><div class="h5"><br>
--<br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>FWIW this is exactly the question that I brought up a couple weeks back and I have some very strong opinions on. I honestly believe that there should be *core* (for lack of a better term) API for each project and it should be expected that the functionality/calls in that API should just work (regardless of how they're implemented and whether it's efficient or not). <br>
<br>The stance I've taken in the Cinder project is that there's a core set of functionality [1], each driver submitted to Cinder needs to be able to provide this level of functionality. There may be exceptions, grace periods for folks to catch up etc, but really it seems like a horrible end-user experience to make an API call and get things like "Not Implemented" one time and then not the next just by luck of the draw from the scheduler and which back-end driver happened to be selected. This sort of defeats the purpose in my opinion.<br>
<br></div><div class="gmail_extra">Anyway, I agree with Russell, this is most definitely a Technical Community issue and I would hope that we can reach an agreement on this without too much difficulty. I know that on the Cinder side I think we've finally all agreed that this is a good thing and we're all more or less willing to implement it and keep it updated. We're at least trying it for another cycle and I hope that it stands.<br>
<br>[1] <a href="https://wiki.openstack.org/wiki/Cinder#Minimum_Driver_Features">https://wiki.openstack.org/wiki/Cinder#Minimum_Driver_Features</a><br><br></div><div class="gmail_extra">Thanks,<br></div><div class="gmail_extra">
John<br></div></div>