Open Stack

2013/10/11 Paul Michali <pcm at cisco.com>:
> Added several more questions inline…
>
>
> PCM (Paul Michali)
>
> MAIL pcm at cisco.com
> IRC   pcm_  (irc.freenode.net)
> TW   @pmichali
>
> On Oct 11, 2013, at 3:28 PM, Paul Michali <pcm at 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 pcm at cisco.com
> IRC   pcm_  (irc.freenode.net)
> TW   @pmichali
>
>