- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- Re: It seems that R80.10 VSec doesn't support open...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It seems that R80.10 VSec doesn't support openstack higher than Mitaka (due the placement API)
Starting with OCATA placement API have become mandatory in every Openstack deployment.
Unfortunately it seems that CheckPoint integration with openstack get confused with this new endpoint.
In fact before placement there was only a service-type under nova, that was compute.:
#openstack endpoint list | grep nova
| 8413db31b008469ea0ebd3529b07078d | RegionOne | nova | compute | True | public | http://x.y.z.w:8774/v2.1 |
| ea733c09627c4a1f8bc9a9c90c6099e5 | RegionOne | nova | compute | True | admin | http://x.y.z.w:8774/v2.1 |
| fd12c313db914695a63f730330fedbf4 | RegionOne | nova | compute | True | internal | http://x.y.z.w:8774/v2.1 |
With the addition of placement service, now, when you ask for nova endpoints, you get 'compute' and 'placement'.
#openstack endpoint list | grep nova
| 3248904d9d2b4983a9f1b30fda68c9b2 | RegionOne | nova | placement | True | admin | http://x.y.z.w:8778/ |
| 3ba077c236b14d9fbb18e2cbe2fd61fd | RegionOne | nova | placement | True | internal | http://x.y.z.w:8778/ |
| 6539258c683146e8bc80a924c7a00d0a | RegionOne | nova | placement | True | public | http://x.y.z.w:8778/ |
| 8413db31b008469ea0ebd3529b07078d | RegionOne | nova | compute | True | public | http://x.y.z.w:8774/v2.1 |
| ea733c09627c4a1f8bc9a9c90c6099e5 | RegionOne | nova | compute | True | admin | http://x.y.x.w:8774/v2.1 |
| fd12c313db914695a63f730330fedbf4 | RegionOne | nova | compute | True | internal | http://x.y.z.w:8774/v2.1 |
When you try to get items from the datacenter objects VSec incorrectly tries to ask for 'servers/list' to the placement api instead of the compute api, getting a 404.
Removing the placement endpoints fixes the problem but leaves openstack in unusable state.
Apparently this is due to the code inside "openstack_plugin.jar", specifically the ServiceType.class which defines:
public enum ServiceType
{
IDENTITY("keystone", "identity"), COMPUTE("nova", "compute"), IMAGE("glance", "image"), BLOCK_STORAGE("cinder", "volume"), OBJECT_STORAGE("object-store", "object-store"), NETWORK("neutron", "network"), EC2("ec2", "ec2"), TELEMETRY("ceilometer", "metering"), ORCHESTRATION("heat", "orchestration"), SAHARA("sahara", "data_processing"), UNKNOWN("NA", "NA");
...
which doesn't handle the ambiguity of nova/compute vs nova/placement.
Sometimes, depending on the order the service catalog is returned, it succeded to get the correct endpoint.
Does anyone know if there's a solution for this?
Thanks.
Andrea
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just a guess, but I suspect we'll have to fix the CloudGuard Controller to support this new endpoint.
Will check.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Assuming you are referring to the changes in Keystone API version -
Currently CloudGuard controller supports only v2. In the next JHF over R80.10 (not yet released), OpenStack v2 and v3 will be supported.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Merav,
thank you for your answer, but I believe that the point is not the support for keystone v2 or v3 rather that the controller does not handle the fact that under nova (> ocata) two endpoints (compute and placement) could be found instead of the one (compute) that used to be in past versions and it routes the request incorrectly.
We implemented a workaround in haproxy to fix this.
Everytime a request comes for placement api from checkpoint we assume that it was intended for compute, thus we send it to the correct endpoint.
Like this:
frontend nova_api_placement-front
bind x.y.z.w:8778
option httplog
option forwardfor except 127.0.0.0/8
option http-server-close
timeout client 600s
acl checkpoint src a.b.c.d
reqrep ^([^\ :]*)\ /(.*) \1\ /v2.1/\2 if checkpoint
use_backend nova_api_os_compute-back if checkpoint
mode http
default_backend nova_api_placement-back
When the request comes from checkpoint it matches the acl and we rewrite the url (adding /v2.1 ) and use the compute backend instead of the default placement.
This way works.
Bye,
Andrea
![](/skins/images/6980CBA140F726D3EF221370390D7B61/responsive_peak/images/icon_anonymous_message.png)