konstructio / kubefirst-api

Kubefirst API that serves console frontend
MIT License
10 stars 14 forks source link

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

Open sundaram2021 opened 4 days ago

sundaram2021 commented 4 days ago

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[bot] commented 4 days ago

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

patrickdappollonio commented 4 days ago

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 commented 4 days ago

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

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

sundaram2021 commented 4 days ago

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 commented 4 days ago

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 commented 4 days ago

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 commented 4 days ago

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 commented 4 days ago

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

patrickdappollonio commented 4 days ago

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.