Hi Tom/Dave,
I met today with some internal interested parties and we
came up with the Top 5’s that we discussed in the Aperi architecture
meeting the other day (not necessarily in prioritized order). Here they are,
for your roadmap enjoyment:
TOP 5 THINGS APERI NEEDS TO SUCCEED
- Strong ties with and commitment
to SNIA, especially supporting SNIA Management Framework APIs as they are
available.
- Broad support from the storage
vendor and storage administrator communities. Aperi needs to present a
clear message to the storage world on what Aperi is and why end users and
storage vendors should adopt it. It might help to start appearing in Linux
distributions by talking to Red Hat or SuSe to get Aperi bundled with
other open source applications. A marketing story like a “Top 10
things Aperi can do for developers and end users” might help push
this along as well.
- An easily installed demo
package. Bundle the management software and the SAN simulator into a
single-button installable that makes the installation and evaluation experience
painless for those wishing to test-drive Aperi and see what it is like.
There are so many open-source packages out there that are completely
painless to install and evaluate, Aperi needs to be one of these as well.
- A clear and easy pathway by
which people can contribute to Aperi. What we are looking for here is good
documentation on Aperi architecture and writing plug-ins, with examples,
as well as documented procedures for writing defects like what was
circulated the other day to the aperi-dev list.
- Broader OS coverage. Aperi
currently contains both Java and C code. If we remove the C code, what’s
left in Aperi as a Java-only implementation that will run on any OS? Do we
lose any critical functionality that way? What are the limitations to a
pure Java implementation? Has anyone taken a hard look at replacing the
existing C code with Java? Alternatively, a good porting guide would be
helpful if the C code is critical. A simple and easy to read guide that
lays out exactly what someone needs to do to port Aperi to another OS
would be very helpful.
TOP 5 THINGS LSI WANTS FROM APERI AS
PREREQUISITES TO CONTRIBUTING/ADOPTING
- Clearly-written documentation
on the architecture, the existing extension points and how to write
plug-ins, with examples. Preferably written by a technical writer rather
than a development resource.
- The ability for Aperi to launch
browser-based functions or element managers via URL, where they are
written as HTML or in _javascript_, for example. We would like to be able to
reduce duplication of effort among those writing code to extend Aperi so
that if a function is written for a browser-based environment, it does not
have to be re-written to work in OSGi/Java. This is critical to reducing
duplication of effort and allowing for the most efficient deployment of
development resources.
- Clearly-defined guidelines and
rules on using Aperi in commercial applications and applicable rights
relative to licensing. We’d like for Aperi to lay out for us exactly
what the licensing issues are. Internal lawyers are ultra-conservative.
- Training sessions for
developers and testers on working with Aperi.
- A configurable, modular,
well-documented, pluggable security manager. We need to be able to
investigate the Aperi security model and easily and seamlessly implement
our own if we decide to. Other vendors may want this capability as well.
Security is becoming a critical issue.
TOP 5 THINGS WE WOULD LIKE TO WORK ON
- Launch-in-Context ability. We
would like vendor-unique extensions that allow for a specific function to
be launched according to the object selected (when the selected object is
LSI OEM) without having to launch an intermediate vendor-unique Element
Manager for that object.
- Implementing broader OS coverage
(not a vendor-unique function), whether investigating a pure Java
implementation without C code or porting Aperi to other OSes.
- Getting Aperi to work seamlessly
with URL-launched functions, whether written in _javascript_ or HTML.
- Vendor-unique RAS extensions to
Aperi, such as providing statistics for various protocols or creating a
visual representation of component topology and cabling.
- Any required refactoring work
to make the security manager pluggable and modular, if needed. If we look
at Aperi and find any areas that we would like to see made more modular,
we would be willing to work on that.
Hope this helps, and we see everything we’ve requested
on the roadmap! J Please let me know
if you have any questions, and note that I will be out of the office and
completely unavailable from October 5th-15th.
Thanks,
Jenny
Jenny Monesson, Ph.D.
Solutions Architecture
LSI - Engenio Storage Group, Austin TX
jenny.monesson@xxxxxxx
Voice: (512) 794-3723
Fax: (512) 794-3702
|