[one-users] Some feedback on the 3.0 Beta: Please keep ad-hoc templates for VMs

[Carlos Martín Sánchez]

Hi Carsten,

Thank you for your feedback. Please find my comments inline:

On Thu, Aug 4, 2011 at 2:23 AM, <Carsten.Friedrich at 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 | cmartin at opennebula.org