Open Stack

Hi team,

Eugene, overall the strategy of slimming down what we're trying to
accomplish in terms of scheduling in Grizzly makes sense.  Some of these
deeper level issues are good topics we can discuss at the Havana release
summit in April.

My only bit of feedback is along similar lines as Avishay.  I believe the
current LbaaS work being done is focused on a "scheduling model" where
there are one or more pools of available LB devices, a pool is selected
based on service type, and then a device selected from the pool, and
communicated with via a driver.  This is certainly one viable model for
LBaaS, and it definitely makes sense to have a plugin that implements this
model to communicate with many different types of LB devices. But its also
important that we don't "bake" this model into assumptions about how all
LBaaS plugins should work.  For example, some LBaaS plugins may not expose
the ability for operators to define scheduling, so having a generic
construct for all lbaas plugins where operators always specify a scheduling
algorithm for each service type doesn't make sense (note: this might make
sense as configuration for a particular lbaas plugin, just not as a general
construct for all plugins).

This is similar to what makes me nervous when I hear discussion of generic
constructs for managing individual load-balancing devices from an operator
layer.  This may be something that some plugins do, but others do not, and
we need to make sure we do not make our service-wide or lbaas-wide
constructs too specific to our first lbaas plugin implementation.

It sounds like we're taking very simple approaches to these for the initial
lbaas implementation in Grizzly, which is the right step.  Coding up a
first service plugin design will flesh out many of the deeper issues we
need to talk about at the Havana summit and help serve as a very concrete
example of the challenges we need to tackle.  The trick is just doing it in
a way that does not overly constrain what we can do in the future.

Dan


On Sun, Jan 27, 2013 at 5:28 AM, Avishay Balderman <AvishayB at radware.com>wrote:

>  Hi,****
>
> ** **
>
> As discussed previously in the ML (by Samuel Bercovici). the scheduler
> should be part of the device and not global as can be seen in the attached
> picture.****
>
> The only global logic is the selection of the appropriate Driver based on
> service type/capabilities.****
>
> ** **
>
> The device selection logic might be based on vendor specific logic which
> is not be relevant in a global scope.****
>
> In addition, the appropriate registration of the different devices as well
> as the provisioning logic is unique to each vendor.****
>
> ** **
>
> As we (Radware) plan to manage the placement in the Driver, we will not be
> using any of the logic discussed.****
>
> Is there any reason prohibiting the scheduling logic to be used by the HA
> Proxy driver privately and not as a global logic?****
>
> If other vendors want to use the device scheduler for their
> implementation, they can utilize this class the is also provided for the HA
> proxy.****
>
> Moreover, such class could be placed in a shared directory (ex:
> LBaaS_utility) so that anyone who wishes to use it, could get it from there.
> ****
>
> ** **
>
> Thanks****
>
> ** **
>
> Avishay
>
****
>
>                 ****
>
> ** **
>
> *From:* Eugene Nikanorov [mailto:enikanorov at mirantis.com]
> *Sent:* Tuesday, January 22, 2013 5:21 PM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [Quantum][LBaaS] Scheduling & device
> management for LBaaS****
>
> ** **
>
> Hi folks,****
>
> ** **
>
> I'd like to present blueprint
> https://blueprints.launchpad.net/quantum/+spec/quantum-service-schedulerwhich I feel needs to be in grizzly.
> ****
>
> You can find more detailed description in specification page.****
>
> ** **
>
> Initially we planned to have comprehensive device management as separate
> plugin with extension and complicated schedulers.****
>
> However due to the lack of time and reviewer resources we desided to
> greatly reduce the scope of this work.****
>
> So, currently the code on review ( https://review.openstack.org/#/c/20225/ )
> introduces the following:****
>
> 1) Configuration management for service schedulers, e.g. admin can
> configure particular scheduler for particular service type****
>
> 2) Simplistic scheduler for lbaas:****
>
>   - scheduling algorithm that randomly chooses a device from list of
> devices****
>
>   - device manager that reads devices from predefined conf-file
> (suggestion from Salvatore)****
>
> ** **
>
> I believe this is reasonable minimum that will allow to use LBaaS service
> at least with some convenience. ****
>
> (In fact, I'd provide some more scheduling algorithms)****
>
> ** **
>
> We have also started to integrate this code with code of
> lbaas-agent-and-rpc<https://blueprints.launchpad.net/quantum/+spec/lbaas-agent-and-rpc> according
> to the call sequence diagram:****
>
> http://wiki.openstack.org/Quantum/LBaaS/Architecture/Scheduler****
>
> So we plan that this code will be base patch for lbaas-agent-and-rpc<https://blueprints.launchpad.net/quantum/+spec/lbaas-agent-and-rpc>
> .****
>
> ** **
>
> Thanks,****
>
> Eugene.****
>
> ** **
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130130/0e2748e8/attachment-0001.html>