cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Whitehead <dri...@megahappy.net>
Subject Re: 'traditional' workload patches
Date Tue, 04 Dec 2012 19:01:42 GMT
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 <kelcey@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 <shadowsor@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)
>

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