V1InterfaceBridge seems to be missing

[tripledes]

While working on the KubeVirt Ansible modules, I found out that I cannot remove VMIs any more as it complains with the following message:

AttributeError: 'module' object has no attribute 'V1InterfaceBridge'

Message coming from:

api_client.py", line 268, in __deserialize

The thing is that the implementation for the V1InterfaceBridge seems to be missing but it's referenced by V1Interface.

Having a look to KubeVirt OpenAPI definition, the type seems to be declared but has no definition, I guess that's the actual problem.

[booxter]

@SchSeba do we need a new build for python client here, or we can close it already? How do Ansible modules consume the client? building from master?

[SchSeba]

@booxter Travis already do the job for us :)

About the ansible maybe @tripledes can help us

[tripledes]

@SchSeba @booxter I had an specific commit hash on the requirements file so I knew it kinda worked well. That being said, I'm no longer the maintainer of the modules, perhaps @pkliczewski can help.

[pkliczewski]

@SchSeba I do not think that merged PR was correct. In general BrigdeInterface type was wrongly defined. The generator do not allows empty types and I proposed a PR to fix the type which was suppose to be discussed tomorrow during network team meeting.

[booxter]

@pkliczewski apart from generator limitations, are there any more issues you see in keeping the attribute of map type?

[pkliczewski]

@booxter I think that the same issue is with this type. Both of them are empty. I proposed to remove empty type and use string instead or extend the type to contain some meaningful data. In principal empty type seems to be wrong even there are generator limitations.

[booxter]

@pkliczewski that's probably a good discussion to have regardless of how we handle client / generator limitations. The original idea captured in networking API draft was that the maps (bridge, slirp) will contain more attributes (like delegateIp for bridge binding), but since then there were some changes in direction for these auxiliary attributes, and it may well be that we don't want a map anymore.

If that's the case, we can of course make a different decision and then your fix will fit better than what we've merged today. Please leave your other PR open and see if we still have reasons to keep these attributes as maps. If not, perhaps we should convert them into a new attribute called "type" that would be of string type and allow a particular set of values like "bridge" and "slirp". I don't think that we need an attribute per type then as in your PR.

[pkliczewski]

@booxter I agree. Let's have this discussion and fix the type so let's keep this issue open so we can track this change.

[kubevirt-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[pkliczewski]

Since we moved to dynamic client it is not needed anymore.