Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
C
capnet
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 18
    • Issues 18
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 1
    • Merge Requests 1
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • tcloud
  • capnet
  • Issues
  • #1

Closed
Open
Opened May 12, 2016 by David Johnson@johnsondMaintainer

Handle port_delete OF events

This is quite complicated... we need to handle port-flap events, or worse things where a VM reboots and then gets plugged into a different ofport. What do we call a flap, vs a time to revoke all caps owned by that port, or to that port? Stuff like that. Do we keep a shadow copy of switch, port, and node objects that is detached from the mul (OF) objects when they temporarily disappear, and then "reconnect" them when they reappear? We also need to add liveness information to these objects so that if people perform cap ops on a node cap they hold to a node that actually has gone away, we can deal with it. Same with flows...

This is a combination of @johnsond and @joshkunz ...

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: tcloud/capnet#1