Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
    • Contribute to GitLab
  • Sign in
N
nrm
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 16
    • Issues 16
    • List
    • Boards
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • argo
  • nrm
  • Issues
  • #1

Closed
Open
Opened Dec 07, 2017 by Swann Perarnau@perarnau11 of 11 tasks completed11/11 tasks
  • Report abuse
  • New issue
Report abuse New issue

Implement control API

We need to flesh out an upstream API to allow the NRM to be controlled from other software.

We have at least two clients of this API in mind:

  • GRM/Flux: to send resource requests, and launch jobs
  • a CLI client, to launch containers and other stuff interactively

There are several factors that make an pub/sub interface a good idea there:

  • GRM wants to request changes in resources in an asynchronous, idempotent way. This is for scaling and coupling reasons. As such, GRM acts as a publisher, and the NRM as a subscriber.
  • Flux will need to be interfaced by listening to events on the Flux bus, so Flux will be a publisher and NRM subscriber also.
  • while the CLI client could follow a more typicall REQ/REP pattern, if we need to send back to the client the stdout/stderr from the container, we probably want to also have a publisher socket.
  • This is also the case for Flux, that expects events to be published for stdout/stderr.
    Those constraints push us to have:
  • a SUB socket to listen for commands
  • a PUB socket to respond to those commands, forward data on current events

The TODO for this issue are:

  • Add pub/sub sockets for this API
  • Add callback to event loop to capture messages on those sockets
  • Implement basic command manager, to keep track of non-completed commands
  • Implement basic commands handling for:
    • run container
    • list container
    • kill container
    • send acks to API clients
    • send results to API clients
  • Implement basic CLI binary to test the commands
  • Merge draft power control API into this facility
Edited Dec 15, 2017 by Swann Perarnau
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
0
Labels
None
Assign labels
  • View project labels
Reference: argo/nrm#1