CGRU / cgru

CGRU - AFANASY
http://cgru.info/
GNU Lesser General Public License v3.0
278 stars 111 forks source link

self.taskInfo in nuke.py ( service.py ) #562

Closed eberrippe closed 3 weeks ago

eberrippe commented 1 year ago

Hi Timur, Jan here from Rise.fx

We introduced the Tickets called "threads" to regulate the amount of threads nuke is started with "nuke -m ....... ".

To modify the starting commands of a task we change it in the nuke.py service and overwrite the "def getCommand(self)" method returning the modified command.

Problem is, that we can not get the amount of tickets of the block in the services.self.taskInfo, because the ticket information is not inside.

Our secound Idea is to use the capacity, but also the self.taskInfo.get("capacity") always stays 0L.

Is this intended? When I look in a tasks json I can see the tickets and also the correct capacity.

If its intended, what would you recommend us to realize this feature with?

Thanks a lot,

best Jan

timurhai commented 1 year ago

Hi! Sorry for a delay. I was at vocation. Block tickets info is not passed to render with a task to run from server. It can be, i do not think that it is a big deal.

It is bug that self.taskInfo.get("capacity") always returns. It can be easily fixed: https://github.com/CGRU/cgru/blob/master/afanasy/src/libafanasy/service.cpp#L190 There should be getCapacity() instead of getCapCoeff().

ultra-sonic commented 1 year ago

Hi Timur, thx for your support! Would it be easy to also provide all tickets as a dict on the task info? Like taskinfo.get("tickets")

eberrippe commented 1 year ago

Thanks @timurhai , I was able to add the capacity and it works as intended. 🌹

I still would be suuper happy if you could add the ticket information as well in a future update. I saw that this is a little more complex and couldn't add it myself.

As always, thanks in advance

Jan

timurhai commented 1 year ago

I can be done, but it will break binary compatibility. As afrender use hard coded binary (not JSON) protocol for speend and traffic reasons. So it can happen only in 3.4.x version. (but soon there will be 3.3.1 release)

eberrippe commented 1 year ago

Ahh, I see the problem @timurhai ...

If you find the time for a future release, it would be super helpful for us.

Thanks a lot

Jan

ultra-sonic commented 1 year ago

+1 for adding this in 3.4.x - this would help us a lot! Thanks in advance and keep up the great work Timur!

ultra-sonic commented 9 months ago

Hi Timur, thx for your support! Would it be easy to also provide all tickets as a dict on the task info? Like taskinfo.get("tickets")

hey timur,

we will soon need the tickets in the taskinfo and I wonder if you could implement this "properly" or if we should try it the amateur way and send a PR?

cheers Oli

timurhai commented 9 months ago

Hello! I will look at tickets today! May it is not a problem. Bigger problem is render capacity and capacity used/free. For 3.4.x I want to send some task data via JSON, for more flexible changes, to not loose binary compatibility at any change (any more data).

ultra-sonic commented 9 months ago

Hello! I will look at tickets today! May it is not a problem.

that sounds great!!!

Bigger problem is render capacity and capacity used/free. For 3.4.x I want to send some task data via JSON, for more flexible changes, to not loose binary compatibility at any change (any more data).

Even though we also need this at one point I think we can add the capacity info later if it is too much work and implement the tickets first.

timurhai commented 9 months ago

Hello! I am very sorry, was wrong (( Tickets are passed from server to render with task. I just forgot to write it in taskInfo dict. Now that simple few lines commit solves the issue that 1 year old. No compatibility break, you can check it right now.

ultra-sonic commented 9 months ago

Thanks a lot Timur! glad it doesn't break compatibility!