Hi, I'm too working on the client based on marvin too (https://issues.apache.org/jira/browse/CLOUDSTACK-132), pl. see the comments on the issue so we can collaborate on this. Next thing I want to discuss and work on is the agent for KVM.
Right now if one install agent on KVM; he had to: - Do it manually on all hosts (not scalable unless some provisioning tool, like chef/puppet is used); required installation of dependencies - Upgrade is manual; properties are stored on host; possibility of loss of these files while upgrade (if upgrade/install scenarios are not very well handled) - Developer development is manual and not smooth; if you change something in agent code, you are required to manually setup agent on hosts Proposed agent: - Mgmt server should ssh and setup the agent; in case of Xen, vmops plugin which is written in Python is deployed and used (much easier as they have xapi service and we're just adding one plugin) - Possibly rewrite agent in Python because: * Present agent written in Java, comes with its own baggage, required openjdk etc. * Python is preinstalled on most Linux distros * Writing in Python makes it easy to hack, no hack-build-run loop; just hack-run * Agent can have it's own environment and run in a virtualenv; the present agent required deps etc. which are not local to the agent, but affects the system in general * Can reuse libvirt-python (no virsh), example code I'd written in past; https://github.com/bhaisaab/vmcontroller/blob/master/src/vmcontroller.host/vmcontroller/host/controller/hypervisors/LibVirt.py - Rewriting and throwing away code can be a wild ide, so if we decide to not rewrite it, let's discuss some way to automate agent deployment on hosts and make it easier for developers to work with it Regards. ________________________________________ From: Sebastien Goasguen [run...@gmail.com] Sent: Saturday, October 27, 2012 2:27 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Moving beyond 4.0.0-incubating Hi, *I emailed with James Martin who has been doing some devcloud improvements, I encouraged him to submit his patches even if it's not done. *Prasanna created a marvin-parallel branch to host a threading of the integration tests. I will get back to that after the vote. *There is a request for an interactive shell. I just tried jclouds-cli, it's nice but is far from covering all cloudstack can do. So I am starting a prototype using the marvin cloudstackAPI. *There is also an important thread on a better AWS support with a newer api version. On the more technical front, I think we need to look at network capabilities that are only available with netscaler and provide an open source alternative. Potentially also look at integrating quantum -if you look at it as an open source nicira- -Sebastien On Oct 26, 2012, at 10:07 PM, Edison Su <edison...@citrix.com> wrote: > I am working on the storage subsystem refactor on javelin branch. The code I > write is under platform/storage directory. I'll send out a detailed changes I > want to make in the next few days. > >> -----Original Message----- >> From: Chip Childers [mailto:chip.child...@sungard.com] >> Sent: Wednesday, October 24, 2012 2:57 PM >> To: cloudstack-dev@incubator.apache.org >> Subject: Moving beyond 4.0.0-incubating >> >> Hi all, >> >> Obviously we still have to actually pass a vote, and then pass another >> vote within the IPMC, before we can call success with >> 4.0.0-incubating. (And we may have to do this several more times, >> depending on how things go.) However, I think it's time to catch up >> on work that's ongoing, ideas for what to do next, and to start to >> plan out what our next community goals are. >> >> Along those lines, perhaps we can all start communicating a little >> better about where other work stands? I'd like to ask folks that are >> working on features / tools to kick off discussion threads for their >> specific areas. Questions that would be great to have answered >> include: How's the work going generally? Are there any design >> decisions that should be talked about? Any help needed? >> >> Examples that come to mind (in no order, and not exhaustive): >> >> 1- Adding more plugin capabilities to the core design (I assume this >> is what the javelin branch is for) >> 2- RBAC >> 3 - Event handling / message bus integration >> 4 - DevCloud changes >> 5 - Work demonstrated at Citrix Synergy (Cisco product integrations) >> 6 - Auto-scaling >> 7 - Host deployment feature >> >> I'd also like to ask that we start proposing new features to the list >> again (I know that some of this has continued, but I think it died >> down a bit). It's going to be important to start thinking about >> timing of our next feature release soon (and to be time bound about >> it), so I think we need to ensure that we're all sharing current >> thoughts, status, etc... And as always, feel free to let me know if >> you disagree! >> >> Thanks all, >> >> -chip
