Open Stack

Sumit,

I'm going to create a wiki page on directory structure tomorrow.
Meanwhile you could look at https://review.openstack.org/#/c/28257/

Thanks,
Eugene.


On Tue, May 7, 2013 at 12:47 AM, Sumit Naiksatam
<sumitnaiksatam at gmail.com>wrote:

> Thanks Eugene for the summary (and for organizing the meeting). Can
> you also add what the current consensus is on the directory structure
> (as in what it is intended to finally look like,
> services/loadbalancer/...)?
>
> In general, item 1 discussed below obviously has implications beyond
> just the loadbalancer service. Happy to take up the action item on
> this.
>
> ~Sumit.
>
> On Mon, May 6, 2013 at 12:17 PM, Eugene Nikanorov
> <enikanorov at mirantis.com> wrote:
> > Hi, this is a follow up of the todays' LBaaS meeting held on
> #quantum-lbaas.
> >
> > Agenda:
> > 1. ServiceType framework
> > 2. Service source file locations
> > 3. Multivendor support
> > 4. NFV
> > 5. Regular meeting
> >
> > 1. ServiceType framework
> > Agreed on the following:
> > - ServiceType is the name of the entity consisting of
> > (uuid, service_class, plugin:driver, vendor (opt), version (opt))
> > This is an essential entity with minimal info needed for multivendor
> > support.
> > - Extra parameters include: insertion mode, service quality.
> >
> > Action item: Sumit to prepare workflow with additional parameters (ins.
> > mode, quality) and entities (ServiceOffering, ServiceChain, etc).
> > Workflow design should be a separate discussion.
> >
> > Action item: Eugene to refactor current ServiceType framework to comply
> with
> > what was decided.
> >
> > 2. Service source file locations (related gerrit
> > https://review.openstack.org/#/c/28257/ )
> > Agreed on making two changes:
> > - move all lbaas-related implementation files to
> > plugins/services/agent_loadbalancer
> > (db plugin goes to services/agent_loadbalancer/db)
> > - rename agent_loadbalancer to loadbalancer to indicate that we're going
> to
> > have multivendor solution
> >
> > Remaining question:
> > whether to move whole services directory one level up.
> > That could shorten import paths a bit and also it's a good time to make
> such
> > change before services directory is not very populated.
> >
> > 3. Multivendor support
> > Was not discussed.
> > There are two patches on review:
> > splitting reference implementation into plugin and plugin driver:
> > https://review.openstack.org/#/c/28289/
> >
> > "Blueprint multi-vendor-support-for-lbaas-step0"
> > https://review.openstack.org/#/c/28245
> >
> > 4. Network Function Virtualization.
> > There's a concern that this blueprint is trying to address the problem
> that
> > is already is being solved.
> >
> https://blueprints.launchpad.net/quantum/+spec/nfv-and-network-service-chain-implementation
> > This is not quite related to LBaaS, however there are plans to implement
> > "device inventory" module, which is needed for LBaaS and could be
> utilized
> > by other services as well.
> > That overlaps with what is proposed in NFV.
> >
> > 5. Regular LBaaS meeting.
> > Waiting for Mark McClain opinion.
> >
> > Thanks,
> > Eugene.
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130507/d67ca62a/attachment.html>