Most data modeling exercises are very similar to an OOP implementation approach:
1. Identify / Create the base/common "class" 2. Extend the base/common class with more domain specific attributes and behaviors 3. Operate on the specific instance you need In this case, we can define an Event YANG module and define additional modules that extends the event model for the Fault, Scaling, etc. Once the YANG schemas are created, we can use YANG aware tools to transact the underlying data across implementation boundaries (via REST, RESTCONF, websockets, protocol buffers, message queues, etc.) and have each of the front-end, middleware, backend etc. share the same underlying data models. We can even consider something like sysrepo for database which has native YANG support. Having the YANG models ensures data validations and consistency across boundaries. Since there is already a reference implementation, it would be straightforward to create a YANG schema counterpart capturing the event messaging data structure(s). Peter On Tue, Nov 15, 2016 at 9:48 AM SULLIVAN, BRYAN L <bs3...@att.com> wrote: > Peter, that would be great. Can you give some overview of how this can be > done? I started a section of the wiki page > https://wiki.opnfv.org/display/ves/Operational+Framework on “Field > Mapping” where you can put your input in the table or as a paragraph. Or > just reply here and I will capture the concept in the table. > > > > Thanks, > > Bryan Sullivan | AT&T > > > > *From:* Peter Lee [mailto:pe...@corenova.com] > *Sent:* Tuesday, November 01, 2016 11:40 AM > *To:* SULLIVAN, BRYAN L <bs3...@att.com>; > opnfv-tech-discuss@lists.opnfv.org > *Subject:* Re: [opnfv-tech-discuss] [Barometer][VES] Mapping monitored > source data to backend interface/model items > > > > Sounds like a good use case for modeling using YANG. > > Please feel free to ping me if interested in exploring how. > > Best, > > Peter > > On Tue, Nov 1, 2016 at 10:07 AM SULLIVAN, BRYAN L <bs3...@att.com> wrote: > > On the Barometer project (FKA SFQM) call today, I made the following > suggestion that was welcomed by the team. Basically the Barometer project > will be developing the “frontend” (i.e. agent) data source aspects of > analytics collection (i.e. interfacing with hosts and VMs etc to collect > analytics), and delivering it to “backends” (i.e. collectors such as > VIMs/monitoring systems) via protocols such as REST/HTTP, Kafka, SNMP etc. > I think this is a good development, as most of the frontend heavy lifting > will be done in the collectd upstream, and specific projects in OPNFV such > as Barometer and VES just need to take care of the mapping to the backend > interfaces and data models. > > > > To minimize development/maintenance of the mapping between the collectd > plugin data sources and the specific backend protocol/data model, I > suggested that we consider a mapping table as a static or manageable > attribute of the configuration for the agent. For example, as you can see > in Maryam’s team implementation of the ves_plugin.py > <https://github.com/maryamtahhan/OpenStackBarcelonaDemo/blob/master/ves_plugin/ves_plugin.py>, > values for the data source items are mapped to fields in the JSON-based VES > message structure in individual code statements. Even in this early demo > version, there are many monitored data items, and this can be expected to > expand greatly. It would be nice if we can automate as much of this as > possible through a table with rows such as: > > > > { plugin_name, plugin_instance, type_name, type_instance }, { > domain.property.property.property… } > > > > Theoretically, it should be possible in many cases to simply run thru such > a table and copy the source data to the proper place in the target event > structure. If calculations are needed on the source, they might still > require a discrete statement, but many of the fields could be just copied. > For target properties which are lists, that would need to be considered as > well, but I think we could indicate that through some variable reference or > “property[x]”. > > > > Any input on this idea, experience implementing such mapping systems etc, > is appreciated. > > > > Thanks, > > Bryan Sullivan | AT&T > > _______________________________________________ > opnfv-tech-discuss mailing list > opnfv-tech-discuss@lists.opnfv.org > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss > > -- > > Peter Lee > Corenova Technologies > +1 310 400 6450 > pe...@corenova.com > -- Peter Lee Corenova Technologies +1 310 400 6450 pe...@corenova.com
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
