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.

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

DANM's IPAM as a separate offering #244

Open
navjotsingh83 opened this issue Jan 5, 2021 · 3 comments
Open

DANM's IPAM as a separate offering #244

navjotsingh83 opened this issue Jan 5, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@navjotsingh83
Copy link

navjotsingh83 commented Jan 5, 2021

Is this a BUG REPORT or FEATURE REQUEST?:
feature

As we know, DANM's IPAM does wonderful things :) especially I love the NO IP option (besides the static one). But, to be practical, its not that DANM will be the preferred meta-CNI in customer premises especially when it comes to multi-tenancy.
However, we still would like to use the versatile IPAM. So it should be made available as a separate offering so that one can use the IPAM with other CNI plugins too.

This should be prioritised and will surely make DANM popular and known.

@Levovar
Copy link
Collaborator

Levovar commented Jan 5, 2021

well DANM has DANM IPAM, Multus has Whereabouts :)
the difference between the IPAMs is basically mirroring the main difference between these projects: one glorifies the CNI API, while the other actively hides it and believes in an integrated, K8s-style network management API

IP management is part of network management, therefore IPAM information is currently part of the network APIs. it is actually not that hard to implement CNI_ADD and CNI_DEL library calls in addition to direct Golang interfaces, but the IPAM would be still looking for the DANM APIs during Allocate, and Release calls

if you are okay with these APIs then you should use DANM in the first place :)
if not... theoretically speaking it would be possible to cut out the IPAM parts from the existing network management APIs, and simply refer an IPAM API object from a DANM network object. doing this in a backward compatible manner is the big work though, and the reason why I haven't done it so far
personally I don't see this endavour valuable enough to justify this cost, but at the same time if somebody feels strong enough about it we can definitely discuss how it can be done

@Levovar Levovar added the enhancement New feature or request label Jan 5, 2021
@navjotsingh83
Copy link
Author

Hi,

Like I mentioned, that product/application teams cannot regulate/dictate the infrastructure choices of the customers. So we are currently facing a challenge where almost all our customers prefer multus to DANM (reasons might not be technical). So, atleast I saw a value-add in offering DANM's IPAM seperately so that it fits well in the multus (or any other) ecosystem and we do not miss out on the good features.

But yes, you would be the best person to do the ROI analysis for the same, and atleast I am not sure on how beneficial will it be in the long run, neither I can guarantee whether customers will agree to have a specific DANM's IPAM. Moreover our use-case was that we want the CNI to setup the networking, but not provide the IP, so that we (the application) can plumb the IP based and support HA based on floating-ip. This is not a typical cloud-native use-case but mandatorily require for legacy applications on containers.

@Levovar
Copy link
Collaborator

Levovar commented Jan 6, 2021

thank you for the additional information!
yeah I know exactly the use case you are talking about, as you can guess the existence of the none option is not accidental :)

also make no mistake the enhancement itself totally makes sense, it has been floating around for some time now. just my personal experience is that whoever uses Multus in production will use it with Whereabouts, without regard to technical reasons. if features were more important than lobbying and marketing power DANM would be used to begin with in those environments :)

so for this reason I personally won't take up the enhancement, but I will keep it open because it is definitely valid, doable, and would be an accepted one. it just needs somebody with a strong enough interest to pick it up

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants