Feature pages for 3.2

[Adam Litke]

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.

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center