An example of how to avoid Java can be found in the Hyper-V agent. Hyper-V experts tend to know C# better than Java, so hypervisor control is through an agent on the hypervisor written in C#. To avoid porting the message bus, communications are over HTTP Request. To avoid porting the command and answer objects, the agent uses weak typing. Data is left in JSON container objects.
DL > -----Original Message----- > From: Koushik Das [mailto:koushik....@citrix.com] > Sent: 17 October 2013 16:39 > To: <dev@cloudstack.apache.org> > Subject: Re: Cloudstack collab Hackathons > > Agree with Marcus here. > If we are planning to rewrite, I think that there should be some discussion > around the possibility of making it a direct agent like XS/Vmware. If this is > possible then installing the KVM agent on individual hosts will be eliminated. > > > On 17-Oct-2013, at 8:49 PM, Marcus Sorensen <shadow...@gmail.com> > wrote: > > > I'm not at all against it, I just haven't heard anyone give any reason > > as to why. Keep in mind that we'd essentially be asking anyone who > > has written code for the agent to re-do their work (midonet, vxlan, > > storage plugins). My impression is that people just like the 'feel' > > of it being in Python, and for good reason, but that ignores the fact > > that 1) we've already done the work, and 2) features still require > > java knowledge since the agent doesn't do anything the mgmt server > > doesn't ask for. Without anyone explaining why, it just sort of feels > > like rearranging deck chairs on a boat with serious leaks going on > > below deck. Worse, people brought their own chairs, and we threw them > > overboard because they're now the wrong color. > > > > On Wed, Oct 16, 2013 at 6:54 PM, Darren Shepherd > > <darren.s.sheph...@gmail.com> wrote: > >> +1 for kvm in python. I'd like to take it a step further. I'd like to > >> create a > framework for adding compute and storage with python drivers. The first > implementation should just happen to be libvirt/kvm. So yeah, I'll be > interested in this. I'll be landing around 10am so don't know what time I'll > get > to the hackathon. > >> > >> Darren > >> > >>> On Oct 14, 2013, at 9:29 AM, Marcus Sorensen <shadow...@gmail.com> > wrote: > >>> > >>>> On Mon, Oct 14, 2013 at 8:22 AM, Sebastien Goasguen > <run...@gmail.com> wrote: > >>>> > >>>>> On Oct 11, 2013, at 4:43 AM, Hugo Trippaers <trip...@gmail.com> > wrote: > >>>>> > >>>>> Hey Guys, > >>>>> > >>>>> The CloudStack collaboration conference is right around the corner. > The first day of the conference will be dedicated to workshops and a > hackathon. > >>>>> > >>>>> I'm curious which developers are planning to attend the hackthon and > what subjects you are interested in. In Santa Clara we had a short list of > some > subjects to discuss and some tables and discussions were already prepared in > advance. In the upcoming conference we can do the same, so if you have a > discussion or project idea that you want to work on at the hackthon let us > know with a reply in this thread. > >>>>> > >>>>> I'm also curious if there are any aspiring developers that would like to > have a sort of introduction into cloudstack development during the > hackathon. > >>>>> > >>>>> If you have any other ideas, just shout. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Hugo > >>>> > >>>> I am adding couple topics that I would like to see: > >>>> > >>>> -API interfaces (AWS refactor, GCE, OCCI&CIMI standard): Discuss the > state of our interfaces, plans for future, needs etc. AWS interface might > need a refactor, GCE is a new interface, OCCI is a standard and Isaac Chiang > has developed an interface. We are missing a CIMI interface. > >>>> > >>>> -DOCs: We are having lots of talks about docs, they have been split in a > separate repo, we need to discuss format, release life cycle, format etc. > >>>> > >>>> -KVM agent: There has been discussions/wishes to re-write the KVM > >>>> agent in something else than Java. Review architecture, define a > >>>> plan, find developers :) > >>> > >>> What? First I've heard of it! I'm not sure how I feel about that. > >>> On one side, it seems reasonable to do it in something like python > >>> and remove the java dependency on the KVM host. On the other hand, > >>> there's a lot of technical debt in what's been built already, while > >>> it would probably be almost trivial to set up a basic working agent, > >>> it seems like a significant amount of work to transfer all of the > >>> functionality, special code that works around libvirt bugs, etc. Not > >>> to mention agent plugins that have already had a significant amount > >>> of effort put into them. On top of that, I'm not sure there's a > >>> whole lot of value if the motive is to attract non-java guys or > >>> admins, when the agent's features rely on what the mgmt server can > >>> do (new features/capabilities would require java code anyway, or at > >>> the very least coordinated effort between multiple devs who want the > >>> same feature). > >>> > >>>> > >>>> -Ecosystem: The are lots of tools in the cloud ecosystem, we should talk > about docker, ansible, cloud foundry/bosh...etc.and define a plan to have > great cloudstack support in all of those. > >>>> > >>>> -sebastien > >>>> > >>>>
