Open sejnub opened 7 years ago
Thanks for the bug report! Sounds like there is indeed an issue with the defaults handling in noflo-nodejs. I'll look at this next week.
FYI: the noflo-ui side of this is being handled in noflo/noflo-ui#680 where we change the manual runtime registration so that it both:
Great! I will have a look at it the day after tomorrow.
FYI and a bit off topic: If you think it might be interesting for others as well I will gladly hone the docker image until it is easily usable and also runs on x86 (and not only ARM).
@sejnub yes, Docker image sounds useful. Are you planning to distribute it via https://hub.docker.com/ ?
Also, I'd be happy to include the Dockerfile in this repo if you make a PR. Then we can add some Docker testing to the CI suite
Yes, it will be on https://hub.docker.com Continuous test for the container would be useful. You will here from me during the next days.
I worked on the docker image. You can pull it from https://hub.docker.com/r/sejnub/noflo-runtime-js/ The source you find at https://github.com/sejnub/docker-noflo-runtime-js
I still have some questions and remarks about noflo-ui. If it's OK with you I will post them as issues at https://github.com/noflo/noflo-ui/issues
I also still have a remark about the relation between the node_modules/.bin/noflo-nodejs-init
and the node_modules/.bin/noflo-nodejs
the way they share the responsibilities now doesn't make much sense for a docker image because for every docker run
I have to call both of them. But I think it's better to post that as a separate issue so that this issue can be just about the docker image and not about those internals.
I would be glad if you could test this docker image and give me some feedback.
p.s.: About the PR: I wouldn't know where inside your source I should place my docker stuff. So I didn't create one.
@sejnub yes, you're certainly more than welcome to report issues in noflo-ui repo!
As for noflo-nodejs-init
, the idea of that script is just to prepopulate a config file so that the options don't need to be passed to noflo-nodejs
every time you run it.
So in theory at least these three should be equivalent:
.flowhub.json
file manually and run noflo-nodejs
noflo-nodejs-init
to create .flowhub.json
and run noflo-nodejs
noflo-nodejs
and pass it all the relevant options, no config file neededAh, OK, that's simple enough.
Then
--label
must be added to noflo-nodejs
because at least in my case I want to change it with every run and therefore now I must execute noflo-nodejs-init
with each docker run
--id
vs --uuid
noflo-nodejs-init --host
option is really used by noflo-nodejs
. When I last checked it seemed it wasn't.Do you need any further improvements for the docker image before you can integrate it into the CI suite?
@sejnub for integration, a pull request adding it to this repository would be awesome. We can then rig it in to the Travis setup
I created PR #107. I hope this will be useful.
Thanks!
I am in the process of building a Docker container for the noflo-nodejs-runtime (First version is for the raspberry pi. Other versions will be added if I succeed). I will hone this container and the documentation so that it will be easily usable. The Dockerfile can be found under https://github.com/sejnub/docker-noflo-runtime-js/blob/master/Dockerfile
Here comes the problem(s): After node is configured with
it shows the following:
When I then start the runtime with
the runtime is registered and visible in the browser on the app.flowhub.io after logging in. But the runtime is shown with "ws://172.17.0.4:3569" which is the local ip address of the container the runtime is hosted in. So when I click the runtime it of cause can not connect.
I found out that I have to set the host again when I start the runtime with
Why is this? I did set the host with "noflo-nodejs-init --host" so why set it again with "noflo-nodejs --host "? If I don't set it again here the runtime does register at app.flowhub.io but it is registered with the local ip of the container 172.17,... and so the flowhub-app can't reach the runtime.
First question: Why do I have to set the host two times? Is this intended behaviuor
But even if I set it here again I can't find a way to use this runtime in a github synced project. The registered runtime is not shown when I try to use the "Select runtime" button.
Second question: How can I use my registered runtime inside a github project? (Or is this question noflo-ui related and I should post it there?)
When I register the runtime manually via "new runtime register / add manually" it works, but only one time. When I go back to "home" (app.flowhub.io) the manually registered runtime is shown for only half a second, then it's gone.
Third question: Why is the manually registered runtime only usable a single time? (Or is this question noflo-ui related and I should post it there?)
I am sorry, if this is the wrong place to ask this questions. I could not find a better one.