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 >>>> >>>>
