Feature pages for 3.2

[Itamar Heim]

On 10/17/2012 08:27 PM, Adam Litke wrote:
> On Wed, Oct 17, 2012 at 07:44:10PM +0200, Itamar Heim wrote:
>> 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?)
>
> Yes,  I would definitely be okay with cleaning it up.  As a first pass we could
> remove all currently deprecated APIs, remove unneeded parameters, make
> parameters optional when possible, etc.  I believe HSM is getting an API
> redesign and we could switch to that new API as well.  Saggi and I also
> discussed how we can make VM representations a well organized collection of
> objects (eg. memSize=1024 => vm.append(VmMemoryStick(size=1024)) ).  There are a
> lot of things we could do to reset the API at this stage.
>

but would make more sense to do after moving the engine to the current 
api or we'll never be able to make the migration and test for 
regressions, and then we could refactor both sides.
post 3.2 we need to do some estimations on the effort of changing the 
engine and the post migration changes expected to the API to feel 
"better" about it to be claimed supported.