OOF 2018-02-19 Meeting Notes

Whoever is working on the tests should communicate through JIRA to prevent duplication. Should invite Ikram into these calls. Offline call for deep dive.

Flows that should be successful and those that should fail. We want to return invalid request type cases. Need to have performance measures.

We want optimizer to ignore failure and still continue without losing its state:

1. continuous input data, optimizer should function in the presence of noisy data – this maybe beyond scope of R2 (for usecases such as SON)?
2. break it down into validation checks (e.g. incomplete data) versus noise in timeseries data (large anamolies to be ignored): first case is in scope for R2, second one is not in scope for R2

Sonar provides static code analysis – we can wait to see the outcome from sonar job results and plan accordingly.

We need the ONAP system to spin up the whole system in one hour (with readiness check). Having a clean separation between being ready and announcing it. Should we do roll this up into functional tests?

HPA related discussions. Items discussed and conclusions/agreements.

1. VDU specific hardware requirements using policies: It is agreed that OOF OSDF and HAS don't have any restrictions on the representation of HPA capabilities of a given VDU in one policy or set of policies. This is up to the entity creating the policy records.
2. Specifying HPA capability mandatory requirements and score/weight in case of optional: OOF infrastructure and HAS infrastructure does not interpret the HPA capabilities and attributes and it is up to the HPA filter implementation in HAS. Introducing 'is_mandatory' and 'weight' attributes along with version and hwArchin of each HPA capability is okay with the OOF team.
3. VNF and VDU (VFModule) : OOF, at this time, does not have a way to return the region and flavor for each VDU back to the SO. OOF, at this time consider the entire VNF as one entity and return one region and one flavor. There are two ways to address this.
   1. SO to decompose the VNF (with Multiple VDUs) and provide list of VDUs in its request to OOF and OOF to make placement decisions for each VDU independently and provide region & flavor for each VDU back to the SO. This is right thing to do, but it may not be possible in R2 time frame.
   2. Second option is to put a restriction that each VNF in TOSCA having only one VDU in it. We thought that if option (b) is chosen, it needs to be brought to architecture subcommittee for approval.
4. Performance: There are multiple filters in OOF and more filters can be added in future. If each filter run independent of others, the performance can take a big hit if there are large number of regions in the A&AI. In 5G, we are thinking that there could be 5000 cloud regions (due to edge clouds) and X number of filtering going through all 5000 edge clouds for each VDU placement decision is costly. It is confirmed today that OOF does not run all filters simultaneously. These filters are executed in sequential fashion. Order of filters that are executed are at this time based on a configuration file and hence is fixed. Each filter is given set of regions as candidate list and each filter is expected to return subset of regions as output. One filter output is given as input to the next filter. That way, only the first filter may work on all 5000 regions and but subsequent filters act on only subset of the regions. In summary, each filter takes the candidate region list and outputs the subset of regions that satisfy policies of that filter.
5. Filter priorities are currently based on the configuration file. In future, execution time of each filter will be considered to change the order of future filter execution. Shankar mentioned that some ML based algorithms can be used too to dynamically change the order.
6. Usage of aggregate labels for HPA features such as "VM Sizes" and "Instance types" and "Openstack flavors" in policy instead of individual HPA capabilities as requirement: Ramki brought this point. OOF team said that there is no limitation in OOF as it does not interpret the attributes. It is up to the HPA filter implementation. HPA filter implementation can use aggregate label by figuring out the regions that have that aggregation label. As long as multicloud component provides the aggregation lables for each region (which it needs to do anyway), this is possible. Mechanics discussed are as follows:
   
   1. Policy would have Cloud owner and aggregation label information.
   2. If VDU can be placed, say X number of regions, then there could be X number of policies with each policy having owner and aggregation label.
   3. HPA filter will choose one of the aggregation label in the policies by matching the aggregation label in the cloud-region.
   4. If there are no policies with HPA aggregation label or no matching aggregation labels in A&AI, then the HPA capabilities in the policies are used to get the best region set and flavor set in each region.
   5. It is yet to be discussed whether aggregation label policy support to be implemented in R2 or beyond.
7. Policy authoring : Just like distance & latency filters, HPA filters can also be authored manually. That is, even if TOSCA template does not define the HPA capabilities, policies can be added through policy authoring mechanism. If HPA capabilities are specified in TOSCA template for each VDU, then policy is created dyanmically by POLICY ENGINE when the TOSCA template is onboarded. This flexibility is a good thing in that HPA functionality can be tested independent of TOSCA template/SDC-change and POLICY ENGINE changes.