Open Stack

Thanks for the responses Nachi! I combined them into one message. See @PCM inline…


PCM (Paul Michali)

MAIL pcm at cisco.com
IRC   pcm_  (irc.freenode.net)
TW   @pmichali

On Oct 11, 2013, at 5:40 PM, Nachi Ueno <nachi at ntti3.com> wrote:

> Hi Paul
> 
> 2013/10/11 Paul Michali <pcm at cisco.com>:
>> Hi folks,
>> 
>> I have a bunch of questions for you on VPNaaS in specific, and services in
>> general...
>> 
>> Nachi,
>> 
>> 1) You hd a bug fix to do service provider framework support for VPN
>> (41827). It was held for Icehouse. Is that pretty much a working patch?
>> 2) When are you planning on reopening the review?
> 
> I'm not sure it will work without rebase.
> I'll rebase, and test it again in next week.

@PCM Thanks! I did pull new Neutron code and then patched in the code and it seems to be working fine, BTW.


> 
>> 
>> Anyone,
>> 
>> I see that there is an agent.py file for VPN that has a main() and it starts
>> up an L3 agent, specifying the VPNAgent class (in same file).
>> 
>> 3) How does this file get invoked? IOW how does the main() get invoked?
> 
> we should use neutron-vpn-agent command to run vpn-agent.
> This command invoke vpn agent class.
> It is defined setup.cnf
> 
> https://github.com/openstack/neutron/blob/master/setup.cfg#L98
> 
>> 4) I take it we can specify multiple device drivers in the config file for
>> the agent?
> 
> Yes.
> 
>> 
>> Currently, for the reference device driver, the hierarchy is currently
>> DeviceDriver [ABC] -> IPsecDriver [Swan based logic] -> OpenSwanDriver [one
>> function, OpenSwan specific]. The ABC has a specific set of APIs. Wondering
>> how to incorporate provider based device drivers.
> 
> It is designed when we know only one swan based driver.
> so It won't fit with another device drivers.
> if so, You can also extend or modify DeviceDriver also.
> 
>> 5) Should I push up more general methods from IPsecDriver to DeviceDriver,
>> so that they can be reused by other providers?
> 
> That's woud be great
> 
>> 6) Should I push down the swan based methods from DeviceDriver to
>> IPsecDriver and maybe name it SwanDeviceDriver?
> 
> yes
> 
>> 
>> I see that vpnaas.py is an extension for VPN that defines attributes and the
>> base plugin functions.
>> 
>> 7) If a provider as additional attributes (can't think of any yet), how can
>> the attribute be extended, only for that provider (or is that the wrong way
>> to handle this)?
> 
> You can extend existing extension.

@PCM Would like more info on how to do that. Any examples? Would the attribute be static, always available (versus, only being available when a certain provider is selected)?


> 
>> For VPN, there are several attributes, each with varying ranges of values
>> allowed. This is reflected in the CLI help messages, the database (e.g.
>> enums), and is validated (some) in the client code and in the VPN service.
> 
> Chaining existing attributes may be challenging on client side.
> But let's discuss this with a concrete example.
> 
>> 8) How do we provide different limits/allowed values for attributes, for a
>> specific provider (e.g. let's say the provider supports or doesn't support
>> an encryption method, or doesn't support IKE v1 or v2)?
> 
> Driver can throw unsupported exception. ( It is not defined yet)

@PCM Yeah, I was figuring at execution time we could reject the selection, but I'm wondering if we can be proactive and not show the option in the help and maybe validate it at the client side.  The other side of this (and probably worse) is if a provider supports more options than the reference VPN. The new value would be hidden from the help, and we have the added value that the database is not set up to allow the value (say an emu is being used).

I have an example, and that is of a provider (yet) not supporting (via programatic interface) IKE v2. Not sure if this is a good example though, as, for VPN, it seems like the IKE and IPSec policies, are they not associated with the provider, right? If that is the case, then how do we handle the case where a provider has a limitation (in this case) or more capabilities than the reference VPN?

 
> 
>> 9) Should the code be changed not to do any client validation, and to have
>> generic help, so that different values could be provided, or is there a way
>> to customize this based on provider?
> 
> That's could be one way.
> 
>> 10) If customized, is it possible to reflect the difference in allowed
>> values in the help strings (and client validation)?
> 
> May be, server side can tell the client "hey I'm supporting this set of values"
> Then client can use it as the help string.
> # This change may need bp.

@PCM That was what I was thinking… having an API that the client can use to determine the server's capabilities. Was thinking of that for a summit session, but not sure how the community feels about doing something like that, and whether the complexity is worth the effort.  Mark? Kyle?

I had similar thoughts about that info be using for the attribute values, to handle the case where a provider handles more or less than what the reference version handles. Granted, there are complications, like the IKE and IPSec policies, which don't seem to be related to the provider.  

Obviously, this architecture issue applies to other service providers.


> 
>> 11) How do we handle the variation in the database (e.g. when enums
>> specifying a fixed set of values)? Do we need to change the database to be
>> more generic (strings and ints) or do we somehow extend the database?
> 
> more than one driver will use same DB.
> so I'm +1 for generic db structure if it is really needed.

@PCM Yeah, I see the potential problem (as providers add support, enums could pose problems). But, I don't have a case of it right now, so it is likely a case of YAGNI(you aren't gonna need it), and we should deal with it, when it happens. I just hope I don't see it next week :)



> 
>> I was wondering in general how providers can customize service features,
>> based on their capabilities (better or worse than reference). I could create
>> a Summit session topic on this, but wanted to know if this is something that
>> has already been addressed or if a different architectural approach has
>> already been defined.
> 
> AFIK, That's new challenge.
> I think LB team and FW team is facing same issue.
> For the RPC, I see there is an IPSEC_DRIVER_TOPIC and IPSEC_AGENT_TOPIC,
>> each of which gets the host appended to the end.
>> 
>> 12) For a provider, I'm assuming I'd create a provider specific topic name?
> 
> Yes.
> 
>> 13) Is there any convention to the naming of the topics?
>> <svc>_<provider>_<type>.<host>?
> 
> It is not discussed yet, but your example makes sense.
> 
>> 14) Is it just be, or is it just a bit misleading with the agent topic name?
>> Seems like the RPCs are all between the service and device drivers.
>> 
>> In Icehouse, we're talking about other protocols for VPN, like SSL-VPN,
>> MPLS/BGP.
> 
> I'm not sure I get this question.

@PCM Sorry. I wasn't real clear. What I see is a service driver and a device driver. For RPCs sent from the service driver to the device driver, it looks like it uses IPSEC_AGENT_TOPIC, and RPCs from the device driver to the service driver use the IPSEC_DRIVER_TOPIC.  I see the VPNAgent creating all the device drivers, but other than that, I don't seem to see the "agent" involved in any interactions. So, seeing the IPSEC_AGENT_TOPIC, seemed misleading/confusing to me.  I guess I was thinking more of these being service and device topics.  Maybe I'm missing something?


> IMO, each driver will use unique topic, then we can handle multiple protocols.
> 
>> 15) Has anyone thought about the class naming for the service/device
>> drivers, and the RPC topics, or will it be a totally separate hierarchy?
>> 
>> 
>> On the underlying provider device, there could be a case where a mapping is
>> needed. For example, the VPN connection UUID may need to be mapped to a
>> Tunnel number.
> 
> What's this tunnel number?

@PCM For a Cisco router, the VPN connection would (for example) occur over a tunnel. On the device the tunnels are numbered, so you may have tunnel1, tunnel2, etc. These tunnels would correspond to the OpenStack VPN connections, which are identified by UUIDs. 

> 
>> 16) Is there any precedence for persisting this type of information in
>> OpenStack?
> 
> I think we have not.

@PCM Because of the tunnel/UUID difference, I'm thinking mapping is needed and some persistence of that mapping (or some complicated syncing of information).  I was hoping there was some other case where this type of mapping is needed.


> 
>> 17) Would the device driver send that back up to the plugin, or is there
>> some way to persist at the driver level?
>> 
>> I'm probably going to use a REST API in the device driver to talk to the
>> provider process (in a VM).
> 
> You mean data persistence?

@PCM No, in Q#17, I'm talking about the mapping of tunnels to VPN connection UUIDs.  If the mapping is needed, I can see hacky ways to deal with it, other than persisting, but was hoping there is a way to persist that mapping and how it could be done.


> IMO, each driver should handle it if the data is driver specific.
> Also, you can add new resource extension for a driver.

@PCM Can you elaborate on the "resource extension"?  I'm looking for how to persist some configuration information in OpenStack, for the device.


> 
>> 18) Are there any libraries in Neutron for REST API client that I can use
>> (versus rolling my own)?
> 
> python-neutronclient is the client library. It's not only for CLI :P

@PCM Not talking about the client API. I'm talking about the API that will be used by the device driver to talk to the device. For the VPN reference this is config files and commands that are invoked, but for the provider I'm thinking of using the REST API that the device provides (versus NETCONF). Wondering if there is something that is commonly used, or do I just use the Request/urllib2/httplib2 package for this?


Thanks!

PCM


> 
> Best
> Nachi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131012/c25705a8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131012/c25705a8/attachment.pgp>