Skip to content

Debt Whiteboard

Matthew Avery edited this page Jan 9, 2017 · 19 revisions

A Whiteboard for collecting engineering debt. This will get translated into a prioritization effort.

Portlayer

  • URGENTLY REQUIRES a document or a spec that defines methods, their arguments and expected return codes

Portlayer exec component needs a complete rework

  • don’t have a good way to persist handles across portlayer components
  • some handle operations (like network bind container) are executed immediately and not after Commit is called
  • event handling is haphazard; needs to be more feature rich in terms of filtering events, as well as a cleanup of which events are handled where (there are places where we handle the same event more than once)
  • hard to add more event handling for OOB operations, and hard to integrate with vm register/unregister events.

Portlayer network component:

  • Most of the data structures need to be put behind interfaces
  • IPAM code needs to be simplified
  • The VCH shouldn't be used for PAT'ing containers
  • Change interface-by-slot to interface-by-label so we can have more than 3 NICs

Logging:

  • Not consistent at all across components; we need a logging package that will enforce one logging format across components
  • Multiline logging is not supported, leading to stack traces in logs that are difficult to read
  • Use of trace.Operation instead of context.Context in API signatures; the only advantage I see right now are the logging functions, but then how do functions that don't currently use Context or Operation log? The trace.Operation object is useful, and it should be retained, but not sure it needs to so visible in our APIs

Tether:

  • Should be a complete rewrite in my opinion [hmahmood]
  • Interfaces need to be cleaned up
  • Interface implementations are scattered across several files
  • Network configuration code is difficult to follow
  • Attach/serial code is difficult to follow; at the very least needs to be reorganized
  • Needs to stop sharing the state and use alternatives (eg; channels)

DHCP client:

  • we should use an external well-tested library or command line tool, and deprecate our in-house client

vic machine

  • Should separate standard output and log. Now standard output will show all log messages, especially some message printed out by common library is misleading for customer
  • Upgrade does not have metadata migration
  • cmd and lib are not properly separated. This causes certain steps like validation to occur in a non-ideal order.

Port forwarding

  • Should leverage sudoers (at a minimum) so that the personality can run as non-root
  • Should allow us to use standard port on ESX, not 2377 (otherwise we have issues with custom VIBs, ESX stateless firewall, etc).

i18N

  • Move all customer facing output into message catalogues.

imagec

  • make image IDs and digests consistent with docker
    • Add support for schema v2 manifests
    • Leave empty layer diff IDs out of image metadata and do not show their progress output on pull

###Container Lifecycle###

  • We should draw out an architecture diagram of the different possible states and state transitions for the life of a container. This will allow us to handle or add states in the future if needed, as well as make sure we are handling state transitions appropriately.
  • We need to discuss the way we transition from state to state.
                oldState := container.SetState(StateFixing)
		        defer container.SetState(oldState)

This displays our vulnerability to race conditions with regards to state changes.