[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Ovirt-devel] [PATCH] added ability to reprovision vm via edit vm form



Perry N. Myers wrote:
> Scott Seago wrote:
>> Mohammed Morsi wrote:
>>> ---
>>>  wui/src/app/controllers/vm_controller.rb |   29
>>> +++++++++++++++++------------
>>>  wui/src/app/views/vm/_form.rhtml         |    2 +-
>>>  2 files changed, 18 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/wui/src/app/controllers/vm_controller.rb
>>> b/wui/src/app/controllers/vm_controller.rb
>>> index e55ec28..6d32427 100644
>>> --- a/wui/src/app/controllers/vm_controller.rb
>>> +++ b/wui/src/app/controllers/vm_controller.rb
>>> @@ -267,6 +271,7 @@ class VmController < ApplicationController
>>>      @perm_obj = @vm.vm_resource_pool
>>>      @redir_obj = @vm
>>>      @current_pool_id= perm_obj id
>>> +    _setup_provisioning
>>>    end
>>>    def pre_vm_action
>>>      pre_edit
>>> diff --git a/wui/src/app/views/vm/_form.rhtml
>>> b/wui/src/app/views/vm/_form.rhtml
>>> index 60ed003..0dfe940 100644
>>> --- a/wui/src/app/views/vm/_form.rhtml
>>> +++ b/wui/src/app/views/vm/_form.rhtml
>>> @@ -8,7 +8,7 @@
>>>  <%= hidden_field_tag 'hardware_pool_id', @hardware_pool.id if
>>> @hardware_pool %>
>>>  
>>>      <%= text_field_with_label "Name:", "vm", "description",
>>> {:style=>"width:250px;"}  %>
>>> -    <%= select_with_label "Operating System:", 'vm',
>>> 'provisioning_and_boot_settings', @provisioning_options,
>>> :style=>"width:250px;"  if create %>
>>> +    <%= select_with_label "Operating System:", 'vm',
>>> 'provisioning_and_boot_settings', @provisioning_options,
>>> :style=>"width:250px;" %>
>>>      <div class="clear_row" style="height:15px;"></div>
>>>  
>>>      <div class="form_heading">Resources</div>
>>>   
>>
>> The UI needs to make it clear that changing the provisioning bits on
>> a running VM will potentially wipe the contents of the current VM and
>> reprovision from scratch. In addition, if the VM is currently
>> running, should we provide the user an easy way to force an immediate
>> reboot (so the provisioning can take effect). Currently we have a
>> 'start VM now' button for creating VMs -- maybe for edit, we should
>> provide the option to start/restart VM now.
>
> This is not always the case... This new UI for changing the
> provisioning could also be used to 'boot a rescue ISO' or something
> like that.  In which case it's not going to blow away your existing
> disk.  A rescue ISO in cobbler looks the same as an F9 install ISO...
>
>> Also, we need to be careful in how we handle the boot device and
>> cobbler profile fields. Currently cobbler profile is only set on
>> create -- so the above won't actually register a new cobbler system
>> (and what of the old cobbler system -- do we need to un-register it?
>> There's also the automatic update of the boot device on successful
>> boot -- I don't think the above will cause any problems with that
>> though.
Correct me if I'm wrong but upon submitting the edit vm form, vm.save!
is invoked after which if you look at the database you will see the
'boot device' is updated and the 'provisioning' field is set to the
correct cobbler profile. I'm not sure why we would have to unregister it
(as opposed to just overwriting what profile is used), is there some
reason why we should? (perhaps another system can't use the cobbler
profile until its unregistered?)


>
> Maybe we should treat editing the provisioning information as a create
> call.  i.e. if you change the VM in this way it removes the exising vm
> and creates a new one.  Would that work?
I'm not a huge fan of deleting / recreating as we have the need of
history (for graphing and what not) and this might throw a monkey wrench
into how we track that, eg we'd have to retain the old vm to lookup
information about it and what not.


>
> If unregistration of a system is necessary we should make that happen
> in the create call in taskomatic for ALL creates.  i.e. whenever
> create is called it should first try to delete the system record in
> cobbler (and fail silently if that record does not exist) and then
> create a new one.
>
> That will handle the reprovisioning case.
>
> Perry

Just to make everything perfectly clear you are looking for the
following additional requirements to be satisfied is addition to whats
already there
1. On editing a vm, if a different boot device / provisioning method is
selected, display a confirmation dialog that this _might _ overwrite the
current vm if the user is not careful. Clicking 'ok' should cause the
app to proceed as normal, clicking cancel should take the user back to
the edit vm form.
2. When editing a vm, if it is stopped, provide the 'start now'
checkbox, and if it is running provide a 'restart now' checkbox.
Clicking either will register the appropriated event in the tasks table
for task-o-matic to pick up.
3. If neccessary (pending questions above) perform additional steps to
unregister / register cobbler profile for edited vm (besides just
writing to the 'boot device' and 'provisioning' fields of the vm table,
what else needs to be done for this? a new task in the tasks table?)

  -Mo


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]