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

[Mohammed Morsi]

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.

   -Mo