Update dl_vlan validation to allow mask

[ajoaoff]

Closes #132

• Accept dl_vlan in the format vlan/mask in addition to vlan

[viniarck]

@ajoaoff looks good to me.

Could you update the changelog? Also, could you provide either a migration MongoDB command in the changelog itself if it's short, or a migration script updating/mapping dl_vlan values as string? This change would break anything but it would leave different types in the collection that can become confusing, 2022.3.X will be used in production at AmLight, thanks.

[ajoaoff]

@viniarck I'll provide the migration script, but anyway I don't think this PR should ship with 2022.3.x, it is a change for 2023.1. What do you think about creating a branch for the changes expected to ship with 2023.1?

[viniarck]

@viniarck I'll provide the migration script, but anyway I don't think this PR should ship with 2022.3.x, it is a change for 2023.1. What do you think about creating a branch for the changes expected to ship with 2023.1?

@ajoaoff, yes, we won't ship to 2022.3.X, when I read my comment again, I summarized it too much, what I meant to write was, since AmLight will deploy 2022.3, and this will be shipped to master and eventually 2023.1, then ideally they can use this script before using/deploying 2023.1 to keep the collection with dl_vlan type the same.

Antonio, if you could also update the openapi.yml spec as well, that'd be great, we'll start reusing the openapi-core validate decorator that you've implemented to also validate some endpoints on flow_manager.

Regarding a new branch for 2023.1 although it's a great idea, at this time, I'd rather maintain master and then on upstream only keep tag and start creating old branches for patched versions since the tag by itself wouldn't suffice, sometimes we don't have a new version scope defined yet, and then contributions might also land on master. We can keep evolving this discussion if we can benefit from a simpler workflow.

[Alopalao]

This PR also handles any and untagged cases I am working on. mef_eline issue #219

[viniarck]

LGTM. Thanks for also pushing this script @ajoaoff.

Antonio, before merging, let's also update the changelog, if you can also mention there about this script that'd be great. @italovalcy when AmLight upgrades to 2023.1 some months down the road you'll probably want to run this script.

[italovalcy]

@viniarck and @ajoaoff, since this is a major change that will impact other Napps, IMO we have to increase the API version and keep the old one compatible with the previous format—maybe providing an abstraction between the two versions (which will convert int to string).

Another strategy would be supporting both int and string.

WDYT?

[Alopalao]

Good point. If we decide to unify the string format for dl_vlan, of_core will be affected since the vlan_id is returned as int (here). Combination of int and string is already supported, here vlan with mask it is returned as string.
Minor detail, it is easier/faster to differentiate strings from integers while writing code since they represent special cases.

[viniarck]

Agreed @italovalcy @Alopalao, I tend to avoid mixing different type for the same field dl_vlan, but it's becoming evident that dl_vlan being Optional[Union[str, int]] would make things way simpler, and only use a str when setting a mask as of_core has been designed, not completely breaking compatibility with the API as well while extending it to support the mask. @ajoaoff could you adapt this part? That way we also wouldn't need the script as well. Thanks

Regarding bumping v3 though, let's leave it to when we address the other validations in general on issue #43 that we have on our radar (cookie_mask mandatory for deletions an so on).

[viniarck]

@ajoaoff thanks for this PR and pushing the latest commits. I went ahead and finished reverting the scripts related changes and updated the changelog just so this PR can get merged right away unblocking also mef_eline uni any/untagged feature that @Alopalao is working on.