maintenance hasn't implemented a database storage yet

[viniarck]

In the initial iteration, this NApp is still storing the maintenance windows in a Python dict, however, to be prod grad and provide permanent storage it should implement a NoSQL storage (for more context, in this kytos-ng release 2022.2, topology will be migrated, and other NApps will follow suit later, so maintenance also being a potential candidate too depending on the priorities for 2022.3).

[Ktmi]

So, I've been trying to work on this, but I think we need to consider changing the format that we send and receive information about the maintenance windows, both through REST API, and through the event bus.

First, we should partition the list of items used to contain the ids for all the switches, links and UNIs into three separate lists on the REST API end. Managing all three types of objects through just the items list is ergonomically awkward, and increases the required complexity to parse the incoming data. Additionally, we are already storing the three types of objects in separate lists internally. Using separate lists should also help towards fixing #25.

Next, for the purpose of being able to serialize the database, we should change how we store information to only use the IDs of these objects. Currently it seems that for UNIs and Links, it is expected that we will be storing a reference to the object, rather than its ID.

Finally, we should change how we communicate the event to other NApps to use there IDs. Currently we send references of the objects entering maintenance, which can work. but for Links the reference isn't the actual object, so the receiver extracts the ID from the reference.

What I have done so far still isn't in a necessarily usable state, but this seems to be the direction I'm moving in. Let me know if this seems to be the right way to go.

[viniarck]

First, we should partition the list of items used to contain the ids for all the switches, links and UNIs into three separate lists on the REST API end. Managing all three types of objects through just the items list is ergonomically awkward, and increases the required complexity to parse the incoming data. Additionally, we are already storing the three types of objects in separate lists internally. Using separate lists should also help towards fixing #25.

Agreed. switches, links, interfaces would make it more ergonomic. As it is, in the front-end it had to deal with a very difficult dynamic parsing of the serialized objects. In the data model, also status relies on an integer to give its semantics which requires conversion to a string for users to understand what it means, which also made it a bit difficult for the front-end, it might be something to also consider if we'll make enhancements in the data model, converting this to a string since it's a high-level attribute could make it easier to consume and deal with.

Next, for the purpose of being able to serialize the database, we should change how we store information to only use the IDs of these objects. Currently it seems that for UNIs and Links, it is expected that we will be storing a reference to the object, rather than its ID.

I think it's great to store effectively what the application needs to perform its responsibilities and also be able to restore scheduling states such as what mef_eline does, we want to defer to DB as much as we can eliminating self.maintenances from Main, here's some guidelines we've been following when storing on MongoDB as a future ref. if storing the ids and only few attributes suffice for what we need then we should go for it, for instance, topology also doesn't store all links attrs, what I'll recommend is, let's review the requirements and if anything else needs to be stored.

Finally, we should change how we communicate the event to other NApps to use there IDs. Currently we send references of the objects entering maintenance, which can work. but for Links the reference isn't the actual object, so the receiver extracts the ID from the reference.

IDs could work and simplify things, ultimately we'll need a NApp responsible who is managing that resource to update in memory GenericEntity status just so it works well with NApps that use these shared objects. Maybe maintenance could register status func for Switch and Interface and leave Link for topology, as long as the IDs that are being used in the messages are sufficient for the NApp to find efficiently (and low cost) that object then it can work well. On topology it also needs to update the DB accordingly since status can be updated (just so both the objects in memory that NApps still rely on and DB are all set), we need these issues to be handled as well:

kytos-ng/topology#87

kytos-ng/topology#62

What I have done so far still isn't in a necessarily usable state, but this seems to be the direction I'm moving in. Let me know if this seems to be the right way to go.

@Ktmi, very good points and initial approach. What I'll advise is let's first also make sure that the requirements that @italovalcy, Jeronimo and Arturo previously mapped are also reviewed and assessed, @italovalcy has posed them here #59 (comment), let's refine it first, and them I think you could start a lightweight blueprint consolidating what it's feasible for this version and aligned with the requirements/expectations, cc'ing @ajoaoff (since we also had a PR in draft, we'll need to sync this blueprint and if there might be possibility to divide and conquer the scope), how does that sound?

Thanks, if you need my help let me know, happy to help with reviews or brainstorm sessions if you need.