Open Stack

yes, I think from a tenant/user perspective, we can just use "lb-" to mean
load balancing.  forcing someone to include "aas" in each lb, fw, vpn, etc.
command they type would be a "pain-in-the-aas" in my opinion.

As Salvatore said, I think the use of "lb" to mean "linux bridge" is at
least mostly contained to code itself, which would should be able to avoid
the rework in the future.

Dan


On Mon, Nov 19, 2012 at 6:48 AM, Salvatore Orlando <sorlando at nicira.com>wrote:

> Hi,
>
> To the best of my knowledge, the 'lb' shortcut is used in place of
> 'linuxbridge' only in the name for the module hosting the plugin class
> (lb_quantum_plugin.py). I think we always use 'LinuxBridge' or LINUX_BRIDGE
> in all other instances. Also, as pointed out by Ilya, 'LinuxBridge' is a
> backend technology, and therefore never exposed to API clients.
>
> Salvatore
>
> On 19 November 2012 14:10, Ilya Shakhat <ishakhat at mirantis.com> wrote:
>
>> The only concern about 'lbaas' prefix is consistency with other advanced
>> services. For example, VPNaaS may have prefix 'vpn', DNSaaS - 'dns' and so
>> on. Abbreviation 'lb' as 'linux bridge' is used mostly internally in
>> Quantum and not exposed into client, so it wouldn't muddle end-users up too
>> much.
>>
>>
>> 2012/11/18 Samuel Bercovici <SamuelB at radware.com>
>>
>>>  Lb might be overloaded with Linux bridge.****
>>>
>>> Should we use lbaas as a prefix instead of lb?****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* Ilya Shakhat [mailto:ishakhat at mirantis.com]
>>> *Sent:* Thursday, November 15, 2012 4:04 PM
>>>
>>> *To:* OpenStack Development Mailing List
>>> *Subject:* Re: [openstack-dev] [Quantum][LBaaS] LBaaS extension for
>>> python-quantumclient****
>>>
>>>  ** **
>>>
>>> Thanks for comments Youcef!****
>>>
>>> ** **
>>>
>>> I've updated document with proposed changes. "tenant-id" attribute is
>>> added for all creation commands. Also I've noticed that there is
>>> "description" attribute in REST API pool update command, so I've added it
>>> for both "lb-pool-update" and "lb-pool-create" commands.****
>>>
>>> ** **
>>>
>>> As of keystone interaction - the client already supports both token and
>>> env. variables, so there is nothing to change here.****
>>>
>>> ** **
>>>
>>> Thanks,****
>>>
>>> Ilya****
>>>
>>> 2012/11/14 Youcef Laribi <Youcef.Laribi at eu.citrix.com>****
>>>
>>> Looks great Ilya!  ****
>>>
>>>  ****
>>>
>>> A few small comments below:****
>>>
>>>  ****
>>>
>>> ·         On lb-pool-create command, the arguments are not optional,
>>> they have to be specified.****
>>>
>>>  ****
>>>
>>> lb-pool-create [--network-id <network-id>] [--lb-method <lb-method>]
>>> [--protocol <protocol>] <name>****
>>>
>>>  ****
>>>
>>> ·         The type of the health-monitor cannot be updated.****
>>>
>>>  ****
>>>
>>> lb-healthmonitor-update [--type <type>] [--delay <delay>] [--max_retries <max_retries>] [--timeout <timeout>] [--name <name>] [--http_method <http method>] [--path <path>] [--expected-codes <expected codes>] <healthmonitor-id>****
>>>
>>>   ****
>>>
>>> ·         There is also the “description” field missing in the
>>> lb-vip-create command.****
>>>
>>>  ****
>>>
>>> Also for all the create commands, we should support supplied a
>>> “tenant_id” attribute when an admin is creating resources for another
>>> tenant (API supports supplying this).****
>>>
>>>  ****
>>>
>>> BTW, how is the tenant keystone token specified? are we going to use
>>> env. variables ?****
>>>
>>>  ****
>>>
>>> Thanks****
>>>
>>> Youcef****
>>>
>>>  ****
>>>
>>> *From:* Ilya Shakhat [mailto:ishakhat at mirantis.com]
>>> *Sent:* Wednesday, November 14, 2012 8:51 AM
>>> *To:* OpenStack Development Mailing List (
>>> openstack-dev at lists.openstack.org)
>>> *Subject:* [openstack-dev] [Quantum][LBaaS] LBaaS extension for
>>> python-quantumclient****
>>>
>>>  ****
>>>
>>> Hi!****
>>>
>>>  ****
>>>
>>> Please review the draft specification on LBaaS CLI (
>>> http://wiki.openstack.org/Quantum/LBaaS/CLI). It is based on service
>>> REST API, all new commands start with "lb_' prefix. ****
>>>
>>>  ****
>>>
>>> Thanks,****
>>>
>>> Ilya****
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
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/20121119/74f4d9a4/attachment.html>