[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aperi-dev] Aperi R4 planning
|
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: aperi-dev-bounces@xxxxxxxxxxx
12/06/2006 11:17 PM
Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx> |
|
To
| Aperi Development <aperi-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| Re: [aperi-dev] Aperi R4 planning |
|
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
12/05/2006 01:56 PM
Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx> |
|
To
| aperi-dev@xxxxxxxxxxx
|
cc
|
|
Subject
| [aperi-dev] Aperi R4 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