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:
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?