Portal doesn't work with current Tink grpc version

[stolsma]

Expected Behaviour

Portal should run and the GUI should show data from a running configured recent Tinkerbell install

Current Behaviour

Portal compiles and runs but doesn't work and returns errors in the GUI or doesnt do anything at all. Generic gui shows but nothing works.

I expected to see data from the local running Tink instance

Possible Solution

If Portal is still supported the GRPC code should be updated to the current Tink grpc code.

Steps to Reproduce (for bugs)

Just run Portal against a current Tinkerbell implementation and see that it doesn't work...

Context

I'm trying to get a GUI on my running Tinkerbell installation

Your Environment

Standard Ubuntu Tinkerbell Provisioner VM with the most recent Tinkerbell version from the standard public registry

• Operating System and version (e.g. Linux, Windows, MacOS):
  Linux ubuntu

• How are you running Tinkerbell? Using Vagrant & VirtualBox, Vagrant & Libvirt, on Packet using Terraform, or give details:
  Vagrant Libvirt

• Link to your project or a code example to reproduce issue:

[gauravgahlot]

@stolsma Thank you for reporting this issue.

The portal is certainly not in sync with the recent tink changes. This is primarily because the team is majorly focused on making tinkerbell more stable as a product. You can always check the projects to know what's keeping the team occupied.

We will try and bring the portal to a stable state as soon as we can.
Thanks. :)

[stolsma]

@gauravgahlot Thanks for the quick reply!

Understandable! Didn't know about the projects page!

If I have some time next week I will try to update the GRPC and supporting code and make a pull request...

[gauravgahlot]

That would be awesome. 🚀 Looking forward to it.

[stolsma]

@gauravgahlot, working on getting working code but I found another bug too, that one is related to the very basic implementation of caching in redis. When creating workflows the new workflows are not shown on the web page because data from the new flow is not cached. The same happens for all data in the web page (hardware, template, workflow) when the CLI is used for adding/changing/removing Tink data!.

This brought me to the question why the replies from Tink are cached? It doesn't give much profit as you still need to query Redis over the network instead of Tink. If the load on Tink and subsequently the database in Postgress is the problem here, then implementing some sort of response caching in Tink would be the best place to solve that problem imo.

It would definitely clean up the code if caching could be removed ;-)

[gauravgahlot]

@stolsma When I started the project, I felt like we need a cache for a better/faster response. The response from Tink API does not always have the details we want to present on the UI. And so it happens that to present certain details on the UI you make multiple calls to tink/db, which is something I wanted to avoid.

I will be happy to discuss how we can improve the overall design and yet keep the portal responsive.
Please use this link to join Equinix Metal Community, if not already. You can find me as GG. 👍🏼

[stolsma]

Thanks for merging! 👍