See @PCM in-line… PCM (Paul Michali)
MAIL p...@cisco.com IRC pcm_ (irc.freenode.net) TW @pmichali On Oct 12, 2013, at 5:04 PM, Eugene Nikanorov <enikano...@mirantis.com> wrote: > Hi folks, > > > 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. > > This is seems to be a multilayered feature that needs to be discussed. > Mark McClain will be speaking about vendor cli extensions in > http://summit.openstack.org/cfp/details/10. > It require API counterpart on server side. I was planning to speak about this > in this session: > http://summit.openstack.org/cfp/details/22 > Feel free to add your suggestions to theether pad. @PCM Thanks Eugene! I saw Mark's previously, but it didn't seem to have much in it. I had created a session suggestion this morning: http://summit.openstack.org/cfp/details/230 and then added a comment that maybe it could be combined (added to) with others like yours (or maybe yours covers it all :) > > more specifically: > > 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)? > I think it should be an additional extension mechanism different from the > framework that we're using right now. > Service plugin should gather extended resources or attribute maps from > supported drivers and return them to the layer that will make wsgi > controllers for the collections. So it should be pretty much the same as > extension framework but instead of loading common extensions, it should load > resources from the service plugin. > @PCM That's a great idea and would be good to discuss more. Regards, PCM > > Thanks, > Eugene. > > > On Sat, Oct 12, 2013 at 1:40 AM, Nachi Ueno <na...@ntti3.com> wrote: > Hi Paul > > 2013/10/11 Paul Michali <p...@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. > > > > > 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. > > > 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) > > > 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. > > > 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. > > > 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. > > Best > Nachi > > > > > 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 >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
