hey team, our team at Microsoft has been working o...
# fluent-bit
z
hey team, our team at Microsoft has been working on using fluent-bit on windows nano server container microsoft/windows-nanoserver - Docker Image | Docker Hub, the major concern is that how to prevent future broken changes of fluent-bit on nano server container. I believe currently there is no test for nano server container compatibility, but I wonder what is the existing testing mechanism of fluent-bit for windows platform? By leveraging existing tests, we could develop new tests to guard fluent-bit nano server container compatibility.
p
I think there was an attempt to use nano server a while back but not sure it was completed. The main issue was nano server missing libraries I think. What's the specific concerns that you think are relevant though? I'm not an expert on nano server. It's probably better to push changes into upstream rather than maintaining a fork too
z
good question. our team is migrating our service from windows server core container to nanoserver container, and fluent-bit was broken due to missing api used by chunkio on nanoserver, some PRs(1, 2, 3) were made to replace the missing api with other api that is available on nanoserver. The concern here is in the future with fluent-bit adding (or updating) features, some additional windows API maybe used that is not available on nanoserver container, resulting in fluent-bit failure on nanoserver. Therefore, it is necessary that fluent-bit has some tests (e.g. unit test) or sort of API blacklist to prevent these missing windows API from getting into fluent-bit when PR is reviewed.
p
Sure, so what tests are you proposing?
Why not send a PR to change the official Windows container to use a nano container then it will be picked up by upstream? https://github.com/fluent/fluent-bit/blob/master/dockerfiles/Dockerfile.windows That would be the best option for everyone I think as OSS users get smaller containers, you do not have to maintain a fork, etc.
Windows containers get built automatically for PRs now so if the Windows container is updated to use nanoserver then it will automatically also pick up any failures
z
> Windows containers get built automatically for PRs now so if the Windows container is updated to use nanoserver then it will automatically also pick up any failures This is great to know and thanks! Let me make a PR to see how it comes out when I change it to nanoserver. While I would not say pick up any failure though. The container starts up with the following command `` "fluent-bit.exe", "-c", "/fluent-bit/etc/fluent-bit.conf"`` , and this definitely detect the start up failure of fluent-bit.exe as well as its configuration under this specific configuration file, which is great! However, for example, if this specific fluent-bit.conf does not use filesystem buffer feature, fluent-bit may fail when this feature is enabled and the windows apis used by this feature is missing on nanoserver.
p
maybe provide a configuration to test with then as part of the PR
👍 1
z
one thing just comes to my mind: nanoserver has much less api available compared to windows server core, I suspect there maybe some plugins that work on server core may not run on nanoserver. Instead of releasing only windows server core version of fluent-bit, I believe it maybe a good idea to have both nanoserver and windows server core version of fluent-bit.
p
Do you know if there is any actual difference or current plugins that fail? I would not come up with possible problems if the current windows plugins work. If there is a difference already I still think it's worthwhile adding a nanoserver base as well via a PR with custom configuration as required.