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

[Perry N. Myers]

Mohammed Morsi wrote:
> Scott Seago wrote:
>> Chris Lalancette wrote:
>>> Scott Seago wrote:
>>>  
>>>> Yeah -- we need to do them in the same place. As it is with this
>>>> patch, there's a bit of a race condition if you edit a vm right
>>>> after creating (but before taskomatic executes create_vm).
>>>> Originally I'd made the decision to put the system create in
>>>> taskomatic, since that's where all the other action-oriented bits
>>>> that call out to external servers are handled. It's probably not
>>>> that big a deal either way though, as we're already making cobbler
>>>> calls from the WUI to get the profile list.
>>>>
>>>> But yes, we need to either put both of these calls in taskomatic or
>>>> gut create_vm and put both in the WUI. My original preference here
>>>> was for taskomatic to handle it, but the reprovision case makes that
>>>> much more complex (since we'd need a new task type, etc), so maybe
>>>> it makes more sense to do it all in the WUI.
>>>>
>>>> Any other opinions on this?
>>>>     
>>> Not an opinion (since I don't really care where it's done, as long as
>>> it is
>>> consistent), but a fact: in theory the cobbler stuff could hang up
>>> the WUI if
>>> there are network issues.  If you do something like:
>>>
>>> iptables -A INPUT -p tcp --dport <cobbler_port> -j DROP
>>>
>>> on the cobbler server to simulate a network outage, then try to
>>> connect to it
>>> remotely, you will hang up for quite a while TCP attempts to
>>> connect.  It's one
>>> reason to slightly prefer taskomatic to do it, but it may not be
>>> compelling
>>> enough.  I just thought I would point it out.
>>>
>>>   
>> On the other hand, we're already getting the profile list on the WUI
>> -- the above problem will affect the WUI anyway unless we also
>> generate the cobbler profile list on the back end. Now we may
>> eventually have to do this anyway if we ever want to define
>> per-profile access control -- but as things stand now, just doing the
>> cobbler system bit in taskomatic doesn't completely eliminate the
>> cobbler connectivity issue for the WUI.
>>
>> Scott
> It seems the best / most flexible way for future requirements would be
> to move all the cobbler calls out to task-o-matic, and setup some
> caching system so as to not to run into the wui being hung up when
> cobbler cannot be reached (for both setting and getting the profile).
> Unfortunately, this requires significant design decisions early on,
> including how and when we should cache, managing discrepancies (what if
> the user picks a cobbler item from the local cache that has since been
> deleting from the server), and semi-major model changes / additions, all
> of which is out of the scope of this vm re-provisioning requirement.
> 
>  It seems to me that this should all become a separate requirement for
> future development, and currently we can leave the implementation as is,
> or move the bits setting the cobbler profile from task-o-matic into the
> wui for the time being for consistency. I don't think the whole
> create_vm process needs to be gutted from task-o-matic, simply the
> portions involving cobbler if we go that route. After this component is
> checked off, then we can tackle the issues and design considerations of
> integrating cobbler with task-o-matic and the cobbler cache with the wui.

I somewhat agree with you here...  In that the long term solution should 
be future development.

However, for the short term solution, leave the create_system stuff in 
Taskomatic that is associated with the create_vm action since that should 
logically be done by Taskomatic when it is ready do to that action.

Pulling the cobbler profile/image list can stay in the WUI as we don't 
need a separate taskomatic request for that.

Editing the VM to reprovision it does require a Taskomatic task since the 
VM definition needs to be redefined (i.e. the boot method needs to be 
changed from hd to net or cdrom).  So the act of reprovisioning should 
result in a taskomatic task that also creates a new system (or edits the 
old system depending on how the cobbler Ruby API works).

Perry