Owner: Architect:

Martin Mulholland

Story (Required)

As a Primaza Administrator, I would like to easily set up Applications and Services namespaces so that I can discover services and bind them to applications.

Background (Required)

Primazactl creates namespace, service accounts, role binding and roles, and secret names  which are subject to the new naming convention and will require updates.

Glossary

<List of new terms and definition used in this story>

Out of scope

Updating primaza

In Scope

Updating primazactl

Approach(Required)

Currently promazactl use kubectl apply to apply manifest files with a hardcoded namespace and resource names. Resource names in the manifest may be updated by primaza (or maybe not) but the namespace has to be set by primazactl. To enable this primazactl must:

1. Add namespace input (tenant) for all primazactl commands.
2. Read manifest to be applied and split it into the individual resources.
3. For each resource:
   1. If needed: modify the namespace value in the resource.
   2. If needed modify the resource name value to include cluster name, namespace, user and/or environment in the name.
   3. Use the kubernetes api to apply the resource.

Primazactl also creates service account, secrets, roles, and rolebindings which must adhere to the new naming convention.

This will also remove the dependency primazactl has on kubectl.

Eventually naming convention should be defined in config file which primazactl reads an adopts at build time, must allow for this in code created.

Demo requirements(Required)

Demo would show setting the namespace name to use in prmazactl.

Dependencies

Dependent on naming convention to be finalized.  

Edge Case

Duplicate resources which may indicate an issue.

Resource names getting too long.

Acceptance Criteria

_<Provides a required and minimum list of acceptance tests for this story.
More is expected as the engineer implements this story>_

Development: primazactl adheres to new naming convention.

QE: Add tests for new namespace flag.

Documentation: Yes

Upstream: <Inputs/Requirement details: Concept/Procedure>/ Not
Applicable

Downstream: <Inputs/Requirement details: Concept/Procedure>/ Not
Applicable

Release Notes Type: <New Feature/Enhancement/Known Issue/Bug
fix/Breaking change/Deprecated Functionality/Technology Preview>

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

v

Legend

Unknown

Verified

Unsatisfied