Re: patchviasocket: Why in Perl and not native Java?

2013-05-27 Thread Wido den Hollander



On 05/26/2013 06:41 PM, Marcus Sorensen wrote:

Yes, you're welcome to rewrite it in Python.  You're spot on with why
it's not in Java.



Thanks for the clarification!


  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.



Ack, I might give it a try to rewrite in Python.


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.



I'd vote for:
* Java
* Bash
* Python

The reasoning behind Python is that:
A): We already have a lot of Python scripts (783 vs 1 Perl)
B): It seems to be the standard for Linux distributions to develop their 
scripts in. Ubuntu is a good example.


Wido



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


patchviasocket: Why in Perl and not native Java?

2013-05-26 Thread Wido den Hollander

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


Re: patchviasocket: Why in Perl and not native Java?

2013-05-26 Thread Marcus Sorensen
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


Re: patchviasocket: Why in Perl and not native Java?

2013-05-26 Thread Marcus Sorensen
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