Skip to content

Add high-level placement registrar for installer workflows #446

@mesilov

Description

@mesilov

Problem

The SDK already provides low-level placement operations (placement.bind, placement.unbind, placement.get) and typed IM helpers such as bindTextarea(), but installer code still has to orchestrate placement registration manually.

In practice this makes installer code more fragile than event handler registration. A typical installer flow wants to declare a small set of placements and register them in one place, similar to eventManager()->bindEventHandlers([...]).

A concrete example from an application installer:

  • bind ONAPPINSTALL / ONAPPUNINSTALL via bindEventHandlers([...])
  • bind IM_TEXTAREA placement separately via bindTextarea(...)

The second step is much more awkward:

  • there is no high-level bulk/helper API
  • installer code must decide when to call bind, get, or unbind
  • repeated install/reinstall flows can hit REST errors such as ERROR_CORE: Unable to set placement handler: Handler already binded

So the SDK has typed placement primitives, but no installer-oriented abstraction for declaring and synchronizing placement handlers.

Proposed solution

Add a high-level placement registration service/helper for installer workflows, similar in spirit to bindEventHandlers([...]).

Possible shape:

  • a metadata DTO for placement declarations, similar to EventHandlerMetadata
  • a registrar service that accepts a list of placement declarations
  • internally it can use placement.get to inspect current state
  • if a placement is already bound to the same handler/configuration, it should skip it
  • if a placement is bound but needs to be changed, it can decide whether to unbind+bind or expose that policy explicitly
  • return a structured result describing which placements were bound, skipped, updated, or failed

This would make installer code much simpler and reduce repeated boilerplate around placement registration.

Acceptance criteria

  • The SDK exposes a high-level API for registering one or more placements in installer code
  • The API is ergonomic in the same way bindEventHandlers([...]) is ergonomic for event handlers
  • Re-running the same installer flow does not fail just because a placement is already registered with the same handler
  • The result of registration clearly reports whether each placement was created, skipped, updated, or failed
  • The feature is covered by tests and documented with an installer-oriented example

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions