Open Stack

Hi Sam,
I'll comment on what I know in-line.

On Wed, 2014-07-02 at 15:29 +0000, Samuel Bercovici wrote:
> To reiterate the Juno release plan from:
> https://wiki.openstack.org/wiki/Juno_Release_Schedule
> 
> Feature freeze is at: 21st August.
> 
>  
> 
> I am listing tasks which we should consider to be done for Juno and
> who should handle them.
> 
>  
> 
> The following might be considered as critical path to get anything for
> Juno:
> 
> 1.      LBaaS Plugin, API, DB – when is a code commit expected?
The extension, plugin, and DB code are all implemented for the most
part.  Right now we are working on the "db" unit tests.  The "plugin"
tests have been converted from the old version.  The reason I am using
quotes is because the old plugin unit tests actually tested the
extension, and the old db unit tests actually tested the plugin (though
I can digress into a rant about how its not really unit tests, but I
won't bog this down).  So I'm probably jsut going to rename the modules.

After that is done I'll probably put this up on gerrit as a WIP because
there still things left to be included that others are working on such
as shim layers, agent tree refactor, namespace_driver refactor.
> 
> 2.      CLI

Craig Tracey has been working on this.  From what I understand he is
close to completion.

> 
> 3.      LBaaS Driver Interfaces – done -
> https://review.openstack.org/#/c/100690/
> 
> 4.      Connecting the Plugin calls to the drive – I have not seen any
> reference to this. I think we should use the “provider” capabilities
> until “flavor” gets implemented. Is this addressed by item 1 above or
> does it required an additional task?

Yes that is what is being done in #1.

> 
> 5.      HA proxy reference implementation – when is a code commit
> expected?

I believe Dustin Lundquist was/is working on this.  I'll let him give an
update.

> 
> 6.      Tempest Tests

Miguel Lavalle was working on this.

> 
>  
> 
> Additional “Core” features
> 
> 1.      Horizon UI

This one should be discussed more.  I think we talked about that this
can wait because the v1 API should remain unchanged and so Horizon can
use that at first until a change is made.

> 
> 2.      Quota update/fix

If by this you mean quota for loadbalancers, listeners, pools, members,
health monitors, then this will be done in the refactor.

> 
> 3.      API Compatibility

If by this you mean the new API and old API requests and responses work
simultaneously then that will be done in the refactor.

> 
> a.      Connecting the “OLD API Plugin calls to “old/new” drivers. Is
> this still planned?

The old API plugin will not be calling the new driver interface.  There
may be a shim layer that turns the new object model into the old one and
passes it to the drivers that do not follow the new driver interface.

> 
> 4.      Driver Compatibility

Mentioned this above.

> 
> a.      Connecting the Plugin calls to “old” drivers. Is this still
> planned?

Touched on it above, but there may be a shim layer that does this
translation.  I also think if the old API and new API can live side by
side this shim layer may not be needed.  That needs to be a different
discussion though.

> 
>  
> 

Everything below does indeed depend on the refactor so I haven't been as
involved as I should be in those discussions.  I'll let those who are
involved give updates.

> In addition/parallel
> 
> 1.      TLS  – 
> 
> a.      BP is approved. 
> 
> b.     WIP code was committed and waiting for the code of the basic
> API/model to be available for start of review. 
> 
> c.      HA Proxy reference implementation
> 
> d.     CLI
> 
> e.     Horizon Support
> 
> f.       Tempest Tests
> 
> 2.      L7 context switching
> 
> a.      BP in review
> 
> b.     WIP code in progress and waiting for the code of the basic
> API/model to be available for initial commit
> 
> c.      HA Proxy reference implementation
> 
> d.     CLI
> 
> e.     Horizon Support
> 
> f.       Tempest Tests
> 
>  
> 
> Anything else?
> 
>  
> 
>  
> 
> Regards,
> 
>                 -Sam.
> 
>  
> 
>