Bug Reference

https://issues.apache.org/jira/browse/CLOUDSTACK-1532

Branch

No branch. a patch is submitted through Review Request #10970

Introduction

Currently a VPC private gateway interface can be plugged on a specific VLAN. We like to see the possibility to specify a Nicira NVP logical switch instead of a VLAN.

One of the use cases we have for this is VPC <-> VPC connectivity (routing) within the logical space of NVP.
This functionality should then be combined with the possibility to specify more then one route on the virtual private gateway for multiple peer networks, this gives us a better manageable environment for customer networks.

Related work is nTier Apps 2.0 Features, however in this work it is choosen to add multiple gateways to a VPC, which will result in the number of interfaces on the VPC router running out. Preferably would be to add multiple routes to a single (or one of the) gateway(s). This is a new issue however.

Purpose

The picture above speaks for itself. The vpc gateways are plugged into a lswitch on NiciraNvp. In addition to that they are on the same logical switch, which in ACS terms means they are on the same network. In cloudstack, therefore, a check must be created that checks if the net a vpc switch is plugged on is an lswitch. If it is it must not refuse to create the gateway when the network allready exists, as it does now. see multiple vpc gateways on the same network for this.

References

Document History

Glossary

Feature Specifications

Assumptions / Pre-requisites

Use cases

Architecture and Design description

• quality risks (test guidelines)
  • functional
  • non functional: performance, scalability, stability, overload scenarios, etc
  • corner cases and boundary conditions
  • negative usage scenarios
• specify supportability characteristics:
  • what new logging (or at least the important one) is introduced
  • how to debug and troubleshoot
  • what are the audit events 
  • list JMX interfaces
  • graceful failure and recovery scenarios
  • possible fallback or work around route if feature does not work as expected, if those workarounds do exist ofcourse.
  • if feature depends other run-time environment related requirements, provide sanity check list for support people to run
• explain configuration characteristics:
  • configuration parameters or files introduced/changed
  • branding parameters or files introduced/changed
  • highlight parameters for performance tweaking
  • highlight how installation/upgrade scenarios change
• deployment requirements (fresh install vs. upgrade) if any
• system requirements: memory, CPU, desk space, etc
• interoperability and compatibility requirements:
  • OS
  • xenserver, hypervisors
  • storage, networks, other
• list localization and internationalization specifications 
• explain the impact and possible upgrade/migration solution introduced by the feature 
• explain performance & scalability implications when feature is used from small scale to large scale
• explain security specifications
  • list your evaluation of possible security attacks against the feature and the answers in your design* *
• explain marketing specifications
• explain levels or types of users communities of this feature (e.g. admin, user, etc)

Web Services APIs

DB changes

Phased implementation for VMware

UI flow

Appendix

Appendix A:

Appendix B: