Compatibility Issue: 'syscall.Statfs' Function Not Supported in Windows Environment

[sundaram2021]

internal/validations.go

1. GetAvailableDiskSize fn is not working properly
2. syscall.Statfs is not defined
3. syscall.Statfs_t is not defined

this is creating error becuase syscall methods Statfs and Stats_t is os specific
and are only available in UNIX like systems

[linear]

KRA-16 Compatibility Issue: 'syscall.Statfs' Function Not Supported in Windows Environment

[patrickdappollonio]

Hey @sundaram2021!

This is unfortunately one of those little Achilles' heels of Kubefirst. We're working on making it cross platform but we're not there yet. We can fix this but 5 other things will pop up including generating platform specific folder paths.

We'll keep this in our radar (in fact it already went to our triage in linear) and keep it updated if any progress happens!

Thanks for the report!

[sundaram2021]

Also this validation is used in this repo "https://github.com/konstructio/kubefirst"
and causing a build failure there

...
...
i have raise a pr regarding this which is a plaform indepenent solution here

[sundaram2021]

hey @patrickdappollonio i have solution for this cross plaform issue
we can create a custom actions which will test the project whether it is compatible for various distrosor not
and if not then on which os it not ....

at least we will know where are the issues are
and also in that particularly we can check for specific pattern
like checking for syscall pkg etc..

please feel free to share your thoughts
thanks

[patrickdappollonio]

I think getting it to compile is one thing which might be easy...

Getting it to actually work appropriately is a different issue altogether. Many of the internal paths coded in the application are Unix-specific and those locations don't exist on Windows.

I'm happy to merge your PR with the platform-agnostic solution... I just want to make sure you understand that just fixing the system calls unavailable on windows might not be enough.

For Windows, we always recommend using WSL rather than running it natively on Windows.

[sundaram2021]

i am curious to know how you guys approaching this issue
and how can i help you guys with these
it sounds preety intresting to me

thanks

[patrickdappollonio]

It is indeed interesting. There are a few challenges we need to overcome like the ones I stated in my previous post (path locations, etc).

Then there's also the fact we rely for a few things on k3s and k3s is not natively available on Windows: https://docs.k3s.io/faq#does-k3s-support-windows -- that alone might be a dealbreaker for us until we can see a path with a custom cluster technology.

We'll try to keep this story as synchronized as possible, but we're a small team trying to tackle a few other challenges as well so this would have to process through appropriate channels: triage -> backlog -> action.

We'll keep this isssue updated!

[sundaram2021]

I will start contributing at my level regarding this and will document each and every thing for the future
thanks for the guidance :)

[patrickdappollonio]

Sounds good! Just to set expectations though: happy to take PRs, but please assume the team might be focusing on something else at the moment and full Windows support might some sometime in the future, even if your PR changes are merged today.

[fharper]

@sundaram2021: I missed the end of our meeting, but I think the decision was to not focus on Windows support since it won't work properly right? If so, I'll close this issue.