Feature pages for 3.2

[Adam Litke]

On Wed, Oct 17, 2012 at 08:33:21PM +0200, Itamar Heim wrote:
> 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.

Agreed.  One thing that may help is if we can generate a POC java binding
(perhaps just for a single API) and we could see how easily that new API can be
used from engine.  Since engine has a vdsBroker, hopefully most of the affected
engine code would be in one place.

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