Houdini License Server Not Running Mac

[Samantha Figueredo]

It looks like the instructions for configuring the help server are telling me to set and env variable that tells houdini to look for python scripts where none exist. There is either something wrong with my install, or the help server is out of date. I tried redirecting the help server to the actual python paths that do exist under the houdini resources folders, but thats when the lxml issues come up. I imagine that if lxml were a critical part of running the help server, it would be installed already, no? I am just trying to find a way to run the houdini help server in a way that the port is the same every time - because when houdini crashes and i restart it, i already have some help cards open in my browser, and they become broken, because a new port # is used after relaunching houdini.

First of all. Why are interested in running a central help-server on a single workstation? Second, I'm not sure if lxml is bundled with Houdini but when I had trouble launching the help from within Houdini 11 under Linux. SideFx Support suggested I should install lxml systemwide. Furthermore, why do you modify the houdini_setup-scripts? Creating a .bashrc file in your $HOME-directory gives you more flexibility when you need to install a new build.

I want to run a standalone Houdini help server primarly because EVERY time houdini crashes, or has to be restarted, ALL of the help cards I have open in my browser become broken links, and also any example files I wish to load become broken links.

I'm afraid that I'm unable to give you any recommendations since I don't run Houdini under Mac OS X on a regular basis and the help page that "old school" points to does not specify how to set up an external help server under OS X but you could try to use the Linux BASH shell instructions.

New ftrack user here trying to get started. I installed ftrack connect on OS X 10.10.3, entered the server, user, and api key information and I get a rather nondescript error saying "Failed to connect to event server at URL" where SERVER URL is my ftrack url.

I'm not behind a firewall or anything and I've tried from multiple internet connections. I verified that I can login via the website with the same credentials, but Connect isn't, well, connecting, from the desktop.

PS: I installed connect on a different machine without proxy (via a freshly downloaded "ftrack-connect-package-0.2.0-amd64.msi" file) and it says in the about-window "Version: 0.1.10". That's probably just a mistake, but adds to the confusion.

I'm guessing the issue has something to do with when the panel is being built because when I create the python panel again by going to New Pane Tab Type> Python Panel> mb_MMM it queries the ftrack servers successfully and correctly builds the panel tab.

I should mention that I'm still on connect 0.7.6. Will updating to 1.0.1 solve this problem? I've tried updating before and ran into some different issues which are preventing me from properly testing. So I'm hesitant to move on while some bugs are still prevalent in this version of my pipeline.

Hi @Mike, is hard to tell without more debug information, but could be related to the ssl library shipped with the python version embedded with houdini.
Can you please provide what houdini and python version are you using ?
If you have a chance please try to see using a different interpreter whether does help.

I did some digging and found that some of my ftrack env variables point to paths that no longer exist due to the updated connect folder structure. I'll make some changes and will let you know how it goes.

Just trying to figure this out as Im running out of options. Running Deadline latest version, Deadline works fine on Maya and Nuke jobs, on multiple workers (which have licensing set to free, up to 10). I have 3 machines.

Im not sure what the issue might be, everything seems properly setup since all other apps work fine. Houdini as a plugin is properly setup (plugin configuration is setup properly for houdini 18.5 pointing at the correct paths). This is linux based.

at Deadline.Plugins.SandboxedPlugin.d(DeadlineMessage beg, CancellationToken beh)
at Deadline.Plugins.SandboxedPlugin.RenderTask(Task task, CancellationToken cancellationToken)
at Deadline.Slaves.SlaveRenderThread.c(TaskLogWriter aiy, CancellationToken aiz)

I was able to confirm that the local Nucleus Service was successfully linked.But I can access the local Nucleus server by opening the folder view through houdini and I can create folders normally

I just tried to save a fresh scene using the ov save hip button. and it shows up in the Nucleus browser and the windows/documents/Omniverse folder. So the two are definitely connected.
Is this perhaps why the ROP has trouble creating folders during export?

I have 19.5.640 because of Redshift.
I will try the new Production build, but I have so many issues right now with Create that this might take a while. Tutorial videos and Docs seem to be not up to date in many cases. It is very hard to trouble shoot.

NOTE: Windows containers are currently not supported and Darwin does not have native containers. Steps will run inside a temporary directory on the Windows/Darwin worker. Any dependencies needed for your tasks (e.g. git, .NET, golang, ssh) should be pre-installed on the worker. Windows/Darwin workers do not come with any resource types.

Bandwidth usage: again, almost entirely subject to pipeline workloads. Expect spikes from periodic checking, though the intervals should spread out over enough time. Resource fetching and pushing will also use arbitrary bandwidth.

Disk usage: arbitrary data will be written as builds run, and resource caches will be kept and garbage collected on their own life cycle. We suggest going for a larger disk size if it's not too much trouble. All state on disk must not outlive the worker itself; it is all ephemeral. If the worker is re-created (i.e. fresh VM/container and all processes were killed), it should be brought back with an empty disk.

Horizontally scalable: yes; workers directly correlate to your capacity required by however many pipelines, resources, and in-flight builds you want to run. It makes sense to scale them up and down with demand.

The worker nodes are designed to be stateless and as interchangeable as possible. Tasks and Resources bring their own Docker images, so you should never have to install dependencies on the worker. Windows and Darwin workers are the exception to this. Any dependencies should be pre-installed on Windows and Darwin workers.

In Concourse, all important data is represented by Resources, so the workers themselves are dispensible. Any data in the work-dir is ephemeral and should go away when the worker machine is removed - it should not be persisted between worker VM or container re-creates.

More workers should be added to accommodate more pipelines. To know when this is necessary you should probably set up Metrics and keep an eye on container counts. If average container count starts to approach 200 or so per worker, you should probably add another worker. Load average is another metric to keep an eye on.

Note: it doesn't make sense to run multiple workers on one machine since they'll both be contending for the same physical resources. Workers should be given their own VMs or physical machines to maximize resource usage.

The answer to whether you should scale your workers horizontally or vertically depends heavily on what workloads your pipelines are running. Anecdotally though, we have seen that a lot of smaller workers (horizontal scaling) is usually better than a few large workers (vertical scaling).

Workers will continuously heartbeat to the Concourse cluster in order to remain registered and healthy. If a worker hasn't checked in after a while, possibly due to a network error, being overloaded, or having crashed, the web node will transition its state to stalled and new workloads will not be scheduled on that worker until it recovers.

A safer way to restart a worker is to land it by sending SIGUSR1 to the worker process. This will switch the worker to the landing state and Concourse will stop scheduling new work on it. When all builds running on the worker have finished, the process will exit.

When a worker machine is going away, it should be retired. This is similar to landing, except at the end the worker is completely unregistered, along with its volumes and containers. This should be done when a worker's VM or container is being destroyed.

To retire a worker, send SIGUSR2 to the worker process. This will switch the worker to retiring state, and Concourse will stop scheduling new work on it. When all builds running on the worker have finished, the worker will be removed and the worker process will exit.

c80f0f1006