This sounds great, I would certainly use these enhanced API services for persistent and semi-persistent infra. I can even see potential in elastic situations to at-will modify these instance parameters.
Thanks in advance! I really hope these get added into master. Sent from my iPhone On Dec 3, 2012, at 9:53 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > 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)
