Validation of existence on items of a maintenance window

[italovalcy]

Trying to capture the discussion we had in the PR #64 (see thread):

viniarck on Dec 1, 2022

@Ktmi what's the expected behavior if a non active or non existing switch (interface or link) id is present in any of the lists? that might be outside of the scope of this PR, but it's something that we need to align either in the blueprint or a new issue. This can also lead to invalid data being inserted into the collection, which although is not desirable, it might be acceptable if we make clear that's not being validated in this iteration that will be delivered.

@Ktmi Ktmi on Dec 8, 2022

So, Ive been thinking about this one, and I think that we should allow ids for things we can't confirm to exist to be used. My main reasoning for this is that when we create a maintenance window, we won't be 100% certain of the state of the network's topology. It could be that switches where removed or added, making some ids that were previously invalid into valid, or valid into invalid.

@viniarck viniarck on Dec 8, 2022

Right @Ktmi, I believe this would make sense for this iteration. It's probably something to be refined in the blueprint, just so network operators who will use in production are also aware of this, and then in the future we can keep evolving and even try to integrate more with topology as new requirements are discussed and aligned. Thanks.

@italovalcy italovalcy 19 hours ago

@viniarck and @Ktmi, the way I see is: we could have a parameter so that the operator informs Kytos that he/she is requesting an inexistent item on purpose and then the validation should be ignored. Something like force or skip_check_exists , etc.

[Ktmi]

This should be doable. The code already exists to get the devices affected by a window, so this code should be able to be converted into a validator of some kind.

[Ktmi]

Closed with #78