Doesn't work properly with 1.1.0rc1

[eshepelyuk]

Konga doesn't display service and route details popup with 1.1.0rc1

https://discuss.konghq.com/t/kong-1-1-0rc1-available-for-testing/2873

When running KONG without DB in declarative config the popups are not displayed.

[pantsel]

@eshepelyuk , haven't had the chance to test with 1.0.1 yet but,
it seems to me that when you run Kong without a db with predefined configuration, the API is useless to start with.

I think Konga has no place in that particular setup except maybe to visualize your configuration?.

Again, I haven't tested it yet. Will do and post an update.

[eshepelyuk]

Hello @pantsel

haven't had the chance to test with 1.0.1 yet

I think there's a typo - version is 1.1.0, currently RC1

It seems to me that Konga has no place in that particular setup except maybe to visualize your configuration?.

I could agree with you on this point, but visualization should at least work.
Moreover, I assume Kong in future may support a mixed mode, when predefined config can be modified in memory via API, so Konga will be extremely handy in that case too.

[pantsel]

@eshepelyuk ,
Just tested Konga with Kong 1.1.0rc1.
It seems that everything is working fine when running KONG without DB in declarative config.

The only thing ofc is that you can't update/delete anything.

What popups are not displayed on your end?

When for example I'm on the services list page and click on a service, I get directed to the service details page and everyhting is displaying correctly.

[eshepelyuk]

When I'm on service (routes, plugins etc) page and click on any element to see details - I observe 404 in browser.

For instance, if my Konga can be reached at http://konga.stage:1337/#!/dashboard and I go to services page and click on any service - call is made and 404 is received on URLs like http://konga.stage:1337/kong/services/7e19ff91-a43e-449a-88ce-1105e57b74cc

Whie URL http://konga.stage:1337/kong/status works fine.

[pantsel]

@eshepelyuk , what version of Konga are you using?

[eshepelyuk]

@pantsel 0.14.1
And additionally - services are run in Docker Swarm

[pantsel]

@eshepelyuk , Im afraid I can't reproduce it with Konga 0.14.3.

Can you try and see if it works with konga:latest (0.14.3)?

Check Konga's demo instance.
I temporarily made it use the db-less configuration.

Kong 1.1.0rc1
Konga 0.14.3

username: demo
pass: demodemodemo

Kong entity details pages are working with no probs

[eshepelyuk]

@pantsel Tried 0.14.3 - the same issue.

[pantsel]

Have you checked the demo instance?

[eshepelyuk]

Sure

[pantsel]

It's working there.
So the problem must be elsewhere.

What happens if you try to get /services/7e19ff91-a43e-449a-88ce-1105e57b74cc directly from Kong?

[eshepelyuk]

Ok I see the issue in Konga
In the list of displayed services, UUIDs are not mathced to UUIDs of actual services. ( I checked by directly calling Kong)
I just can't understand where those UUIDs are taken from.
So obviously - when clicking on the service - I receive 404.

Will keep investigating.

[pantsel]

Also try listing the services and check if the UUIDs match, directly from Kong's API.

[eshepelyuk]

@pantsel I got the reason.

We have KONG in scaled mode, so there's a several Kong instances in the network, but Konga contact them via the common DNS name - http://kong:8100 for example, that is resolved in round robin manner to the real IP (docker IP in my case)

Since there's no central DB - UUID of the same service is different on each of Kong instance.

So basically the bug is

1. When displaying list of services - the 1st (for ex) instance of Kong is contacted (via round robin LB)
2. When clicking on particular service - 2nd instance is contacted (because of RR LB)

I have a suggestion for this

1. if name is declared fro a service/route etc - use the name for creating details link, if name not declared - use UUID.
2. provide a new setting that will switch on / off this behavior.

What do you think ?

PS: it also could be good for Konga to detect read-only mode and hide button plus provide corresponding announcement to the users. But this may be a separate task.

[pantsel]

@eshepelyuk , if you are scaling Kong, wouldn't you need to have a shared fs as well with your declarative configuration? Same as having a db. All instances must share the same storage/declarative config.

Apart from that, what happens with Entities like certificates that do not have a name attribute?

PS: it also could be good for Konga to detect read-only mode and hide button plus provide corresponding announcement to the users. But this may be a separate task.

That is true, and I'm working on implementing the new Kong 1.1.0rc1 features as we speak.

[eshepelyuk]

@pantsel unfortunately we didn't yet implemented shared FS / docker volume. Instances are configured separately :(

OK, it seems the issue is just specific to our current Kong setup, so I would close it.

Do you agree ?

[pantsel]

@eshepelyuk , It's up to you.

For now, I'll play around with the new Kong features while implementing the needed changes in Konga. I'll also try to replace the UUID with the name when available and see what happens in different setups.

Will keep you posted.

[eshepelyuk]

@pantsel Thanks for your help and patience.