Multicast - Could not compete tasking

[Wayne Workman]

@cyrmoon I’d like for you to do some troubleshooting - And I’m hoping it’s ok that we delete all previous task information.

Go into mysql like this:
mysql

then type: use fog

Then, to clear the tasks table, and multicast tables, issue these queries:
truncate table tasks;
truncate table multicastSessions;
truncate table multicastSessionsAssoc;

Then, create a single multicast task. Then after this task is created, imediately issue these commands and copy the output and post here:

SELECT * FROM tasks;
SELECT * FROM multicastSessions;
SELECT * FROM multicastSessionsAssoc;

Then, let the multicast finish and get to the error you were seeing. Then please issue the same commands again and record their output and post here.

SELECT * FROM tasks;
SELECT * FROM multicastSessions;
SELECT * FROM multicastSessionsAssoc;

also, please post the logs from the Web Interface -> FOG Configuration -> Log Viewer -> Multicast area for the relevant time span that you have done the above procedure. I want to know every little scrap of information available while your doing the multicast.

Then we can go from there.

[cyrmoon]

@Wayne-Workman !
Before multicast

After multicast

log viewer

[Wayne Workman]

@cyrmoon So looking at the data from the DB, the task is created fine. And the hosts update their progress fine, as you see they went from 1% complete to 99.66% and 100%.

They both start out with their task states as 1, which is Queued and end with task state of 5, which is Cancelled

Did you cancel the tasks?

[cyrmoon]

@Wayne-Workman no i let job finish. the two pcs are deployed with success.
but the task disappeared at the end and doesn’t enter in the database. result no log imaging.

[Wayne Workman]

@cyrmoon I was talking ot @Tom-Elliott the other day and he said he is aware that multicast tasks are finishing as “Canceled”, but he’s not sure why. Moving this to bug reports.

[Tom Elliott]

@Wayne-Workman what does ftp errors have to do with multicast?

[Wayne Workman]

@Tom-Elliott after the ftp issue was fixed, @cyrmoon had an issue at the end of multicast. That’s how we got on this topic.

[Tom Elliott]

@Wayne-Workman then how about we move the multicast stuff to its own thread and solve this one? It will help minimize confusion. The way I read this currently the problem the thread was working with is broken.

[Wayne Workman]

@Tom-Elliott forked. @cyrmoon we are in this thread now.

[Tom Elliott]

Sorry about sounding rude, that was not my intention at all. Yes, it should be it’s own thread as it is completely it’s own issue. I am working on fixing this though.

[Tom Elliott]

@cyrmoon So the task finishes now and removes it from the DB and the hosts reboot properly, just they’re showing up as cancelled now, correct?

[Tom Elliott]

Added code that should properly complete a tasking. Please let me know if all is better now.

Thanks,

[Tom Elliott]

Anything?

[Sebastian Roth]

Calling out for @cyrmoon again! Any news on this? As well moving this to the problem section as I am pretty sure this is not a bug…

[Wayne Workman]

@Developers @Moderators
I messaged him in chat and ping’d him here in the thread.

I’m thinking that forking threads isn’t good because people may bookmark the original thread they posted in. He might have came back to the original thread via a bookmark and seen that all his new posts were just gone…

I think that locking threads is a better option once the issue is solved, or we have looser customs about people addressing their next issue in their original thread. With the forums searching functionality, it may not be such a bad idea to just let folks keep going in the original thread. Also, another option is after forking, leave a link behind for them to find where the fork went to. Maybe that should be a feature in nodeBB? Auto-link to the fork, and maybe even send an email to the individual who’s posts were forked? Maybe even auto-message them too with the link and a short message of what happened.