Versions Compared

Old Version 14

changes.mady.by.user Daan

Saved on

compared with

New Version Current

changes.mady.by.user Daan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

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.

Purpose

Give an administrator more flexible network solutions for virtual private clouds.

References

jira ticket CLOUDSTACK-1532

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.

Document History

Feature Specifications

An administrator must be able to choose a sdn based network for use in a vpc router gateway.

Use cases

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.

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.

Architecture and Design description

tbd

HTML Comment
hiddentrue
  • 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

As the gateway creates a network and the network offering for a nicira based network has a different 'Connectivity' provider then the default, a network offering must be passed as an optional argument to the createVpcGateway api call. This will be added by uuid.

The api call now accepts an vlanid. it must be loosened to also accept a broadcastUri, i.e. lswitch:<a-uuid-of-some-sort>. It makes sense to then also let it accept vlan://<number>.

DB changes

no changes are strictly needed.

It may be wise to change some columns in name and in some cases in type from 'vlan' to 'broadcast_uri'.

In the long run it makes sense too remove broadcastDomainType fields from tables that have a broadcastUri as it is encoded in it. This must be decided on a case by case basis.

UI flow

Appendix

Appendix A:

Appendix B: