Hi Carsten, Thank you for your feedback. Please find my comments inline:
On Thu, Aug 4, 2011 at 2:23 AM, <carsten.friedr...@csiro.au> wrote: > > Hi, > > Some very interesting and exciting new features. Some initial feedback on > just reading the documentation (didn’t get around to actually trying it yet): > > Please keep the option to have ad-hoc templates. Not being able to > dynamically create templates will break a lot of my current work (and force > me to rewrite my code to register tons of templates that nobody will every > use again). > That functionality is still there for compatibility. VMs can be created just like before, from a template file, using the same commands (onevm create from the CLI, one.vm.allocate from XML-RPC). In the usage guides we assume the only way to create VMs is to register a Template and then instantiate it, but that's because we want to explain the "preferred" usage, the one we supposed is the common use case. The same thing happens with VM Disks and Images. Through all the guides, we assume the Images are registered, and then referenced in the VM template. But you can completely skip the Image repository, and specify a path directly, as was done in OpenNebula 1.4 > > Also, please add more detail to > http://www.opennebula.org/documentation:rel3.0:api: > > It is currently very hard to understand what the parameters for some of the > calls are, e.g. for one.vm.allocate. I assume it is not only session id and > image template. Actually, it should say "resource template", not "image template". But that's it, the method one.vm.allocate takes only those two parameters. > > Does one.vm.savedisk really still take the image name? I thought everything > was moved to ID. The VM and Disk ID are used to reference the object; the name is for the new Image to be created, not to reference an existing Image. > > Is the section headline “Common Methods” to be taken literally (as in there > are also others)? If yes, please have an additional page where all methods > are listed. We tried to merge the commands with the same meaning and parameters, to reduce the immense page. But maybe it was clearer before, and a reference page is expected to be enormous anyway. We still have to work on the documentation, we'll take your suggestion into account. > > Generally it would be great if OpenNebula could become a bit more community > oriented in the sense that upcoming planned changes are announced early and > put up for discussion. The current situation of being at the same time > excited and scared of every new version because I don’t know what it may > break next it not ideal L. > Some major features are driven by projects and organization sponsoring OpenNebula, but new features are always up for discussion in our development portal [1]; and we include in the roadmap the reasonable feature requests made by the community. We also announced the 3.0 roadmap in our blog [2], and then organized two IRC sessions [3,4] to talk about the new features and hear your thoughts and suggestions. And, of course, we are always open to suggestions and feedback in this list. Actually, one of the main incompatibilities from 2.x to 3.0 version is that Images and VNets have to referenced by ID in the VM Templates; and that decision was motivated from a request you made [5]. Again, let me thank all of you that provide us valuable feedback. Carlos. [1] http://dev.opennebula.org/projects/opennebula/issues?query_id=12 [2] http://blog.opennebula.org/?p=1626 [3] http://blog.opennebula.org/?p=1553 [4] http://opennebula.org/community:events [5] http://lists.opennebula.org/pipermail/users-opennebula.org/2010-October/002924.html -- Carlos Martín, MSc Project Major Contributor OpenNebula - The Open Source Toolkit for Cloud Computing www.OpenNebula.org | cmar...@opennebula.org _______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org