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

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

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
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.

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).


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