A lot of good iASP feedback. I am initially documenting it in this
publicly editable GoogleDoc for ease/simplicity, though it should
eventually end up on wiki.midrange.com:
http://bit.ly/whyibmi_iasp
<JimO: then why not just give each of them a virtually hosted partition
(hosted by IBM i or VIOS) and be done with it?
Cost prohibitive. Though I do believe this will get better in the future
as IBM continues to see IBM i adopted for cloud. Though I wonder if the
70-day trial could work for some of the CI uses I am envisioning (see
below).
<Larry: So you kinda can get to programs in the IFS if invoking them this
way works for you.
This is one of my concerns - that others can see the various iASP devices
and objects.
Let me back up a bit to convey a portion of the "why" behind my questions.
The IBM i community stands to gain a lot from the open source community via
PASE. The issue is that the open source community doesn't have dead simple
access to IBM i so Continuous Integration** tests can be run for our
platform. To see what I am talking about check out
https://travis-ci.org.
In short, imagine if each time a commit was done to libxml2 that it would
spin up a logical environment on IBM i to compile and unit test to learn
whether the changes will work on IBM i.
**
http://en.wikipedia.org/wiki/Continuous_integration
The chroot** environment approach gets close to meeting this need, but with
security holes once /QSYS.LIB gets involved. Obviously those security
holes aren't nearly as detrimental for open source CI so I think this could
still be an option. One thing chroot doesn't have that docker.io does is
the ability to limit resources*** (i.e. CPU) and that is one area I was
curious whether iASP might be able to help.
**youngiprofessionals.com/wiki/index.php/PASE/CHROOT
***
http://bit.ly/workload_groups
Aaron Bartell
midrange.com
