Hi, Greg. Thank you! Will put you on the agenda for next week. And to the team, please review the new update before our next meeting so that we could have an efficient discussion.
Thanks to everyone. 发件人: Waines, Greg [mailto:[email protected]] 发送时间: 2017年3月1日 21:45 收件人: [email protected] 抄送: Ulrich Kleber; Hui Wang; Stefan Arntzen; Jolliffe, Ian; Edgar StPierre; Yue Yuan 主题: Re: Change in availability[master]: Updating Commit based on initial review during OPNFV HA meet... Qiao Fu, FYI … I have just submitted an update to the Overview document of the HA Guest API work. Is it possible to get another discussion of the Overview document on the Agenda for next week ? thanks, Greg. From: "Qiao Fu (OPNFV Code Review)" <[email protected] <mailto:[email protected]> > Reply-To: "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> > Date: Thursday, February 23, 2017 at 3:07 AM To: Greg Waines <[email protected] <mailto:[email protected]> > Cc: Ulrich Kleber <[email protected] <mailto:[email protected]> >, Hui Wang <[email protected] <mailto:[email protected]> >, Stefan Arntzen <[email protected] <mailto:[email protected]> >, "Jolliffe, Ian" <[email protected] <mailto:[email protected]> >, Edgar StPierre <[email protected] <mailto:[email protected]> >, Yue Yuan <[email protected] <mailto:[email protected]> > Subject: Change in availability[master]: Updating Commit based on initial review during OPNFV HA meet... Qiao Fu has posted comments on this change. ( https://gerrit.opnfv.org/gerrit/26663 ) Change subject: Updating Commit based on initial review during OPNFV HA meeting, as well as submitted comments on the review. ...................................................................... Patch Set 2: (6 comments) sorry for the late reply. I was out of office last week. https://gerrit.opnfv.org/gerrit/#/c/26663/2/Support_For_HA_Guest_APIs/OPNFV_HA_Guest_APIs-Overview_HLD.rst File Support_For_HA_Guest_APIs/OPNFV_HA_Guest_APIs-Overview_HLD.rst: Line 40: - VM Event Notification and Acknowledgement Please explain the difference to the notifications in doctor project. I think these is some misunderstanding here. Probably because the entry here is a little bit misleading. The event notification here does not mean VM notify the guest os or the MANO, but indicates the other way round. I suggest to change this entry as "Infrustructure event notification and VM ack" Line 42: - VM Resource Scaling Yeah agree that the next 'iteration' of the Overview Document needs to "bri Greg. I think some explaination should be made here. I think the HA API is kind of misleading. People may consider the VM directly uses these APIs and get the info that they need. However from your reply above, I see that the NFVO and VNFM are the entities that use these. The NFVO and VNFM use the nova restful API to trigger certain action, and the nova proxy kidnaps these command, trigger some interaction between the host and VM using these API, then give the command back to the real nova. (don't know if I understand right about these). if so, I think we may not call these as API but rather should be message flow between VM and the host OS. for each entry listed above, I suggest to add a short explaination or example about how to use the capability by NFVO and VNFM. PS2, Line 52: M Heartbeating and Health Checking which entity should use this API. Is it nova or nova proxy? my understanding is the API is used by nova or nova proxy, to indicate the daemon to work and reply to nova about the health of the VM. Am I right? PS2, Line 88: a corrective action that overrides the default : corrective action specified at regist this corrective action should be override by the VM or the VNFM? I think the VNFM should do such decision. or at least the VNFM should have such capability PS2, Line 155: In addition to notifications, there is also an opportunity for the VM : to vote on any proposed event. Voting precedes all notifications, : and offers the VM a chance to reject the event that the OpenStack Cloud : wishes to initiate. The USE CASE here is that the we are providing a mechanism for the Guest VM I think there should be a scheme to notify the nova proxy which operation is strong and should be forced without consideration of the VM, and which operation can be postponed and wait for the VM to prepare smoothly.So there could be 3 situations. 1) the action is not urgent, nova proxy asks the vm to vote and the VM agrees to take the action 2) the action is not urgent, nova proxy asks the vm to vote, the vm rejects the action. nova proxy hand the action to nova after the vm finishes preparing 3) the action is urgent. nova proxy directly hands this action to nova without asking the vm to vote. PS2, Line 182: VM Peer State Notification and Messaging who should take action when the peer state message fails? should such situation be uploaded to the VNFM? -- To view, visit https://gerrit.opnfv.org/gerrit/26663 To unsubscribe, visit https://gerrit.opnfv.org/gerrit/settings Gerrit-MessageType: comment Gerrit-Change-Id: I1e44efe6052dfa84cdffd9bbebe8be86e4992121 Gerrit-PatchSet: 2 Gerrit-Project: availability Gerrit-Branch: master Gerrit-Owner: Greg Waines <[email protected] <mailto:[email protected]> > Gerrit-Reviewer: Edgar StPierre <[email protected] <mailto:[email protected]> > Gerrit-Reviewer: Greg Waines <[email protected] <mailto:[email protected]> > Gerrit-Reviewer: Hui Wang <[email protected] <mailto:[email protected]> > Gerrit-Reviewer: Ian Jolliffe <[email protected] <mailto:[email protected]> > Gerrit-Reviewer: Qiao Fu <[email protected] <mailto:[email protected]> > Gerrit-Reviewer: Stefan Arntzen <[email protected] <mailto:[email protected]> > Gerrit-Reviewer: Ulrich Kleber <[email protected] <mailto:[email protected]> > Gerrit-Reviewer: Yue Yuan <[email protected] <mailto:[email protected]> > Gerrit-HasComments: Yes
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
