Hello all,
I wanted to respond to this from the point
of view of a storage vendor looking to have Aperi work seamlessly with our
product line, which may be a different take than the typical end-user, but I
thought I’d throw it out there. In particular, I wanted to address the
question “What does Aperi need to be in order to add value to your
organization?”
- First
off, as a company interested in contributing plug-ins to the Aperi
codebase that allow specifically for easier management of our devices
without increasing the level of code bloat Aperi users have to deal with,
we’re interested in keeping the architecture and implementation of
Aperi as cleanly modular as possible. We’d like to be able to write
plug-ins that touch as little of the existing codebase as possible, for
easy addition or subtraction, and have customers that are interested in
using Aperi to manage our devices be able to do so without installing any
extraneous elements that they will not be using (for example, utilizing or
writing plug-ins for the device managers without needing to install or
touch the tape managers) to keep the footprint as small as possible.
- Along
the same lines, we’d like to be sure Aperi keeps a focus on having
the native GUI that comes with Aperi be easily replaceable with another
GUI should a vendor choose to write one. If a company, for example, wishes
to build on the Aperi codebase and infrastructure while maintaining a look
and feel that has a consistency with the rest of their brand, this should
be easily accomplished with as little code-hacking as possible. I know
Aperi is in theory designed and implemented to accommodate this, but
theory often falls by the wayside when things get put in to practice, and
we need to be vigilant to ensure that this does not happen.
- We’d
like to see Aperi possibly move toward a more database-agnostic platform.
For example, we know that the underlying technology is SMI-S, and
we’d like to be able to wrap that protocol in whatever wrapper
we’d like to develop within, not necessarily just a Java platform.
Other vendors may as well. If someone is looking at browser-based
technology for their products, how does the information currently stored
in a DB2 or Derby
database translate to a browser DOM, or what if a vendor wishes to use a
more lightweight SQL database instead?
- The
more developer tools we can make available, the better. If we want folks
contributing code, we should make it as easy as possible for them to learn
about the architecture and structure of Aperi and how to develop for it. Detailed
information on how to write plug-ins would be super helpful,
as I mentioned in today’s meeting. Good documentation on writing
plug-ins, making contributions, etc. would really help
us to help make the world of
Aperi a better place, at least when it comes to managing our storage.
- Continued
development of a robust and rich SAN simulator tool will help people looking to contribute to Aperi
immensely. Just wanted to highlight the importance of that tool to this
community and mention that it should be updated regularly.
- Support
for additional OSes. As we’ve been discussing on the distribution
list, support for Solaris would be great. Just wanted to second the
motion.
On the topic of my experience with Aperi
thus far, I’ve already written in detail regarding my installation
experience, pre-GUI-installer. I intend to embark on a complete analysis of the
interface and interaction models and will share the results of that with
the community once I’ve completed it.
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
From:
aperi-dev-bounces@xxxxxxxxxxx [mailto:aperi-dev-bounces@xxxxxxxxxxx] On Behalf Of Todd Singleton
Sent: Thursday, August 23, 2007
2:31 PM
To: aperi-dev@xxxxxxxxxxx
Subject: [aperi-dev] Adoption of
Aperi...
Hello All,
This
post is intended to stimulate some open, candid discussion about the adoption
of Aperi. This is especially important as we head into 2008 - we need to
make sure that, as a community, we are adding value to Aperi in such a way to help drive adoption. So please chime in with
your thoughts and incites.
What does Aperi need to be in order to add value to your
organization? This is the fundamental question that needs to
answered by all members of the community. Does Aperi need to be a competitive
end-user product for IT storage administrators? Does it need to gain a
strong end-user following like Nagios and Apache did (producing demand from
customers)? Does Aperi need to be a collection of easily consumed
components? If so, what does 'easily consumable' mean for you? Does
Aperi need to focus more on SAN simulation (or other support tools) and less on
a real-time management application? Is your organization interested in
adopting the entire code base, rebranding it, and selling it as a commercial
offering?
Answering
these questions will help us focus
our efforts and ensure that Aperi produces value for participating members.
What has your experience done for your organization so far?
Have you attempted to adopt Aperi? Have you attempted
to use Aperi? If so, what were your first impressions? Did your
experience help or hurt?
The
download, install, and run process has been painful for many for a number of
reasons (many of them legal). However, this experience continues to
improve and should be much less painful with the upcoming builds and releases.
However, do share your thoughts.
What does 'adoption' mean for your organization?
Aperi
has several cool features (topology viewer, discovery, reporting, etc.).
However, we know that cool does not equal useful and free does not equal
valuable. So what would be substantially useful and valuable to your
organization - enough to drive adoption? Do share.
Todd
Singleton
Software Engineer, Tivoli,
IBM
Menlo Park, CA
email: toddsing@xxxxxxxxxx
|