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 <[email protected]> IBM Linux Technology Center _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
