Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aperi-dev] LSI's Aperi Requirements list

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

 

 


Back to the top