Meeting scheduled for 7/12/2018 at 9am EST

• Discussed open questions:

Before the meeting, So far I’ve met two issues while developing the code needs some advice, BTW, SO and AAI code are referenced:

1. SO and AAI have self-configuration format and related property parse:

1. SO: format is JSON, the property parse is org.openecomp.mso.properties.MsoJsonProperties.
2. AAI: format is flat, just key-value, the property parse is java.util.Properties

First of all, IMO in the pom.xml dependency setting of Policy, Policy try to depends on SDC and common library of ONAP, avoid so many another component.

If use JSON format as SO, either leverage the SO’s JsonProperties or find another common one.

If use the flat format as AAI, we could use the built-in property parse, is related easier.

1. Since logging is very necessary, in order to align with another component of Policy, which Logging tool should distribution use?

1. So uses org.openecomp.mso.logger.MsoLogger
2. Aai uses org.onap.aai.cl.api.Logger

Should Policy Use org.onap.policy.common.logging.ONAPLoggingContext?

Decision is to use java.util.Properties for decoding JSON and org.onap.policy.common.logging.ONAPLoggingContext.

I have few questions based on the wiki, you might have already discussed these, but I missed it:

• How policies are provided in CSAR? Is it part of TOSCA or provided as part of artifacts in CSAR?  From the name "PolicyDecoderToscaPdpX" I assume, it converts TOSCA based policies to XACML using sdc tosca parser. But how about "PolicyDecoderCsarPdpD/A"?
  <Liam>
  In practice, policies could be provided many ways in a CSAR. There could be a separate Policy files packaged in the CSAR, the policy might be derived from the TSOCA template (as in the actual case here for HPA), or the policy could be in an artifact completely separate from the CSAR. The idea with the design presented on the wiki page is that the packaging of the policy doesn’t matter all that much. We just design towards an interface and we provide implementations that can managed the various permutations and combinations of Policy packaging. The PolicyDecoderToscaPdpX/ PolicyDecoderCsarPdpD/ PolicyDecoderCsarPdpA are examples of implementations for such permutations
  </Liam>
• I am not clear why we need multiple subscriptions, can you just give some usecases/examples?
  <Liam>
  If for example we had a number of policies or policies for particular types of VNFs. An Ericsson VNF might want to have Policy Ericsson_A  and have placement strategy in OOF based on that policy. That would be one subscription. Then Huawei might have policy Huawei_B which requires a different placement strategy in OOF, that would be  a different subscription.
  </Liam>
• In the case of multiple subscriptions, are we using same client credentials for all subscriptions?
  <Liam>
  In the case of multiple subscriptions, the client credentials should be supplied for each subscription. However, many subscriptions could use the same credentials.
  </Liam>

Confirmed Liam's answers are the direction we want to go.

Assigned user stories and created new user story for INotificationCallback.