Add multiple management server support #898

utchoang · 2020-12-17T07:21:22Z

Fixes #895

utchoang · 2020-12-17T07:22:09Z

@blueorangutan package

blueorangutan · 2020-12-17T07:23:02Z

@utchoang a Jenkins job has been kicked to build primate packages. I'll keep you posted as I make progress.

blueorangutan · 2020-12-17T07:33:36Z

Packaging result: ✔️centos ✔️debian ✔️archive.
QA: http://primate-qa.cloudstack.cloud:8080/client/pr/898 (JID-3746)

rohityadavcloud · 2020-12-17T08:10:27Z

public/config.json

-  "apiBase": "/client/api",
+  "servers": [
+    {
+      "name": "Manager 1",


This may not always work; due to CORS if they are on different domain and using https.

@rhtyd Will it work well if I use the baseUrl (domain, https) instead of the current one?

@rhtyd what do you think about my way?

utchoang · 2020-12-22T06:19:21Z

@blueorangutan package

blueorangutan · 2020-12-22T06:20:28Z

@utchoang a Jenkins job has been kicked to build primate packages. I'll keep you posted as I make progress.

blueorangutan · 2020-12-22T06:30:11Z

Packaging result: ✔️centos ✔️debian ✔️archive.
QA: http://primate-qa.cloudstack.cloud:8080/client/pr/898 (JID-3764)

utchoang · 2020-12-22T07:51:52Z

@blueorangutan package

blueorangutan · 2020-12-22T07:52:29Z

@utchoang a Jenkins job has been kicked to build primate packages. I'll keep you posted as I make progress.

blueorangutan · 2020-12-22T08:03:19Z

Packaging result: ✔️centos ✔️debian ✔️archive.
QA: http://primate-qa.cloudstack.cloud:8080/client/pr/898 (JID-3766)

public/config.json

ravening · 2021-01-11T13:15:53Z

@utchoang can you add screenshots if possible?

utchoang · 2021-01-12T00:42:34Z

@ravening

rohityadavcloud · 2021-01-12T09:40:12Z

I don't think it'll work due to CORS issues esp if website is served under https.
What do you think @wido @GabrielBrascher @weizhouapache @utchoang @svenvogel @ravening @davidjumani ?

ravening · 2021-01-12T09:58:23Z

I don't think it'll work due to CORS issues esp if website is served under https.

What do you think @wido @GabrielBrascher @weizhouapache @utchoang @svenvogel @ravening @davidjumani ?

Will test it and let you know

wido · 2021-01-12T10:07:54Z

I don't think it'll work due to CORS issues esp if website is served under https.
What do you think @wido @GabrielBrascher @weizhouapache @utchoang @svenvogel @ravening @davidjumani ?

Why not? The URL stays the same. And on the proxy server you can add, remove and/or modify CORS headers if needed.

ravening · 2021-01-12T10:14:26Z

I don't think it'll work due to CORS issues esp if website is served under https.
What do you think @wido @GabrielBrascher @weizhouapache @utchoang @svenvogel @ravening @davidjumani ?

Why not? The URL stays the same. And on the proxy server you can add, remove and/or modify CORS headers if needed.

@wido @rhtyd @utchoang

The request is getting blocked. Not sure if im missing but I just added the entire endpoint in config.json

rohityadavcloud · 2021-01-12T10:41:58Z

@wido I think it should be the reverse proxy/lb config doing the LB for available/up mgmt servers than provide option in UI. But I see your use-case.

utchoang · 2021-01-12T10:47:31Z

@ravening Yes. If we using domain with http it'll not work due to CORS issues :(. But if using https, It'll works

weizhouapache · 2021-01-12T14:07:06Z

@ravening Yes. If we using domain with http it'll not work due to CORS issues :(. But if using https, It'll works

@utchoang both http/https do not work for me, even if I install browser extension to unblock CORS.
it is not an issue with this PR.
the official release 1.0 does not work either. @rhtyd

utchoang · 2021-01-13T01:02:55Z

@ravening @weizhouapache @rhtyd @ravening I have tested it a few times with http and https but it both doesn't work due to CORS. This PR doesn't solve the problem.
Do you have a better way?

wido · 2021-01-13T13:21:33Z

I tried this with two management servers from the PCextreme cloud.

server {
    listen       80;
    server_name  localhost;
    location / {
        root   /usr/share/nginx/html;
        index  index.html;
    }
    location /api/ams {
        # http://127.0.0.1:8080 should be replaced your CloudStack management
        # Server's actual URI
        proxy_pass   https://api.XXXXX.eu/ams3;
    }
    location /api/haa {
        # http://127.0.0.1:8080 should be replaced your CloudStack management
        # Server's actual URI
        proxy_pass   https://api.XXXXX.eu/zone01_haa01;
    }
}

{
  "servers": [
    {
      "name": "Amsterdam",
      "apiBase": "/api/ams"
    },
    {
      "name": "Haarlem",
      "apiBase": "/api/haa"
    }
  ],

I see the requests go to the proper Management server, but my Firefox console complains that sessionkey cookie expires right away.

The calls which I see:

172.17.0.1 - - [13/Jan/2021:13:18:15 +0000] "POST /api/haa/ HTTP/1.1" 200 323 "http://localhost:8181/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-"
172.17.0.1 - - [13/Jan/2021:13:18:15 +0000] "GET /api/haa/?listall=true&command=listZones&response=json HTTP/1.1" 401 126 "http://localhost:8181/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-"
172.17.0.1 - - [13/Jan/2021:13:18:15 +0000] "GET /api/haa/?username=admin&command=listUsers&response=json HTTP/1.1" 401 126 "http://localhost:8181/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-"
172.17.0.1 - - [13/Jan/2021:13:18:15 +0000] "GET /api/haa/?command=listApis&response=json HTTP/1.1" 401 125 "http://localhost:8181/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-"

So some calls work, but others get back a 401 Unauthorized. Still unclear to me what is breaking it here.

Both API endpoints and up at the management servers:

wido@wido-laptop:~$ curl -I http://localhost:8181/api/ams
HTTP/1.1 401 Unauthorized
Server: nginx/1.19.6
Date: Wed, 13 Jan 2021 13:22:08 GMT
Content-Type: text/xml;charset=utf-8
Content-Length: 211
Connection: keep-alive
X-Content-Type-Options: nosniff
X-XSS-Protection: 1;mode=block
content-security-policy: 1
content-security-policy: default-src=none
content-security-policy: script-src=self
content-security-policy: connect-src=self
content-security-policy: img-src=self
content-security-policy: style-src=self
X-Xss-Protection: 1; mode=block

wido@wido-laptop:~$ curl -I http://localhost:8181/api/haa
HTTP/1.1 401 Unauthorized
Server: nginx/1.19.6
Date: Wed, 13 Jan 2021 13:22:11 GMT
Content-Type: text/xml;charset=utf-8
Content-Length: 211
Connection: keep-alive
X-Content-Type-Options: nosniff
X-XSS-Protection: 1;mode=block
content-security-policy: 1
content-security-policy: default-src=none
content-security-policy: script-src=self
content-security-policy: connect-src=self
content-security-policy: img-src=self
content-security-policy: style-src=self
X-Xss-Protection: 1; mode=block
X-Xss-Protection: 1; mode=block

wido@wido-laptop:~$

I also checked the management server logs:

2021-01-13 14:26:34,987 DEBUG [c.c.a.ApiServlet] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) ===START===  92.XXX.170.138 -- POST  
2021-01-13 14:26:34,988 DEBUG [c.c.a.ApiServlet] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Session cookie is marked secure!
2021-01-13 14:26:34,993 DEBUG [c.c.u.AccountManagerImpl] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Attempting to log in user: admin in domain 1
2021-01-13 14:26:34,995 DEBUG [o.a.c.s.a.PBKDF2UserAuthenticator] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Retrieving user: admin
2021-01-13 14:26:35,316 DEBUG [c.c.u.AccountManagerImpl] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) CIDRs from which account 'Acct[ae43e7cb-abe2-11ea-8f22-d8252d74bd58-admin]' is allowed to perform API calls: 0.0.0.0/0,::/0
2021-01-13 14:26:35,316 DEBUG [c.c.u.AccountManagerImpl] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) User: admin in domain 1 has successfully logged in
2021-01-13 14:26:35,329 INFO  [c.c.a.ApiServer] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Current user logged in under UTC timezone
2021-01-13 14:26:35,329 INFO  [c.c.a.ApiServer] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Timezone offset from UTC is: 0.0
2021-01-13 14:26:35,333 DEBUG [c.c.a.ApiServlet] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) ===END===  92.XXX.170.138 -- POST  
2021-01-13 14:26:35,387 DEBUG [c.c.a.ApiServlet] (qtp979294118-64148:ctx-2355cc41) (logid:343a1d0e) ===START===  92.XXX.170.138 -- GET  listall=true&command=listZones&response=json
2021-01-13 14:26:35,387 DEBUG [c.c.a.ApiServer] (qtp979294118-64148:ctx-2355cc41 ctx-c0c8312c) (logid:343a1d0e) Expired session, missing signature, or missing apiKey -- ignoring request. Signature: null, apiKey: null
2021-01-13 14:26:35,389 DEBUG [c.c.a.ApiServlet] (qtp979294118-64148:ctx-2355cc41 ctx-c0c8312c) (logid:343a1d0e) ===END===  92.xxx.170.138 -- GET  listall=true&command=listZones&response=json

Noticed how these values are null:

apiKey
signature

weizhouapache · 2021-01-13T21:17:34Z

I tried this with two management servers from the PCextreme cloud.

server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html;
}
location /api/ams {
# http://127.0.0.1:8080 should be replaced your CloudStack management
# Server's actual URI
proxy_pass https://api.XXXXX.eu/ams3;
}
location /api/haa {
# http://127.0.0.1:8080 should be replaced your CloudStack management
# Server's actual URI
proxy_pass https://api.XXXXX.eu/zone01_haa01;
}
}
{
"servers": [
{
"name": "Amsterdam",
"apiBase": "/api/ams"
},
{
"name": "Haarlem",
"apiBase": "/api/haa"
}
],
I see the requests go to the proper Management server, but my Firefox console complains that sessionkey cookie expires right away.

The calls which I see:

172.17.0.1 - - [13/Jan/2021:13:18:15 +0000] "POST /api/haa/ HTTP/1.1" 200 323 "http://localhost:8181/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-"
172.17.0.1 - - [13/Jan/2021:13:18:15 +0000] "GET /api/haa/?listall=true&command=listZones&response=json HTTP/1.1" 401 126 "http://localhost:8181/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-"
172.17.0.1 - - [13/Jan/2021:13:18:15 +0000] "GET /api/haa/?username=admin&command=listUsers&response=json HTTP/1.1" 401 126 "http://localhost:8181/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-"
172.17.0.1 - - [13/Jan/2021:13:18:15 +0000] "GET /api/haa/?command=listApis&response=json HTTP/1.1" 401 125 "http://localhost:8181/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-"
So some calls work, but others get back a 401 Unauthorized. Still unclear to me what is breaking it here.

Both API endpoints and up at the management servers:

wido@wido-laptop:~$ curl -I http://localhost:8181/api/ams
HTTP/1.1 401 Unauthorized
Server: nginx/1.19.6
Date: Wed, 13 Jan 2021 13:22:08 GMT
Content-Type: text/xml;charset=utf-8
Content-Length: 211
Connection: keep-alive
X-Content-Type-Options: nosniff
X-XSS-Protection: 1;mode=block
content-security-policy: 1
content-security-policy: default-src=none
content-security-policy: script-src=self
content-security-policy: connect-src=self
content-security-policy: img-src=self
content-security-policy: style-src=self
X-Xss-Protection: 1; mode=block

wido@wido-laptop:~$ curl -I http://localhost:8181/api/haa
HTTP/1.1 401 Unauthorized
Server: nginx/1.19.6
Date: Wed, 13 Jan 2021 13:22:11 GMT
Content-Type: text/xml;charset=utf-8
Content-Length: 211
Connection: keep-alive
X-Content-Type-Options: nosniff
X-XSS-Protection: 1;mode=block
content-security-policy: 1
content-security-policy: default-src=none
content-security-policy: script-src=self
content-security-policy: connect-src=self
content-security-policy: img-src=self
content-security-policy: style-src=self
X-Xss-Protection: 1; mode=block
X-Xss-Protection: 1; mode=block

wido@wido-laptop:~$
I also checked the management server logs:

2021-01-13 14:26:34,987 DEBUG [c.c.a.ApiServlet] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) ===START=== 92.XXX.170.138 -- POST
2021-01-13 14:26:34,988 DEBUG [c.c.a.ApiServlet] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Session cookie is marked secure!
2021-01-13 14:26:34,993 DEBUG [c.c.u.AccountManagerImpl] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Attempting to log in user: admin in domain 1
2021-01-13 14:26:34,995 DEBUG [o.a.c.s.a.PBKDF2UserAuthenticator] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Retrieving user: admin
2021-01-13 14:26:35,316 DEBUG [c.c.u.AccountManagerImpl] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) CIDRs from which account 'Acct[ae43e7cb-abe2-11ea-8f22-d8252d74bd58-admin]' is allowed to perform API calls: 0.0.0.0/0,::/0
2021-01-13 14:26:35,316 DEBUG [c.c.u.AccountManagerImpl] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) User: admin in domain 1 has successfully logged in
2021-01-13 14:26:35,329 INFO [c.c.a.ApiServer] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Current user logged in under UTC timezone
2021-01-13 14:26:35,329 INFO [c.c.a.ApiServer] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Timezone offset from UTC is: 0.0
2021-01-13 14:26:35,333 DEBUG [c.c.a.ApiServlet] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) ===END=== 92.XXX.170.138 -- POST
2021-01-13 14:26:35,387 DEBUG [c.c.a.ApiServlet] (qtp979294118-64148:ctx-2355cc41) (logid:343a1d0e) ===START=== 92.XXX.170.138 -- GET listall=true&command=listZones&response=json
2021-01-13 14:26:35,387 DEBUG [c.c.a.ApiServer] (qtp979294118-64148:ctx-2355cc41 ctx-c0c8312c) (logid:343a1d0e) Expired session, missing signature, or missing apiKey -- ignoring request. Signature: null, apiKey: null
2021-01-13 14:26:35,389 DEBUG [c.c.a.ApiServlet] (qtp979294118-64148:ctx-2355cc41 ctx-c0c8312c) (logid:343a1d0e) ===END=== 92.xxx.170.138 -- GET listall=true&command=listZones&response=json
Noticed how these values are null:

apiKey

signature

@wido this is a good way to avoid CORS. thanks for sharing.
To set cookie of other domains, you need to enable 3rd-party cookie on server side.
Set-Cookie: SiteSite=None; Secure

if you use nginx, add proxy_cookie_path / "/; Secure; SameSite=None;";
it also means both server and client side must be secure (https)

wido · 2021-01-14T14:22:14Z

I tried this with two management servers from the PCextreme cloud.
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html;
}
location /api/ams {

http://127.0.0.1:8080 should be replaced your CloudStack management

Server's actual URI

proxy_pass https://api.XXXXX.eu/ams3;
}
location /api/haa {

http://127.0.0.1:8080 should be replaced your CloudStack management

Server's actual URI

proxy_pass https://api.XXXXX.eu/zone01_haa01;
}
}
{
"servers": [
{
"name": "Amsterdam",
"apiBase": "/api/ams"
},
{
"name": "Haarlem",
"apiBase": "/api/haa"
}
],
I see the requests go to the proper Management server, but my Firefox console complains that sessionkey cookie expires right away.
The calls which I see:
172.17.0.1 - - [13/Jan/2021:13:18:15 +0000] "POST /api/haa/ HTTP/1.1" 200 323 "http://localhost:8181/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-"
172.17.0.1 - - [13/Jan/2021:13:18:15 +0000] "GET /api/haa/?listall=true&command=listZones&response=json HTTP/1.1" 401 126 "http://localhost:8181/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-"
172.17.0.1 - - [13/Jan/2021:13:18:15 +0000] "GET /api/haa/?username=admin&command=listUsers&response=json HTTP/1.1" 401 126 "http://localhost:8181/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-"
172.17.0.1 - - [13/Jan/2021:13:18:15 +0000] "GET /api/haa/?command=listApis&response=json HTTP/1.1" 401 125 "http://localhost:8181/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" "-"
So some calls work, but others get back a 401 Unauthorized. Still unclear to me what is breaking it here.
Both API endpoints and up at the management servers:
wido@wido-laptop:$ curl -I http://localhost:8181/api/ams
HTTP/1.1 401 Unauthorized
Server: nginx/1.19.6
Date: Wed, 13 Jan 2021 13:22:08 GMT
Content-Type: text/xml;charset=utf-8
Content-Length: 211
Connection: keep-alive
X-Content-Type-Options: nosniff
X-XSS-Protection: 1;mode=block
content-security-policy: 1
content-security-policy: default-src=none
content-security-policy: script-src=self
content-security-policy: connect-src=self
content-security-policy: img-src=self
content-security-policy: style-src=self
X-Xss-Protection: 1; mode=block
wido@wido-laptop:$ curl -I http://localhost:8181/api/haa
HTTP/1.1 401 Unauthorized
Server: nginx/1.19.6
Date: Wed, 13 Jan 2021 13:22:11 GMT
Content-Type: text/xml;charset=utf-8
Content-Length: 211
Connection: keep-alive
X-Content-Type-Options: nosniff
X-XSS-Protection: 1;mode=block
content-security-policy: 1
content-security-policy: default-src=none
content-security-policy: script-src=self
content-security-policy: connect-src=self
content-security-policy: img-src=self
content-security-policy: style-src=self
X-Xss-Protection: 1; mode=block
X-Xss-Protection: 1; mode=block
wido@wido-laptop:~$
I also checked the management server logs:
2021-01-13 14:26:34,987 DEBUG [c.c.a.ApiServlet] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) ===START=== 92.XXX.170.138 -- POST
2021-01-13 14:26:34,988 DEBUG [c.c.a.ApiServlet] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Session cookie is marked secure!
2021-01-13 14:26:34,993 DEBUG [c.c.u.AccountManagerImpl] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Attempting to log in user: admin in domain 1
2021-01-13 14:26:34,995 DEBUG [o.a.c.s.a.PBKDF2UserAuthenticator] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Retrieving user: admin
2021-01-13 14:26:35,316 DEBUG [c.c.u.AccountManagerImpl] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) CIDRs from which account 'Acct[ae43e7cb-abe2-11ea-8f22-d8252d74bd58-admin]' is allowed to perform API calls: 0.0.0.0/0,::/0
2021-01-13 14:26:35,316 DEBUG [c.c.u.AccountManagerImpl] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) User: admin in domain 1 has successfully logged in
2021-01-13 14:26:35,329 INFO [c.c.a.ApiServer] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Current user logged in under UTC timezone
2021-01-13 14:26:35,329 INFO [c.c.a.ApiServer] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) Timezone offset from UTC is: 0.0
2021-01-13 14:26:35,333 DEBUG [c.c.a.ApiServlet] (qtp979294118-71298:ctx-a4c4892a) (logid:a706fe0b) ===END=== 92.XXX.170.138 -- POST
2021-01-13 14:26:35,387 DEBUG [c.c.a.ApiServlet] (qtp979294118-64148:ctx-2355cc41) (logid:343a1d0e) ===START=== 92.XXX.170.138 -- GET listall=true&command=listZones&response=json
2021-01-13 14:26:35,387 DEBUG [c.c.a.ApiServer] (qtp979294118-64148:ctx-2355cc41 ctx-c0c8312c) (logid:343a1d0e) Expired session, missing signature, or missing apiKey -- ignoring request. Signature: null, apiKey: null
2021-01-13 14:26:35,389 DEBUG [c.c.a.ApiServlet] (qtp979294118-64148:ctx-2355cc41 ctx-c0c8312c) (logid:343a1d0e) ===END=== 92.xxx.170.138 -- GET listall=true&command=listZones&response=json
Noticed how these values are null:

apiKey

signature

@wido this is a good way to avoid CORS. thanks for sharing.
To set cookie of other domains, you need to enable 3rd-party cookie on server side.
Set-Cookie: SiteSite=None; Secure

if you use nginx, add proxy_cookie_path / "/; Secure; SameSite=None;";
it also means both server and client side must be secure (https)

This is something I would need to investigate. Haven't been able to do so yet.

weizhouapache · 2021-01-15T12:03:43Z

@wido this is a good way to avoid CORS. thanks for sharing.
To set cookie of other domains, you need to enable 3rd-party cookie on server side.
Set-Cookie: SiteSite=None; Secure
if you use nginx, add proxy_cookie_path / "/; Secure; SameSite=None;";
it also means both server and client side must be secure (https)

This is something I would need to investigate. Haven't been able to do so yet.

@wido I have tested it with nginx. it works well.
setting cookie header is supported by haproxy 1.8+

weizhouapache · 2021-01-15T12:05:26Z

@utchoang
The only issue is that vm console is not working.
the console always uses /client/console on localhost.
https://github.com/apache/cloudstack-primate/blob/master/src/components/widgets/Console.vue#L21

wido · 2021-01-15T14:12:44Z

@wido this is a good way to avoid CORS. thanks for sharing.
To set cookie of other domains, you need to enable 3rd-party cookie on server side.
Set-Cookie: SiteSite=None; Secure
if you use nginx, add proxy_cookie_path / "/; Secure; SameSite=None;";
it also means both server and client side must be secure (https)

This is something I would need to investigate. Haven't been able to do so yet.

@wido I have tested it with nginx. it works well.
setting cookie header is supported by haproxy 1.8+

Would you be so kind to share your Nginx configuration? This could then also go into the docs of the UI

rohityadavcloud · 2021-01-18T11:56:32Z

Given the complexity and that it won't be turnkey (work out the box) - should this be made hidden/pluggable or let the LB handled by the nginx (instead of UI)?

wido · 2021-01-18T15:30:04Z

Given the complexity and that it won't be turnkey (work out the box) - should this be made hidden/pluggable or let the LB handled by the nginx (instead of UI)?

I don't see how the LB can handle this without doing anything in the UI.

If users don't touch the config.json it works as expected. This feature only requires some additions to the Nginx configuration.

It would make presenting the UI to users with multiple management servers much easier.

I haven't tested the latest code yet. @utchoang can you resolve the conflict to make testing easier?

weizhouapache · 2021-01-18T16:00:07Z

@wido this is a good way to avoid CORS. thanks for sharing.
To set cookie of other domains, you need to enable 3rd-party cookie on server side.
Set-Cookie: SiteSite=None; Secure
if you use nginx, add proxy_cookie_path / "/; Secure; SameSite=None;";
it also means both server and client side must be secure (https)

This is something I would need to investigate. Haven't been able to do so yet.

@wido I have tested it with nginx. it works well.
setting cookie header is supported by haproxy 1.8+

Would you be so kind to share your Nginx configuration? This could then also go into the docs of the UI

@wido
here are my nginx configurations

(1) config.json on primate server

{
  "servers": [
    {
      "name": "mgt01",
      "apiBase": "/mgt01/client/api"
    },
    {
      "name": "mgt02",
      "apiBase": "/mgt02/client/api"
    },
    {
      "name": "mgt03",
      "apiBase": "/mgt03/client/api"
    }
  ],

(2) nginx config on primate server

server {
    listen                      443 ssl http2;
    server_name                 *.cloud.your.domain;
......
    location / {
......
        location ^~ /mgt01/client {
            rewrite ^/mgt01/(.*)$ /$1 break;
            proxy_pass   https://mgt01.cloud.your.domain;
        }

        location ^~ /mgt02/client {
            rewrite ^/mgt02/(.*)$ /$1 break;
            proxy_pass   https://mgt02.cloud.your.domain;
        }

        location ^~ /mgt03/client {
            rewrite ^/mgt03/(.*)$ /$1 break;
            proxy_pass   https://mgt03.cloud.your.domain;
        }
    }
}

(3) nginx on cloudstack management server

upstream mgtservers {
    hash $request_uri consistent;
    server 10.10.10.10:8080;
}

server {
    listen                      443 ssl http2;
    server_name                 *.cloud.your.domain;
......
    location / {
......
        proxy_pass http://mgtservers;
        proxy_cookie_path / "/; Secure; SameSite=None;";
    }
}

weizhouapache · 2021-01-18T16:01:52Z

@wido the above config does not work with latest commit by @utchoang
even if I change the config.json to the following

  "servers": [
    {
      "name": "mgt01",
      "apiHost": "/mgt01",
      "apiBase": "/client/api"
    },
    {
      "name": "mgt02",
      "apiHost": "/mgt02",
      "apiBase": "/client/api"
    },
    {
      "name": "mgt03",
      "apiHost": "/mgt03",
      "apiBase": "/client/api"
    }
  ],

this is fixed by

diff --git a/src/permission.js b/src/permission.js
index d865b43e..201e9b0c 100644
--- a/src/permission.js
+++ b/src/permission.js
@@ -42,7 +42,11 @@ router.beforeEach((to, from, next) => {

   const servers = Vue.prototype.$config.servers
   const serverStorage = Vue.ls.get(SERVER_MANAGER)
-  const serverFilter = servers.filter(ser => ser.apiHost + ser.apiBase === serverStorage.apiHost + serverStorage.apiBase)
+  var apiFullPath = null
+  if (serverStorage) {
+    apiFullPath = serverStorage.apiHost + serverStorage.apiBase
+  }
+  const serverFilter = servers.filter(ser => ser.apiHost + ser.apiBase === apiFullPath)
   const server = serverFilter[0] || servers[0]

   Vue.axios.defaults.baseURL = server.apiHost + server.apiBase

weizhouapache · 2021-01-18T16:04:18Z

Given the complexity and that it won't be turnkey (work out the box) - should this be made hidden/pluggable or let the LB handled by the nginx (instead of UI)?

I don't see how the LB can handle this without doing anything in the UI.

If users don't touch the config.json it works as expected. This feature only requires some additions to the Nginx configuration.

It would make presenting the UI to users with multiple management servers much easier.

I haven't tested the latest code yet. @utchoang can you resolve the conflict to make testing easier?

agree with @wido
it is a very useful for users who have multiple cloudstack platforms and want to have a centralized management on all platforms.

utchoang · 2021-01-19T06:18:08Z

@wido Can you run test again? Thank you.

weizhouapache · 2021-01-19T09:18:21Z

@utchoang tested good.

one concern, to keep backwards compatibility, apiHost should be set to "" if it is not found in config.json (there is no apiHost in config.json in primate 1.0.0 or cloudstack 4.15.0.0).

weizhouapache · 2021-01-19T14:09:27Z

@utchoang it seems......
config.servers[0].apiHost || '' + config.servers[0].apiBase is equals to
config.servers[0].apiHost || ('' + config.servers[0].apiBase)

utchoang · 2021-01-20T00:49:15Z

@weizhouapache This is not true because baseUrl needs a combination of apiHost and apiBase. In your way, if apiHost exists in config.json then baseUrl is only equal to apiHost. I will edit it again to see better

weizhouapache · 2021-01-20T07:34:42Z

@utchoang it works with commit "Fix for clear code."

add multiple management server support

4beb09d

rohityadavcloud reviewed Dec 17, 2020

View reviewed changes

utchoang added 2 commits December 22, 2020 13:06

Merge branch master into feature/multiple-manage-server

51de686

using https/domain

7086410

rohityadavcloud marked this pull request as ready for review December 22, 2020 06:21

rohityadavcloud marked this pull request as draft December 22, 2020 06:21

utchoang marked this pull request as ready for review December 22, 2020 06:31

fix duplicated variable

1dd081c

utchoang added 2 commits December 22, 2020 15:13

fix duplicated variable

d076e42

Merge branch 'master' into feature/multiple-manage-server

57e52e6

ravening reviewed Jan 11, 2021

View reviewed changes

public/config.json Outdated Show resolved Hide resolved

remove server QA-primate on config file

6358382

using apiHost for vm Console

e5bd647

Merge branch 'master' into feature/multiple-manage-server

9d73302

fixes for server manager not found in localstorage

21f5749

Check to avoid apiHost not found in config.json

36a3503

utchoang added 2 commits January 20, 2021 07:59

Fix for clear code.

0379654

Merge branch master into feature/multiple-manage-server

40924bc

This was referenced Apr 1, 2021

Check and fix all UI issue from the archived primate repository apache/cloudstack#4726

Closed

UI: Add multiple management server support apache/cloudstack#4885

Merged

Add multiple management server support #898

Are you sure you want to change the base?

Add multiple management server support #898

Conversation

utchoang commented Dec 17, 2020

utchoang commented Dec 17, 2020

blueorangutan commented Dec 17, 2020

blueorangutan commented Dec 17, 2020

rohityadavcloud Dec 17, 2020

Choose a reason for hiding this comment

utchoang Dec 17, 2020

Choose a reason for hiding this comment

utchoang Dec 18, 2020

Choose a reason for hiding this comment

utchoang commented Dec 22, 2020

blueorangutan commented Dec 22, 2020

blueorangutan commented Dec 22, 2020

utchoang commented Dec 22, 2020

blueorangutan commented Dec 22, 2020

blueorangutan commented Dec 22, 2020

ravening commented Jan 11, 2021

utchoang commented Jan 12, 2021

rohityadavcloud commented Jan 12, 2021

ravening commented Jan 12, 2021

wido commented Jan 12, 2021

ravening commented Jan 12, 2021

rohityadavcloud commented Jan 12, 2021

utchoang commented Jan 12, 2021 • edited Loading

weizhouapache commented Jan 12, 2021

utchoang commented Jan 13, 2021

wido commented Jan 13, 2021 • edited Loading

weizhouapache commented Jan 13, 2021

wido commented Jan 14, 2021

http://127.0.0.1:8080 should be replaced your CloudStack management

Server's actual URI

http://127.0.0.1:8080 should be replaced your CloudStack management

Server's actual URI

weizhouapache commented Jan 15, 2021

weizhouapache commented Jan 15, 2021

wido commented Jan 15, 2021

rohityadavcloud commented Jan 18, 2021

wido commented Jan 18, 2021

weizhouapache commented Jan 18, 2021

weizhouapache commented Jan 18, 2021 • edited Loading

weizhouapache commented Jan 18, 2021

utchoang commented Jan 19, 2021

weizhouapache commented Jan 19, 2021

weizhouapache commented Jan 19, 2021

utchoang commented Jan 20, 2021

weizhouapache commented Jan 20, 2021

utchoang commented Jan 12, 2021 •

edited

Loading

wido commented Jan 13, 2021 •

edited

Loading

weizhouapache commented Jan 18, 2021 •

edited

Loading