[openstack-dev] [Quantum][LBaaS] Advanced Services Insertion

Eugene Nikanorov enikanorov at mirantis.com
Wed Oct 31 19:21:08 UTC 2012


Salvatore, thanks for detailed reply.

But still there are unclear points for me :(

1. What does mean "advanced service is created". Don't we always have all
advanced services which are provided by plugins configured in quantum.conf?
I mean if we configured lbaas plugin in quantum.conf then tenant may call
corresponding tenant API to request LB service. Is my understanding correct?

2. What happens when tenant calls /routers/<r_id>/enable_service ?

Once again, I've tried to map this "insertion" to the workflow of how a
tenant gets a service, but you're saying it's not about it, so I'm trying
to understand how services insertion affects our design and code at all.

Thanks,
Eugene.

On Wed, Oct 31, 2012 at 9:14 PM, Salvatore Orlando <sorlando at nicira.com>wrote:

> Hi Eugene,
>
> thanks for your feedback.
> Please see my replies inline.
>
> On 31 October 2012 13:32, Eugene Nikanorov <enikanorov at mirantis.com>wrote:
>
>> Hi Salvatore,
>>
>> I'd like to give some feedback/questions based on yesterday's meeting
>> discussion and your renewed
>> http://wiki.openstack.org/Quantum/ServiceInsertion page.
>>
>> First of all, I think it's worth to fix the terminology just to avoid any
>> confusion:
>>
>> - extension (API extension) - set of REST calls
>> - plugin - code that implements certain API, works with quantum database,
>> pushes calls to agents
>> - core plugin - code that implements core API (networks, subnets, ports,
>> L3)
>> - agent - listens to commands from plugin, applies configuration to
>> particular device type, ex: ovs agent, L3 agent
>> - driver - code that applies conf to particular device type. That is just
>> another layer needed to support different device types. Example:
>> Loadbalancing agent may have several drivers to talk to different LB
>> devices.
>>
>
> Everything agreed, with the only exception that some flexibility might be
> allowed in the definition of agents/drivers. It is possible to think of a
> plugin which directly dispatches commands to drivers, rather than relying
> on agents. But this is probably just a detail.
>
>>
>> Some thoughts on the Service Insertion proposal:
>>
>> 1. It seems that multiplugin approach is the right way to move further
>> compared to "mixin" approach where we inject and modify code of the core
>> plugin.
>> This will preserve plugin independency while require some changes to
>> infrastructure (plugin loading, extension management).
>>
>
> I agree on the changes to the infrastructure. I'd like to understand a
> little bit better what degree o plugin independency you'd like to achieve.
>
>
>>
>> 2. Having several implementations of the same service type.
>> If all services of the certain type implement the same calls, then
>> something should allow to route the call to particular plugin.
>> The options include:
>>   1)  passing particular service impl as a url parameter
>>   2)  having a prefix in uri for certain svc type:
>> /lb_svc/lbaas_impl1/call.json, /lb_svc/lbaas_impl2/call.json
>>   3)  having (tenant, service implementation) assosiation in DB that will
>> allow to route a call automatically. But this makes 1 to 1 relation, e.g.
>> tenant will have only 1 impl of service available
>>
>
> In the list above there's no mention of the service_type concept we
> discuss at the summit and which is also presented on the serviceinsertion
> wiki page. Do you deem it totally unreasonable?
>
>
>>
>> My preference is (2): first of all, it "splits" whole API between core
>> API and Adv Svc API, and also does so for different service type
>> implementations.
>> Although URIs may not be so short as we want them, that could prevent
>> from naming collisions between different service types.
>>
>
> I have some concerns about this approach, and the length of the URI is not
> one of them. The particular implementation of a load balancing plugin is
> directly surfaced, meaning that a user cannot transparently move from one
> plugin to another without having to rewrite their client applications - as
> this proposal implies that /lb_svc/lbaas_impl1 might have different spec
> from /lb_svc/lbaas_impl2. Also, one might wonder what's the point in this
> case of going through quantum at all: one can just send the calls to an
> endpoint which performs URL rewriting and then forwards the call to
> appropriate final endpoint. Finally, it is my opinion that this solution is
> tantamount to saying that you want multiple LBaaS solutions at the same
> time in the same cloud; I won't argue that this is not a reasonable use
> case, but I'd prefer Quantum to present a single LBaaS interface rather
> than harbouring multiple solutions.
>
>
>>
>> 3. Service Insertion:
>> I was thinking about routed/floating-mode insertion and there is a
>> certain thing I don't understand: the workflow.
>> It seems that the whole thing is somehow close to what we used to call
>> "device management" in mirantis implementaion of lbaas, but it doesn't look
>> like solving all device management tasks.
>>
>
> Actually, I don't think it is related at all to device management -
> assuming that I understand what you mean by device management. We are using
> this terminology to talk about insertion in the logical model, not the
> physical model. I think I clarified in the specification that we don't want
> to address device management in the service insertion blueprint. It is my
> opinion that this task is specific to particular advances services. For the
> LBaaS case, it necessarily requires a knowledge of physical and virtual
> appliance that I honestly do not have... so I'll gladly leave it to the
> load balancing experts :)
>
>
>>
>> So in our implementation of LBaaS the workflow was as following:
>> 1) admin creates the device. Essentially it's just an instruction to
>> LBaaS of where is the device (it's address), which type is it and
>> credentials to manage it.
>>
> 2) tenant creates VIP. During this operation LBaaS chooses the most
>> appropriate device from the list of available and makes appropriate device
>> configuration
>>
>
> I think it is a reasonable workflow and goes back to the discussion around
> "capabilities" we were having during last week's call. I hope we agree that
> this is specific to LBaaS - I don't think service insertion has anything to
> do with it, as it looks just after the "logical" topology.
>
>
>> If we're talking about workflow within Quantum it could look like
>> following (scenario 1 - shared HW device):
>> 1) admin creates the device. The same as in lbaas - address, type,
>> credentials
>> 2) tenant creates VIP: Quantum LBaaS plugin chooses the device,
>> configures connectivity between the device and tenant network (possibly
>> with l3 router configuration),
>> configures loadbalancer according to provided VIP parameters, possibly
>> assigns floating IP from external network
>>
>
> The solutions for "stiching" a device to a quantum network vary with the
> nature of the device, and with the way in which the service is inserted in
> the logical topology. I think what you said above is valid; in addition to
> that you might consider also other possibilities:
> 1) using nova to plug services in quantum - which would work nicely for
> physical appliances
> 2) leveraging an underlying layer-2 agent (which would be the same thing
> the l3 agent does)
> 3) using the "provider networks" capability. This capability, in a
> nutshell, will allow you map a Quantum network, regardless of the
> technology Quantum uses.
> 4) having a "translator" across service types (for instance GRE to VLAN or
> VXLAN to VLAN) - we don't have yet this on Quantum, but Kyle from Cisco has
> a very interesting blueprint on this topic:
> https://blueprints.launchpad.net/quantum/+spec/quantum-network-segment-translation
>
>>
>> If we're talking about private balancer with Quantum, then:
>> 1) tenant creates the device. This could be a launch of VM with HA Proxy
>> within tenant for instance.
>> 2) tenant creates VIP: LBaaS configures loadbalancer according to
>> provided VIP parameters, possibly assigns floating IP from external
>> network. No other actions required
>>
>
> Yeah... I agree there might be a case where a tenant creates a device.
> This is why we never make a clear distinction between tenant and admin
> APIs, but leave it configurable through the policy engine.
>
>
>>
>> It would be great if you explain how service assignments for routers maps
>> to device management scenarios and what exact workflow will be.
>>
>
> I hope my explanation is satisfactory - which basically is that service
> insertion and device management have nothing in common.
>
>
>>
>> Thanks,
>> Eugene.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121031/675d3e90/attachment-0001.html>


More information about the OpenStack-dev mailing list