14:01:31 #startmeeting promise 14:01:31 Meeting started Mon Aug 31 14:01:31 2015 UTC. The chair is r-mibu. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:31 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:01:31 The meeting name has been set to 'promise' 14:01:44 #topic roll call 14:01:57 #info Ildiko Vancsa 14:02:02 #info Bertrand Souville 14:02:14 #info Bryan Sullivan 14:02:42 #info Ryota Mibu 14:02:59 #chair ildikov 14:02:59 Current chairs: ildikov r-mibu 14:03:22 #chair bertys 14:03:22 Current chairs: bertys ildikov r-mibu 14:03:34 #chair bryan_att 14:03:34 Current chairs: bertys bryan_att ildikov r-mibu 14:09:41 #info Gerald 14:11:14 has someone started the meeting already? 14:12:35 yep 14:14:42 topic: Use of JIRA for Tasks 14:14:55 #info Way of working: there are Jira tickets, but the way forward is not clear. should we organize into short/mid/long-term issues? 14:15:43 #info proposal to better utilize features of Jira to do so 14:16:08 #chair GeraldK 14:16:08 Current chairs: GeraldK bertys bryan_att ildikov r-mibu 14:18:30 #info inviting people from other projects to weekly meetings is of general interest and should be kept 14:21:14 #info requirements track should stay a couple of month ahead of the implementation track 14:21:56 #topic Lab sharing with IPv6 project 14:24:21 #info Peter Lee 14:24:46 #info Bin: VM is used as IPv6 router; integration efforts with ODL trying to solve gaps 14:25:39 #info Bin: after this has been addressed, infrastructure could be used for Promise 14:26:53 #info IPv6 project is using Spirent community lab 14:27:25 #info Peter: would be great if Promise could send our requirements (ODL version, number of nodes, ...) to Infra-Team and they set it up (without Promise getting "empty" hardware 14:40:06 #topic JIRA PROMISE-6 14:40:55 #action Peter to update Promise-6 with additional contributors 14:41:45 #topic JIRA PROMISE_23 14:41:57 #info team should review and provide +1/+2 to the gerrit commit 14:42:04 #link https://gerrit.opnfv.org/gerrit/#/c/1345/ 14:42:37 #topic JIRA PROMISE-19 14:43:12 #info Mirantis would be interested to re-open Blazar 14:44:42 #info related to Promise long term architecture 14:45:49 #info there is long-term effort to extract Nova scheduler. we can start utilizing the latest status of this project and update Blazar accordingly 14:46:45 #chair corenova 14:46:45 Current chairs: GeraldK bertys bryan_att corenova ildikov r-mibu 14:46:49 #info this extracting is *in the best case* done in Mitaka-release, but most likely in later release 14:51:57 #info shim-layer approach seems the only way we can achieve our goals in few months. we should give high prio to solve southbound I/F gaps. but long-term architecture should not be neglected. 14:53:31 #info Peter will make initial draft 14:54:06 #info allocation part might be difficult. Peter is assuming all allocation request go via shim layer to make this work. we need to write down this big picture. 14:55:34 #topic promise software architecture diagram (shim layer) 14:56:06 #info this is not part of weekly Promise meeting, but additional technical meeting 14:56:54 #link https://jira.opnfv.org/secure/attachment/10501/opnfv-promise.png 15:00:11 #info top-left: package "yan/opnfv-promise" has dependency on other packages and schema files 15:01:11 #info "yangforge" provides several internal types 15:03:20 #info ComputeElement, VMImage, etc are instances of ResourceElement; ServerInstance is instance of ResourceInstance 15:05:35 #info Promise instance needs to be tied to OpenStack. two ways to implement this: 1) tight integration between OpenStack and Promise by direct mapping logic and 2) a new layer encapsulating OpenStack 15:06:54 #info OpenStack package can even capture different versions of OpenStack, e.g. different API versions 15:08:31 #info the OpenStack package can also be (re-)used for other (OPNFV) projects 15:08:49 #info (this is a powerful feature) 15:09:10 #undo 15:09:10 Removing item from minutes: 15:11:15 #info there is not yet a basic demo for the OpenStack package 15:12:20 #info this is planned for this week 15:13:09 #info i.e. initial transaction to add a ResourceProvider and populate it with all related data 15:13:42 #info idea is to capture all details, except things done via API extensions. 15:15:05 #info Ildiko: who stores the reservations? Peter: idea is that Promise shim-layer stores all this information required, encapsulating a lot of existing information available downstream. 15:16:02 #info Ildiko: are you planning to include "quotas"? Peter: quota system would be query, but in the first step not allow to change the quotas. 15:16:16 #undo 15:16:16 Removing item from minutes: 15:16:33 #info Ildiko: are you planning to include "quotas"? Peter: quota system would be "query"-based, but in the first step not allow to change the quotas in OpenStack. 15:17:27 #info shim-layer is kind of emulating OpenStack thus allowing to implement Promise features in the shim-layer 15:20:31 #info this requires a feedback-loop to keep states synchronized (best in real-time). some delay might be acceptable for Promise (this has to be analyzed/discussed in more detail) 15:21:03 #info Gerald: Promise might be okay with a more coarse-grained information. 15:21:36 #info Peter: this also depends on the usage of the reservation system, whether you do reservations/changes on a per minute or per day basis 15:21:45 #undo 15:21:45 Removing item from minutes: 15:21:52 #info Peter: this also depends on the usage of the reservation system, whether you do reservations/changes on a per minute or per day frequency 15:28:41 #info Peter could need help to model missing things in the yangforge schemas; also the code logic for reservation is missing. 15:29:54 #info Ildiko: do we need all those models to evaluate the approach as such? No, not all the models, but the basic ones, e.g. storage/network could be done later. 15:30:56 #info Ildiko: are the flows etc already captured, e.g. in the requirement document? 15:32:00 #info No, we don't have these explicit flows. 15:36:05 #info Peter is quite confident that this shim-layer will allow for the basic reservation features among different resource types; but if there are specific behaviours, we may not be able to sufficiently model this (at least in the initial version). 15:40:41 #info Peter will prepare and share sequence diagrams around the reservation flows 15:43:14 #info team should then support Peter to continue from these baseline diagrams to extend to other flows/logic 15:55:20 #info discussion on documentation priorities/needs. 15:55:56 #endmeeting