Allow connecting to an external bitbake server

[cordlandwehr]

Often in commercial environments, developers use a specifically configured Docker container to isolate the Yocto setup more from the (possibly outdated or even not supported) host system or maybe to just enforce a certain native compiler.
For such setups, one usually has to do the following steps to run bitbake:

1. start or log in into a container
2. perform "some" operation to initialize a Git credentials cache (or similar) to obtain access to company internal restricted repositories
3. then source the environment and run BitBake
   Even though all of the above can be put into a wrapper script that is run as a Command Wrapper, I think this is a so common setup that it makes sense to have a dedicated configuration option for such settings where first a login into a container and then a pre-command in that container is needed. By this, one could even put the container lifetime into the hands of VS-code and better isolate against Bitbake failures where the BitBake server is still running but not cleaned up correctly.

[deribaucourt]

Thanks for reporting a new commandWrapper setup!
Indeed, I would advise to put this inside a wrapper script that accepts being passed the bitbake commands for complex setups like this.

If we want to think about new ways to do it:
I don't see a KISS-compliant way of implementing the complex wrapper script you describe while also staying compatible with our commandWrapper which is already versatile enough.
What I have in mind for your use case would be that the user manages the bitbake server on their own:

1. You start your container
2. You log-in interactively the way you are used to
3. You run bitbake --server-only
4. We add a setting "bitbakeServer" and we add the corresponding argument to all bitbake calls. You'll still need to provide bitbake settings to source the bitbake environment file.
5. That way, when any bitbake command is run, it uses your bitbake server which has the docker environment and git credentials
   How does that sound?

[deribaucourt]

I had made a draft where we would manage the server's lifetime. It was quickly becoming super complex because we have to handle crashes of the server, cleanup, locks, ...
Also it wasn't compatible much with external bitbake servers which might be run remotely.
I think a client approach would be more adequate for our extension.

[deribaucourt]

You could also run a VSCode remote session inside your container (see https://code.visualstudio.com/docs/remote/remote-overview)

[cordlandwehr]

I really like the idea of having the possibility to control my bitbake server "myself" and thus external of the VS code session and then only attach to it.
For my use case with the docker container that will solve my issues and is a little bit simpler to setup than the remote extension, specifically when having more a Yocto background than a VS Code background I think.

[Erik-Sovereign]

Hey there,
I just want to second the idea of connecting to a docker container that can run bitbake (I think).

Our setup is that we run a complex docker run <many -v and -e commands> --rm --user $(shell id -u):$(shell id -g) bash -c '. sources/poky/oe-init-build-env build && export BB_ENV_PASSTHROUGH_ADDITIONS="$$BB_ENV_PASSTHROUGH_ADDITIONS $(BB_ENV_PASSTHROUGH_ADDITIONS)" && bitbake $(BB_ADD_TARGETS) our-image' command. We run that in a make file. It would be great if we could just run this in the the makefile as an interactive docker container and then connect the Vs Code extension to that container, since I see no way at the moment how $command_wrapper can run the multiple stages that are defined in our Makefile and then also run our bitbake command exactly how we want (But maybe I just don't fully understand the capabilities of the command wrapper)

[deribaucourt]

Thanks for your feedback. I love to think we can get the extension to work with original environments such as these! . I added this feature into our backlog ;). It looks like the bitbake server options should provide the compatibility needed.

[deribaucourt]

I wonder if this could already be achieved by configuring BBSERVER:

1. Start bitbake server externally (bitbake --server-only -T -1 -B 0.0.0.0:9000)
2. Define BBSERVER="localhost:9000" either in local.conf or our shellEnv setting with BB_ENV_PASSTHROUGH_ADDITIONS
3. Run bitbake commands

I'd prefer just adding documentation instead of adding an actual setting that would add args like bitbake --remote-server localhost:9000. It's easy enough for the basic commands, but the rest of our code with custom commands like devtool would also need to be updated.

So far I've tried to host the remote server in a docker container while binding the port, and using it outside but bitbake always remain frozen. I'm not sure the remote server communication is really stable or requires additional ports forwarding?

[deribaucourt]

Testing again today, on the same machine, I could reuse a running server from a docker context into a native context using the socket file:

1. Open up a docker crops container
2. Run the server inside bitbake --server-only -T -1. Do not close the terminal (bitbake server can only be started in the background)
3. Run bitbake commands from the native side. They'll automatically use the bitbake.sock channel.

If the container is remote, there's probably some additional port forwarding arguments that I didn't figure except (except the obvious docker-run -p 9000:9000. I'll attempt again to use a container from another machine and document the setup with VSCode. It looks like configuring BBSERVER throught local.conf or the VSCode bitbake shellEnv property is the best way to go rather than justify a new setting, and a whole complexity to implement it.

[deribaucourt]

To setup a remote container I'd like to do:

1. Open up a docker crops container with port forwarding docker-run -p 9000:9000
2. Run and bind the server in the background bitbake --server-only -T -1 -B localhost:9000
3. Run a client through the remote connection bitbake --remote-server localhost:9000 busybox

Currently I get

Traceback (most recent call last):
  File "/home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/sources/poky/bitbake/bin/bitbake", line 36, in <module>
    sys.exit(bitbake_main(BitBakeConfigParameters(sys.argv),
  File "/home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/sources/poky/bitbake/lib/bb/main.py", line 388, in bitbake_main
    server_connection, ui_module = setup_bitbake(configParams)
  File "/home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/sources/poky/bitbake/lib/bb/main.py", line 451, in setup_bitbake
    server_connection = bb.server.xmlrpcclient.connectXMLRPC(configParams.remote_server, featureset,
  File "/home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/sources/poky/bitbake/lib/bb/server/xmlrpcclient.py", line 138, in connectXMLRPC
    raise e
  File "/home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/sources/poky/bitbake/lib/bb/server/xmlrpcclient.py", line 134, in connectXMLRPC
    connection = BitBakeXMLRPCServerConnection(host, port, (ip, 0), observer_only, featureset)
  File "/home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/sources/poky/bitbake/lib/bb/server/xmlrpcclient.py", line 76, in __init__
    self.events = uievent.BBUIEventQueue(self.connection, self.clientinfo)
  File "/home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/sources/poky/bitbake/lib/bb/ui/uievent.py", line 45, in __init__
    ret = self.BBServer.registerEventHandler(self.host, self.port)
  File "/usr/lib/python3.10/xmlrpc/client.py", line 1122, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python3.10/xmlrpc/client.py", line 1464, in __request
    response = self.__transport.request(
  File "/usr/lib/python3.10/xmlrpc/client.py", line 1166, in request
    return self.single_request(host, handler, request_body, verbose)
  File "/usr/lib/python3.10/xmlrpc/client.py", line 1179, in single_request
    resp = http_conn.getresponse()
  File "/usr/lib/python3.10/http/client.py", line 1375, in getresponse
    response.begin()
  File "/usr/lib/python3.10/http/client.py", line 318, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.10/http/client.py", line 279, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/usr/lib/python3.10/socket.py", line 705, in readinto
    return self._sock.recv_into(b)
ConnectionResetError: [Errno 104] Connection reset by peer
WARNING: Could not connect to server at localhost:9000 ([Errno 104] Connection reset by peer)
WARNING: sys:1: ResourceWarning: unclosed <socket.socket fd=3, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 40563)>

 $ ps
deribau+     153  0.6  0.5 224560 81512 ?        Sl   15:12   0:03 /usr/bin/python3 /home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/sources/poky/bitbake/bin/bitbake-server decafbad 3 5 /home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/build/bitbake-cookerdaemon.log /home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/build/bitbake.lock /home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/build/bitbake.sock -1.0 0 localhost 9000
deribau+     161  0.0  0.2 132456 37416 ?        S    15:13   0:00 /usr/bin/python3 /home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/sources/poky/bitbake/bin/bitbake-server decafbad 3 5 /home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/build/bitbake-cookerdaemon.log /home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/build/bitbake.lock /home/deribaucourt/Workspace/yocto-vscode/yocto/yocto-build/build/bitbake.sock -1.0 0 localhost 9000

I don't know if bitbake doesn't like that I'm doing that on the same machine, if I should host a different xmlrpc server, or if it's a docker forwarding issue.

[rossburton]

It feels like to me that the existing remote support should just work for the container aspect, so then you just need to glue in the credentials? Manually driving a remote bitbake server feels quite fragile: whilst bitbake has support for this it's not as elegant as you'd like.