Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

security: please separate reference implementation VS generic APIs #104

Closed
glimchb opened this issue Aug 29, 2022 · 3 comments
Closed

security: please separate reference implementation VS generic APIs #104

glimchb opened this issue Aug 29, 2022 · 3 comments
Assignees
@mestery
Labels
security APIs or code related to security area (e.g. ipsec)

Comments

@glimchb
Copy link
Member

glimchb commented Aug 29, 2022 •
edited
Loading

looking at this section of the readme file : https://github.com/opiproject/opi-api/blob/main/security/README.md#architecture

I do think we need to separate reference implementation VS generic APIs...
vici on this page is just an example...
everybody else are free to use their own implementation instead of strongswan or vici...
see the picture from https://github.com/opiproject/opi-poc/blob/main/storage/OPI-storage-SPDK-bridge.png

also storage in this repo doesn't talk about specific implementations storage readme

Originally posted by @glimchb in #102 (comment)
@glimchb
Copy link
Member Author

glimchb commented Aug 29, 2022 •
edited
Loading

fyi @shorman-corigine @mestery

@mestery
Copy link
Contributor

mestery commented Aug 29, 2022

This is a good point for sure. I've intentionally made the current OPI Security IPsec APIs very closely tied to strongSwan to ferret this out.

@mestery mestery added the security APIs or code related to security area (e.g. ipsec) label Aug 29, 2022
stevedoyle added a commit to stevedoyle/opi-api that referenced this issue Jun 24, 2024
@stevedoyle
refactor(security)!: Change API to a CRUD API
00668d2 
Update the OPI security API to use CRUD operations and to use more
non-implementation specific types. The v1 API messages were very specifc
to a strongSwan implementation. This version updates the API to
align with the more generic types from the IETF yang model described
in RFC 9061.

Using an API version tag of v2alpha1 as the API is not backwards
compatible with the v1 IPsec APIs.

Adpoting protobuf naming conventions for all messages and services.

fixes: opiproject#446, opiproject#104

BREAKING-CHANGE: Breaks compatiblity with the existing OPI security
API definition.

Signed-off-by: Stephen Doyle <stephen.doyle@intel.com>
@stevedoyle stevedoyle mentioned this issue Jun 24, 2024
Merged
stevedoyle added a commit to stevedoyle/opi-api that referenced this issue Jun 24, 2024
@stevedoyle
refactor(security)!: Change API to a CRUD API
12a4fba 
Update the OPI security API to use CRUD operations and to use more
non-implementation specific types. The v1 API messages were very specifc
to a strongSwan implementation. This version updates the API to
align with the more generic types from the IETF yang model described
in RFC 9061.

Using an API version tag of v2alpha1 as the API is not backwards
compatible with the v1 IPsec APIs.

Adpoting protobuf naming conventions for all messages and services.

fixes: opiproject#446, opiproject#104

BREAKING-CHANGE: Breaks compatiblity with the existing OPI security
API definition.

Signed-off-by: Stephen Doyle <stephen.doyle@intel.com>
stevedoyle added a commit to stevedoyle/opi-api that referenced this issue Jun 24, 2024
@stevedoyle
refactor(security)!: change API to a CRUD API
840235f 
Update the OPI security API to use CRUD operations and to use more
non-implementation specific types. The v1 API messages were very specifc
to a strongSwan implementation. This version updates the API to
align with the more generic types from the IETF yang model described
in RFC 9061.

Using an API version tag of v2alpha1 as the API is not backwards
compatible with the v1 IPsec APIs.

Adpoting protobuf naming conventions for all messages and services.

fixes: opiproject#446, opiproject#104

BREAKING-CHANGE: Breaks compatiblity with the existing OPI security
API definition.

Signed-off-by: Stephen Doyle <stephen.doyle@intel.com>
stevedoyle added a commit to stevedoyle/opi-api that referenced this issue Jun 24, 2024
@stevedoyle
refactor(security)!: change API to a CRUD API
c97b78b 
Update the OPI security API to use CRUD operations and to use more
non-implementation specific types. The v1 API messages were very specifc
to a strongSwan implementation. This version updates the API to
align with the more generic types from the IETF yang model described
in RFC 9061.

Using an API version tag of v2alpha1 as the API is not backwards
compatible with the v1 IPsec APIs.

Adpoting protobuf naming conventions for all messages and services.

fixes: opiproject#446, opiproject#104

BREAKING-CHANGE: Breaks compatiblity with the existing OPI security
API definition.

Signed-off-by: Stephen Doyle <stephen.doyle@intel.com>
stevedoyle added a commit to stevedoyle/opi-api that referenced this issue Jun 28, 2024
@stevedoyle
refactor(security)!: change API to a CRUD API
383d344 
Update the OPI security API to use CRUD operations and to use more
non-implementation specific types. The v1 API messages were very specifc
to a strongSwan implementation. This version updates the API to
align with the more generic types from the IETF yang model described
in RFC 9061.

Using an API version tag of v2alpha1 as the API is not backwards
compatible with the v1 IPsec APIs.

Adpoting protobuf naming conventions for all messages and services.

fixes: opiproject#446, opiproject#104

BREAKING-CHANGE: Breaks compatiblity with the existing OPI security
API definition.

Signed-off-by: Stephen Doyle <stephen.doyle@intel.com>
artek-koltun pushed a commit that referenced this issue Jul 1, 2024
@stevedoyle @artek-koltun
refactor(security)!: change API to a CRUD API
c5c996b 
Update the OPI security API to use CRUD operations and to use more
non-implementation specific types. The v1 API messages were very specifc
to a strongSwan implementation. This version updates the API to
align with the more generic types from the IETF yang model described
in RFC 9061.

Using an API version tag of v2alpha1 as the API is not backwards
compatible with the v1 IPsec APIs.

Adpoting protobuf naming conventions for all messages and services.

fixes: #446, #104

BREAKING-CHANGE: Breaks compatiblity with the existing OPI security
API definition.

Signed-off-by: Stephen Doyle <stephen.doyle@intel.com>
@sandersms
Copy link
Contributor

Close issue with CRUD model addition on July 1, 2024 checkin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mestery mestery

Labels
security APIs or code related to security area (e.g. ipsec)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mestery @glimchb @sandersms