Skip to content

Further define how to properly handle namespaces for app deployment #142

@ajcraig

Description

@ajcraig

Feature description

Goal: Define how to properly handle namespaces; what is in the spec right now is lacking in details to understand what is going to happen​.

Category

  • Application Description File
  • Host and run Margo apps

Provide adequate technical acceptance criteria(s) associated with this feature below:

  • Fully defined application namespace configuration and impacts
  • Improve Margo artifacts if necessary
    • Application Description
    • Device capabilities
    • Deployment specification

Although not required, it is highly encouraged to provide feature use-cases below:

  • Segmentation of multi-vendor applications on a common compute platform
  • Security boundaries
  • Enable same vendor apps to share an edge environment to enable collaboration

Additional information

There is currently some information in the specification for how namespaces should be specified, but the information is lacking because it's not explained very well. It is confusing, and there is no information about what should happen if two application vendors try to deploy their applications to the same namespace.

  • The application definition needs to be updated to be more explicit about how to specify the namespace to use
  • Expectations on the device's behavior if there is a namespace conflict need to be documented

Notes from minimum scope definition

Would it be sufficient to say that each workload/app should use its own namespace? Or is the problem a lot larger?

JT(RA) I think it is larger. I expect some applications may need to be deployed multiple times to an edge creating multiple instances with separate use case, each requiring a namespace.

Storm (SIEMENS): reverse domain name is commonly used for this, e.g., com.siemens.mega-app.instance1 where the instance1 is added by margo to the "app bundle" on incarnation to address the mutiple app case.

Armand(Margo): Namespace is included in the deployment specification. To ensure fullness of the specification I vote it is important.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    Status

    Todo

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions