Salvatore, thanks for detailed reply.<div><br></div><div>But still there are unclear points for me :(</div><div><br></div><div>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?</div>
<div><br></div><div>2. What happens when tenant calls /routers/<r_id>/enable_service ?</div><div><br></div><div>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.</div>
<div><br></div><div>Thanks,</div><div>Eugene.<br><br><div class="gmail_quote">On Wed, Oct 31, 2012 at 9:14 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eugene,<div><br></div><div>thanks for your feedback.</div><div>Please see my replies inline.<br><br><div class="gmail_quote">
<div>On 31 October 2012 13:32, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Salvatore,<div><br></div><div>I'd like to give some feedback/questions based on yesterday's meeting discussion and your renewed <a href="http://wiki.openstack.org/Quantum/ServiceInsertion" target="_blank">http://wiki.openstack.org/Quantum/ServiceInsertion</a> page.</div>
<div><br></div><div>First of all, I think it's worth to fix the terminology just to avoid any confusion:</div><div><br></div><div>- extension (API extension) - set of REST calls</div><div>- plugin - code that implements certain API, works with quantum database, pushes calls to agents</div>
<div>- core plugin - code that implements core API (networks, subnets, ports, L3)</div><div>- agent - listens to commands from plugin, applies configuration to particular device type, ex: ovs agent, L3 agent</div><div>- 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.</div>
</blockquote><div><br></div></div><div>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. </div>
<div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>Some thoughts on the Service Insertion proposal:</div><div><br></div><div>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.</div>
<div>This will preserve plugin independency while require some changes to infrastructure (plugin loading, extension management).</div></blockquote><div><br></div></div><div>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.</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>2. Having several implementations of the same service type.</div><div>
If all services of the certain type implement the same calls, then something should allow to route the call to particular plugin.</div><div>The options include:</div><div> 1) passing particular service impl as a url parameter</div>
<div> 2) having a prefix in uri for certain svc type: /lb_svc/lbaas_impl1/call.json, /lb_svc/lbaas_impl2/call.json</div><div> 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</div>
</blockquote><div><br></div></div><div>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?</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>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.</div><div>Although URIs may not be so short as we want them, that could prevent from naming collisions between different service types.</div>
</blockquote><div><br></div></div><div>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.</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>3. Service Insertion:</div><div>I was thinking about routed/floating-mode insertion and there is a certain thing I don't understand: the workflow.</div><div>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.</div>
</blockquote><div><br></div></div><div>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 :)</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>So in our implementation of LBaaS the workflow was as following:</div><div>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. </div>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>2) tenant creates VIP. During this operation LBaaS chooses the most appropriate device from the list of available and makes appropriate device configuration</div></blockquote><div><br></div></div><div>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.</div>
<div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>If we're talking about workflow within Quantum it could look like following (scenario 1 - shared HW device):</div>
<div>1) admin creates the device. The same as in lbaas - address, type, credentials</div><div>2) tenant creates VIP: Quantum LBaaS plugin chooses the device, configures connectivity between the device and tenant network (possibly with l3 router configuration), </div>
<div>configures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network</div></blockquote><div><br></div></div><div>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:</div>
<div>1) using nova to plug services in quantum - which would work nicely for physical appliances</div><div>2) leveraging an underlying layer-2 agent (which would be the same thing the l3 agent does)</div><div>3) using the "provider networks" capability. This capability, in a nutshell, will allow you map a Quantum network, regardless of the technology Quantum uses.</div>
<div>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: <a href="https://blueprints.launchpad.net/quantum/+spec/quantum-network-segment-translation" target="_blank">https://blueprints.launchpad.net/quantum/+spec/quantum-network-segment-translation</a></div>
<div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>If we're talking about private balancer with Quantum, then:</div><div>1) tenant creates the device. This could be a launch of VM with HA Proxy within tenant for instance.</div>
<div>2) tenant creates VIP: LBaaS configures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network. No other actions required</div></blockquote><div><br></div></div><div>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.</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>It would be great if you explain how service assignments for routers maps to device management scenarios and what exact workflow will be. </div>
</blockquote><div><br></div></div><div>I hope my explanation is satisfactory - which basically is that service insertion and device management have nothing in common.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>Thanks,</div><div>Eugene.</div>
</blockquote></div><br></div>
</blockquote></div><br></div>