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
  • #2

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

API access to Openstack for WFAs *and* controller

Both the WFAs and controller need some kind of API access to Openstack to support real reset (that reboots a VM), and createVM. Think carefully about relationship between capabilities and the Openstack security mechanisms. We should consider if we can just wrap and proxy full API access to any service in a reasonable way, or if we have to special-case everything. Obviously the former is ideal... but proxying all API calls over the capability protocol isn't going to be super nice. We'll certainly need protocol support for ack'd packet fragments, because the raw cap proto can't do more than an MTU right now. Sigh...

Again, this is a combination of @joshkunz and @johnsond .

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