I'd like to see these and other API functions made available in the GUI.
On Mon, Dec 3, 2012 at 10:38 PM, Kelceydamage@bbits <kel...@bbits.ca> wrote: > 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) >
