add pool allocation to statefulsets and deploymets

[SchSeba]

add the ability to allocate and preserve mac address for statefulsets and deploymets.

add a new annotation kubemacpool/mac with a list of requested or allocated mac addresses related to the deployment or statefulset.

when scale up the deployment we are going to add more addresses into the list, and when scale down the allocated one will stay there.

the addresses will be free only after the deploymet/statefulset is removed

[phoracek]

Maybe we should support it only for StatefulSet. Per Kubernetes documentation:

Like a Deployment , a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.

[chezbut]

I generally agree this should only be supported for a statefulset, and only for replicas:1

[chezbut]

At least in the initial release.

[phoracek]

Why only for replicas:1? Could you share your concerns?

[chezbut]

I mean per MAC address. If somehow it were broken out in the Yaml so that each different member of the statefulset has its own reserved Mac that didn’t change, that would be fine. But generally the use case of these is old, legacy type software that can only run replicas:1 anyway, such as Juniper network appliances. I think it would be a lot easier for development, testing, troubleshooting and prevention of issue filings if it were locked down to replicas:1 for the initial release, and if people wanted another similar host, they could spin up a different statefulset with a different reserved Mac.

…

On Fri, Mar 27, 2020 at 11:57 AM Petr Horacek ***@***.***> wrote: Why only for replicas:1? Could you share your concerns? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGEX34LVSP6I7MDREWKRCTRJTSI3ANCNFSM4HCRP5HQ> .

[phoracek]

I see, makes sense. Let's not work too hard for users that don't exist :) With single replica, it would be good enough.

We are currently rewording the project to be more stable and always ready to serve (since webhook downtimes are now preventing users from applying Pods and VMs).

Would you be interested in adding support for StatefulSets by any chance?

[chezbut]

unfortunately not with everything going on at the moment :(

[phoracek]

No problem, stay strong! We may add it eventually ourselves, but currently we are focused on the stabilization and VM support.

[atiwaripw]

from what I can see we still dont persist mac for pod from stateful set.
Is this still in plan..?

[phoracek]

@atiwaripw at the moment we don't plan to implement it. That being said, we are open to accept contributions adding such feature to the project.