Is the sdk/runtime for omni.services actually "farm" rather than "kit"?

Again, I’m throwing this in development because I can’t really find an appropriate place for something that’s just about microservices.

I’ve been trying to get my head around simple microservices development for a while. First I found that the earliest versions of “code” don’t ship with the appropriate extensions. (another post/thread revealed that for me) Getting databse manager extension to show up in code - Apps / Code - NVIDIA Developer Forums

More recently I tried just creating an extension and linking it to “kit.” Thinking that kit almost certainly does ship with them as “kit” seems to be the equivalent of the sdk/runtime. That didn’t work so well. So I went back to basics.

I’ll reference the documentation here:

Getting started — Omniverse Microservices documentation (nvidia.com)

Getting started suggests you can just run “kit --exec hello_world.py --enable omni.services.core --enable omni.services.transport.server.http” and all should be well. Assuming the dirt simple python script or equivalent is sitting in the directory. However, this didn’t work for me.

I uninstalled and reinstalled kit from launcher to be sure. But at least on my system, there does not seem to be any omni.services.* extensions installed as part of kit. Indeed, they’re not anywhere I can find them in the dir structure. And kit doesn’t seem to do any magic thing to pull them down.

Tell all console log:

2022-07-07 16:11:50 [356ms] [Error] [omni.ext.plugin] Failed to resolve extension dependencies. Failure hints:
        Can't find extension with name: omni.services.core
 Available versions:
         (none found)
        Can't find extension with name: omni.services.server.http
 Available versions:
         (none found)

2022-07-07 16:11:50 [356ms] [Error] [omni.ext.plugin] Exiting app because of dependency solver failure...
2022-07-07 16:11:50 [357ms] [Error] [carb.scripting-python.plugin] ModuleNotFoundError: No module named 'omni.services'

It’s unclear to me if kit is supposed to magically pull these down from some publicly available nvidia repository somewhere. Or whether the extensions would need to effectively be statically provided as part of the kit’s extensions directories upon deployment. But I’m guessing it’s the latter. Much as the earlier version of “code” didn’t have the omni.services.* extensions bundled, this version of kit, doesn’t either.

I was thinking I was going mad. But then I happened upon this repo which is a companion to the “deep dive” video:

GitHub - NVIDIA-Omniverse/deep-dive-into-microservices: Companion code for the GTC 2021 session on “A Deep Dive into Building Microservices with Omniverse”.

of note is the following specific line from “executing the sample:”

REM Launch Create, with the extension enabled:
app/omni.create.bat ^
    --ext-folder C:\Users\<username>\AppData\Local\ov\pkg\farm-queue-102.1.0\exts-farm-queue ^
    --ext-folder ./exts ^
    --enable omni.services.assets.convert

for context, please understand this is to be run AFTER linking the extension to “create”. So this command-line means, run create’s bundled “kit” but cross link in the extensions from farm-queue.

This suggests that, the correct place to acquire the omni.services.* extensions is actually from an install of farm-queue.

And it’s true, the extensions are in there.

My question is: does this mean that the actual runtime/sdk for omni.services.* isn’t the default “kit” one gets form launcher, nor is it “create”, but is instead “Farm Queue” from launcher?

If so, why exactly? And why isn’t this made clear anywhere? I’d have thought it would at least be Farm-Agent. Farm-Queue is only meant to be installed on machines that are managing a work queue. And there’s no reason to assume a Farm-Queue is doing anything other than managing the queue. You’d think it would be the workers, running Farm-Agent that would provide heavy processing services of sorts, if you were to assume something.

But really, that doesn’t make any sense either. Since, Farm-Agent just wants to be pointed to an executable and doesn’t want to know about any particular extensions used within the jobs it’s launching.

Again, the “getting started” docs say:

Using the omni.services extensions and Omniverse Kit’s –exec command-line option makes it easy to
get started with services. As the service evolves and grows it might be worth turning the service itself
into an Extension so that it is easy to ship and distribute. Doing so will also give all the power of extensions
to services with the possibilities to set up dependencies on other extensions, install additional python
packages and take advantage of the settings framework.

but that seems to conflict with the only functioning documented example I can find, which instead requires cross linking with farm-queue. The other examples I can find are bundled into the “cache” app, which seems to be a native windows exe, and not kit based?

Hi @brad_f. This forum is the right place to ask about microservices. Microservices are really just a subset of Extensions.

Things are quickly progressing and the team is working on refreshing the documentation. Code is the best “IDE” to start developing your microservices against. I’ve created a tutorial video that will help you get started and clear up most of the questions that you’ve posed here.

This will likely be a follow-up video you’ll want to watch:

I’d point out that at 2:52, when you are listing the contents of code’s extension cache, you can see that many of the omni.services.* packages are missing. e.g. the database manager facility:

omni.services.facilities.database.manager

… is not listed. Probably because it’s not a dependency for any of the microservices examples that are included in this version of code. And in my experience, adding that extension as “enabled” directly, or as a dependency, won’t result in it being pulled down. Not to my system anyway. Should it be? Or are we limited to the omni.services.* extensions that happen to be dependencies of the included examples?

Also, to be clear: I can’t link the extension to kit (currently 103.1.2), and expect it to run correct (assuming I fix the pathing)? Because, it simply does not contain any of the omni.services.* extensions?

Which gets me back to the original question. The only place I can find a full set of omni.services.* extensions is in farm-queue. Is that intentional? Or is something broken on my end?

I see. Someone from the microservices team will jump in here and help give you a path forward.

Hi Brad,

Sorry for the delay in getting back to you, things are a little hectic with Siggraph coming up.

You are right, the majority of the omni.services extensions are not shipped with the Kit SDK, they used to be but to improve startup and size we have removed them and have been shipping them where necessary (OV Farm, which still uses the Kit runtime but has an additional folder with all of the needed extensions) and in Code.

We ideally would prefer you not having to depend on Create, Code or Farm to write the services and we are in the process of pushing these extensions to a public registry so you can grab them from there.
I hope to have that sorted out early next week and will reply here with the instructions (as well as update our documentation).

Sorry for the hassle, we’ll get this sorted on our end.

Thanks,
Jozef

Hi @brad_f we have pushed all of the service based extensions to public registry.

You can now use the default kit-sdk and enable that registry to get access to those extensions by adding the following flags to your commandline: --/exts/omni.kit.registry.nucleus/registries/0/name=kit/services --/exts/omni.kit.registry.nucleus/registries/0/url=https://dw290v42wisod.cloudfront.net/exts/kit/services

Or adding the registry to your service apps .kit file or adding it via the extension manager.

For example if you save this to a hello_world.py file:

from omni.services.core import main

def hello_world():
  return "hello world"

main.register_endpoint("get", "/hello-world", hello_world)

And then run:

kit --exec service.py --enable omni.services.core --enable omni.services.transport.server.http --/exts/omni.kit.registry.nucleus/registries/0/name=kit/services --/exts/omni.kit.registry.nucleus/registries/0/url=https://dw290v42wisod.cloudfront.net/exts/kit/services

That’ll make sure the extensions are found and downloaded.
Let us know if we can help in any other way.

Thanks,
Jozef

That sounds great. It’s more inline with kit and makes sense. I’ll give it a try this weekend and report back any issues if they crop up.

Yup. That seems to work at a surface level. I can browse and see the database facility and the like now, from within kit.

Below is the default kit mini app showing as such.

Thanks!

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.