Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aperi-dev] Aperi R4 planning


Yep, that's what I meant.

--
Ted Slupesky | Eclipse Aperi Project Lead | IBM: 349-5413 | External: (503) 820-3853




Duane Baldwin/Rochester/IBM@IBMUS
Sent by: aperi-dev-bounces@xxxxxxxxxxx

12/07/2006 05:46 AM

Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx>

To
Aperi Development <aperi-dev@xxxxxxxxxxx>
cc
Subject
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
_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev


Back to the top