2013/10/11 Paul Michali <p...@cisco.com>: > Added several more questions inline… > > > PCM (Paul Michali) > > MAIL p...@cisco.com > IRC pcm_ (irc.freenode.net) > TW @pmichali > > On Oct 11, 2013, at 3:28 PM, Paul Michali <p...@cisco.com> wrote: > > 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? > > > 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? > 4) I take it we can specify multiple device drivers in the config file for > the agent? > > > 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. > > 5) Should I push up more general methods from IPsecDriver to DeviceDriver, > so that they can be reused by other providers? > 6) Should I push down the swan based methods from DeviceDriver to > IPsecDriver and maybe name it SwanDeviceDriver? > > > 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)? > > 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. > > 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)? > 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? > 10) If customized, is it possible to reflect the difference in allowed > values in the help strings (and client validation)? > 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? > > 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. > > > 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. 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? > 16) Is there any precedence for persisting this type of information in > OpenStack? I think we have not. > 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? IMO, each driver should handle it if the data is driver specific. Also, you can add new resource extension for a driver. > 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 Best Nachi > > Thanks! > > PCM > > > > Regards, > > > PCM (Paul Michali) > > MAIL p...@cisco.com > IRC pcm_ (irc.freenode.net) > TW @pmichali > > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
