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