Feature pages for 3.2

[Itamar Heim]

On 10/17/2012 07:27 PM, Adam Litke wrote:
> On Wed, Oct 17, 2012 at 06:55:28PM +0200, Itamar Heim wrote:
>> On 10/17/2012 04:41 PM, Adam Litke wrote:
>>> On Wed, Oct 17, 2012 at 02:58:25PM +0200, Itamar Heim wrote:
>>>> On 10/15/2012 04:12 AM, Mike Burns wrote:
>>>>> The 3.2 Release page[1] has a list of features targeted for 3.2.  The
>>>>> majority of the listed features either lack a feature page completely,
>>>>> or a link is missing.  If you are responsible for the component the
>>>>> includes the feature, can you either create or have someone create a
>>>>> feature page?  A template page is available[2].
>>>>>
>>>>> Thanks
>>>>>
>>>>> Mike
>>>>>
>>>>> [1] http://wiki.ovirt.org/wiki/OVirt_3.2_release-management#Features
>>>>> [2] http://wiki.ovirt.org/wiki/Feature_template
>>>>>
>>>>
>>>> Adam,
>>>>
>>>> i see 'libvdsm preview' appears on the list.
>>>> is this based on the current legacy api prototype or the new planned api?
>>>
>>> I am not sure what you mean by "current legacy api prototype".  I am working on
>>> a new JsonRPC based API that is driven by a schema.  libvdsm is client-side C
>>> library with Python bindings that talks to vdsm using the the JsonRPC protocol
>>> according to the API schema.  We do not currently have the Java client generated
>>> and that is still out of scope for 3.2 since no one is actively working on it.
>>>
>>> Hopefully this is enough information but if not please let me know.
>>>
>>
>> for some reason i though there was a phase which used a schema closer to the
>> old xmlrpc api.  my main concern with libvdsm is when it makes 'stable' api.
>> i assume it closely tied to the jsonrpc based api/schema.  so the question is
>> when do we declare it as supported/stable/etc?
>
> Well, the schema is currently very close to the xmlrpc API with some things
> fixed..  We decided that in order for this to become the new supported API
> eventually, it must start out working very similar to the old API.  This will
> allow ovirt-engine to migrate to the new API without a complete rewrite.
>
> By preview, I am thinking we will deliver the API as something for people to try
> out but not make any API stability guarantees yet.  I think we will be able to
> declare it stable once engine starts using it.  My hope is we can move in that
> direction after the 3.2 release but it will take a concerted effort to get it
> done.
>

wouldn't we want two phases before declaring it stable?
1. move the engine to it.
2. refactor api to be cleaner than just resembling the xml/rpc one
(iiuc, the planned api would be much lean/mean than the xml/rpc one?)

thanks,
    Itamar