One thing I should add, while it makes perfect sense to me to draw a line on which technologies should be allowed in our code base, I will say that I'm fine with Java calling external scripts to do system admin work. I don't really like to see things split, like we have with libvirt where we use java bindings in some places and scripts in others (due to missing bindings), in those cases it makes sense to work toward pulling them back into java, but in general Java is a fairly poor system administration language. In addition, I'd wager that the overlap of people who are good at linux system administration and capable of scripting these tasks with those who can script these tasks in Java is very small. So I'm not really for trying to pull everything we possibly can back into Java. I'm ok with someone implementing a feature by writing a stub in the agent code that calls their system script. This is one advantage OpenStack has; being in Python it's easier for system admins to get in and work with, extend, etc.
On Sun, May 26, 2013 at 10:41 AM, Marcus Sorensen <shadow...@gmail.com> wrote: > Yes, you're welcome to rewrite it in Python. You're spot on with why > it's not in Java. > > As for why it's in Perl, it was simple for me to do and we already > have a dependency on it. As far as I've seen, the majority of what's > written for the agent to call is in Bash, and this task was fairly > difficult for Bash. The exceptions being security groups and the > installation helpers, which are in Python, presumably because they're > also difficult in Bash. The script this replaced was a Bash script. > It's probably because some people are really good at Bash, but don't > know Perl or Python, some are good at Python, but don't know Perl, and > vice versa. Or maybe someone knows them all but has a preference on a > specific tool for a specific job, for compatibility or whatever > reason. I personally tend to shy away from Python if I want to write > something that I know will work everywhere, due to the 2.6/2.7 > compatibility and spread between distros, but that shouldn't matter > for a simple script like patchviasocket.pl. > > Do we want to standardize and say that if it can't be in Java, and it > can't be in Bash, it has to be in Python? The other dependencies on > Perl are few, so we could probably wipe them out as well. If we have > to limit, I'd much rather it be Java, Perl, Python than Java, Bash, > Python, but it's too late for that I think. As a side note, Bash seems > to be highly preferred in the agent code, even though some of the > system vm scripts are fairly complex. It would be nice to see these > simplified by using a more powerful language as well. > > > On Sun, May 26, 2013 at 3:20 AM, Wido den Hollander <w...@widodh.nl> wrote: >> Hi Marcus, >> >> This is somewhat a rhetorical question, but I wanted to confirm anyway. >> >> The 4.2 SystemVMs use a VirtIO socket on KVM to get their boot arguments. >> That is great, since there is no longer a need for patch disks which enables >> them to run on RBD. >> >> One of the things I dislike about the KVM agent is all the scripts it runs, >> I'd rather see them all disappear since executing scripts and getting the >> correct exit statuses is always a difficult thing. >> >> Anyway, the patchviasocket.pl script opens the VirtIO Unix Socket on the >> hypervisor and writes some data to it. >> >> I've been searching and with some third party libraries it is also possible >> to do this natively from Java, for example: >> >> * http://www.matthew.ath.cx/projects/java/ >> * http://code.google.com/p/junixsocket/ >> >> They require libraries on the system with JNI though, so it will make our >> packaging efforts harder. Was this the reasoning behind doing this in Perl? >> >> If so, why Perl? Since most of the stuff in CloudStack is done in Java, >> Python or Bash, why Perl? Couldn't we rewrite this in Python if we don't >> want to do this in Java? >> >> Wido
