[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aperi-dev] Aperi R4 planning
|
Dave,
I assume BSP refers to the SMI-S 1.1 Block Server Performance subprofile.
Thanks, Duane
Duane Baldwin
Storage Management Standards & Architecture
IBM Systems & Technology Group
Phone: 507-253-0894
Dave
Wolfe/Portland/IB
M@IBMUS To
Sent by: Aperi Development
aperi-dev-bounces <aperi-dev@xxxxxxxxxxx>
@eclipse.org cc
Subject
12/07/2006 07:17 Re: [aperi-dev] Aperi R4 planning
AM
Please respond to
Aperi Development
<aperi-dev@eclips
e.org>
Is 'BSP Profile' the Basic Security Profile Version 1.0?
Dave Wolfe/Portland/IBM (dwolfe@xxxxxxxxxx) TL: 775-3376 Office:
503-578-3376 Personal: 503-329-3960
GUI Technical Lead, Aperi Open Source Storage Management
http://www.eclipse.org/aperi http://www.ibm.com
If all of your problems look like nails you should invest in a good hammer
- Unknown
Khan M Tasinga/San Jose/IBM@IBMUS
Sent by: To
aperi-dev-bounces@xxxxxxxxxxx Aperi Development
<aperi-dev@xxxxxxxxxxx>
cc
12/06/2006 11:17 PM
Subject
Re: [aperi-dev] Aperi R4
Please respond to planning
Aperi Development
<aperi-dev@xxxxxxxxxxx>
That's a pretty good list of potential work-items. For the sake of
discussion, I've listed some additional ones that come to mind. It might be
possible to start doing some of the work identified below during the 0.3
timeframe.
- Move away from MS Visual C++ 6.0 for native Windows compilation. Off top,
a couple of potential alternatives come to mind. First, depending upon
things like legal constraints associated with its use, we might be able to
move to Visual C++ 2005 Express Edition, which Microsoft makes available
for free (http://msdn.microsoft.com/vstudio/express/visualc/). Second, we
can explore using GCC through Cygwin.
- Use fragments for native libraries. We need to work around the issue
described in the following bug report:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=139064.
- Move batch reporting from the agent to the server. Batch reporting, as it
is currently implemented, requires deployment of the entire legacy GUI to
our agent. Moving batch reporting to our server will reduce both the
in-memory and filesystem footprint of our agent.
- Data Server and Device Server consolidation. Currently, the Data Server
and Device Server run in separate OSGi containers. In some respects, that
fact is actually a good thing. However, it might be nice to make it
possible to run them within the same OSGi container.
- Host-based agent separation. Currently, we package our Data Agent and
Fabric Agent in a single OSGi container. Would it make sense to give people
the ability to run them in separate containers? I don't think doing so
would require making any code changes. This would probably just be some
packaging work.
- Automated test suite. I think putting something in place would contribute
greatly to the overall stability of our code.
- Move away from Apache SOAP. Given that Apache SOAP satisfies our existing
requirements, moving to something new probably isn't all that necessary.
However, it might be interesting to explore what advantages we might reap
by moving to something like Axis (http://ws.apache.org/axis/) or Axis2 (
http://ws.apache.org/axis2/). It might be possible to build on top of some
of the work being done by the Corona project (
http://www.eclipse.org/corona/).
- Operating system support. While our legacy GUI is capable of running on
any machine with a JVM, such is not the case for our agents and servers.
Currently, our agents and servers run on Windows and Linux. There might be
some interest in seeing them run on other OSes (e.g., AIX, Solaris, etc.).
- Database support. Aperi can run against Apache Derby and DB2. There might
be some interest in additional database support (e.g., Oracle, MySQL,
PostgreSQL, etc.).
- Additional enhancements to extensibility and componentization, throughout
Aperi. For example, on the Data Server, while it's possible to add things
like resource attributes and alert conditions, doing so in a way that
allows different vendors to share the same instance of Aperi is cumbersome.
As such, there's probably room for improvement.
Regards,
Khan Tasinga
IBM Tivoli Software Engineer
Dept: DQUA / Bldg: 050 / Office: A152
5600 Cottle Road, San Jose, CA 95123
Phone: (408) 284-5142 | T/L: 8-953-5142
Email: kmtasing@xxxxxxxxxx
Ted Slupesky/Portland/IBM@IBMUS
Sent by: aperi-dev-bounces@xxxxxxxxxxx
To
12/05/2006 01:56 PM aperi-dev@xxxxxxxxxxx
cc
Please respond to Subject
Aperi Development [aperi-dev] Aperi R4
<aperi-dev@xxxxxxxxxxx> planning
Hello,
I'd like to start the work for planning for Aperi's R4 release. I will list
here the candidate work items from our roadmap and also the 'future' work
items. For each candidate, I'd like to identify an owner in this coming
Monday's development meeting. I'd like the owner to be responsible for
learning enough about the candidate work item to be able to propose various
technical solutions to achieve it... which will ultimately turn into
sizings and project plan. But for now, technical investigation is what is
called for.
Now that our code is available in eclipse.org, this is the first time we
can engage in a release planning process completely in the open -- and it's
a great opportunity for interested developers who haven't been actively
participating to start doing so.
The R4 items from our roadmap are:
SMI-S Fabric & Switch profiles (*)
SMI-S NAS profile
Unified Storage support (FC, NAS composite view)
Complete Eclipse RCP GUI
Items we identified as future work items -- with sufficient interest we
could move some into R4:
IP storage support
SMI-S Virtual Fabric subprofile
BSP profile
Performance statistics for unified storage via SMI-S
Host profile
CLI
Remote install & upgrade of host agents
Role-based access control – finer-grained role definition and
application to profiles
Increased support for storage virtualization (beyond inband
virtualizer)
Application awareness
Of course we are free to re-evaluate these lists. If there is sufficient
interest in the community, the roadmap can certainly be adjusted and items
added (or removed). In fact I would like to propose some additional
candidates:
Port binding
Improved data model for reporting
Feel free to respond with your feedback regarding this list and any changes
you'd like to see (and to volunteer for an item, too!). We'll discuss this
further in Monday's call.
Note: SMI-S Fabric & Switch profile support have a * next to them because
this is an area where IBM has code to contribute (I'd be happy to discuss
alternative implementations however).
--
Ted Slupesky | Eclipse Aperi Project Lead | IBM: 349-5413 | External: (503)
820-3853
_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev
_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev
_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev
