[Feature request] Omnia Modernization

[j0hnL]

After chatting with @richardhenwood-dell about the idea of an API he got me thinking. Today operating an Omnia cluster means SSHing to the OIM, editing files under input/, and running ansible-playbook which makes it hard to drive Omnia from CI/CD, monitoring webhooks, or portals, and leaves no job history or audit trail.

We might consider developing an optional omnia-api container in the OIM stack exposing the existing playbooks through a REST API (perhaps via ansible-runner), with async jobs and a published OpenAPI spec. The playbooks stay the implementation and the current workflow keeps working unchanged.

What do others think? @i3igpete @lwilson @sujit-jadhav

[richardhenwood-dell]

Hi John, This is an excellent discussion topic and echo's some thoughts the team have shared with me.

For me, the design principle I am favorable to is: Omnia is a daemon-less tool. i.e. we are making something that is like kubectl** or systemctl. We can view Omnia as the tool that you need to simplify orchestration and operation of loosely coupled services (OpenLDAP, OpenChami etc) that are used to bring up the cluster. The existing omnia.sh design follows this pattern (but there is more that can be done).

I this it is a good time to review Omnia design and UI. RESTful API design principles are an excellent choice. However, I would be concerned that we may be pursuing an architecture enhancement when we can deliver more User value (and address the shortcomings) with a different approach.

My current thinking is then:

• Start a UI design exercise, based on RESTful principles.
• Implement the new UI as a CLI first, something like kubectl: omnia <noun> <verb> -o json
• If a RESTful API is needed, this becomes a layer on top of the CLI.

PS. The requirement to ssh (or exec) into the container today is, in my opinion, awkward and we should remove it. If ssh access is required, we should provide a recipe to run Omnia in a container/proxmox/baremetal/qemu etc.

** I recognise that kubectl is in practice a thin layer calling a daemon - but my argument here is that we should invest in our User Interface CLI first - not making Omnia a daemon.

[RvishankarOMnia]

Thank you, John & Richard, for starting this discussion. We are moving towards restructuring Omnia Architecture to support service oriented multi repo Model. As a starter, here is the deck that provide the approach and high-level

OmniaNXTv1.pptx

plan.

[abhishek-sa1]

Changes related to issue are available in https://github.com/dell/omnia/tree/issue-4849-omnia-modernization