incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject 'traditional' workload patches
Date Tue, 04 Dec 2012 05:53:54 GMT
During the meetings I found that there are a good number of people
attempting to utilize cloudstack with traditional workloads. Alex mentioned
in his final presentation that going forward CloudStack will have better
support for mixed traditional and cloud workloads, but in the mean time
there was interest from some parties in a few additions we've made but not
pushed back into CloudStack. Given all of the rearchitecting going on, I'd
like to get a better idea of if and when I should push to get these
reviewed and implemented.

 I've already attempted to discuss some of these things with mixed
responses, but since a few people asked me about these things and making
them available I thought I'd bring them up again. These are all API calls
we've added to our own branch, along with implementation code.

*resizeVolume*: At this point I think it can probably be pushed into
Edison's storage refactor. If he just adds resizeVolume to his volume
service then the various storage plugins can work on implementing it (or
not) at any time.

These others I've been reticent to discuss too much about pushing back to
master because I don't yet fully understand the implications of doing these
things for all workloads, but they're necessary for ours and so we
implemented them. They revolve around adjusting a VM's network settings
after the fact, which doesn't matter so much for a cloud environment where
a VM's lifecycle is either short or unimportant, but a big deal to people
trying to do more traditional workloads. There were several people who
seemed very interested in this functionality. We'll work with Chiradeep to
understand any pitfalls in these implementations, I just want to get a feel
for whether it's worth doing the work of making patches against master
(they are currently working for 4.0) and adding patches to documentation.

addNicToVirtualMachine: Allows a new NIC to be added to a VM, given a vm id
and a network id.

removeNicFromVirtualMachine: Removes NIC associated with given network id
from given vm. Does not allow removal of default NIC.

updateDefaultNicForVirtualMachine: Changes which NIC should be considered
the default NIC for a VM.

Aside from adding the API calls themselves, they touch UserVmService,
UserVmManagerImpl, VirtualMachineManager to do the additions, removals, but
largely call existing code do do the work (e.g. _networkMgr.createNicForVm,
NicVO.setDefaultNic, etc)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message