18:15:15 <adetalhouet> #startmeeting Armoury Weekly 18:15:15 <odl_meetbot> Meeting started Mon Oct 5 18:15:15 2015 UTC. The chair is adetalhouet. Information about MeetBot at http://ci.openstack.org/meetbot.html. 18:15:15 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:15:15 <odl_meetbot> The meeting name has been set to 'armoury_weekly' 18:15:31 <adetalhouet> #topic Roll Call 18:15:48 <adetalhouet> please pound in for ppl attending the meeting 18:15:48 <alagalah> #info alagalah 18:15:52 <subh> #info subh 18:16:05 <grmontpetit> here 18:16:10 <grmontpetit> #info grmontpetit 18:16:43 <adetalhouet> Let's wait one more minute to see if edwarnicke or anipbu will join us 18:17:27 <anipbu> #info anipbu 18:18:08 <adetalhouet> Ok so let's start 18:18:16 <adetalhouet> #topic Agenda Bashing 18:18:27 <adetalhouet> I came up with 2 main goals for today 18:18:33 <adetalhouet> #info Release plan for M3 18:18:43 <adetalhouet> Discuss the release plan I started 18:18:53 <adetalhouet> See if there is anything we could add or explain better 18:18:59 <adetalhouet> #info On going tasks 18:19:15 <adetalhouet> Check on going tasks, I know there are not much but we need to get things started 18:19:32 <adetalhouet> Do you guys have anything you would like to discuss>? 18:19:51 <grmontpetit> Did we get the sequence diagram completed ? 18:20:01 <adetalhouet> alagalah: maybe around the SFC use case (base on the mail you sent to the ML) ? 18:20:17 <adetalhouet> grmontpetit: no, not yet, it is still a draft 18:22:06 <adetalhouet> #link discussion around SFC/Armoury/Tacker https://lists.opendaylight.org/pipermail/armoury-dev/2015-October/000039.html 18:23:28 <adetalhouet> alagalah: want to discuss about that? 18:23:43 <adetalhouet> #topic Beryllium release plan 18:23:51 <adetalhouet> #link https://wiki.opendaylight.org/view/Armoury/Beryllium_Release_Plan 18:23:54 <alagalah> adetalhouet, Well.... I'm still waiting for others to chime in 18:24:15 <alagalah> adetalhouet, Anyone here have any experience with Tacker ? 18:24:32 <adetalhouet> alagalah: I agree, I don't feel a real involvement around here 18:24:55 <adetalhouet> alagalah: I personally don't have much - but you mentioned someone at RH 18:25:37 <adetalhouet> alagalah: the idea behind a Tacker driver in Armoury is kind of a passthrough to Tacker APIs? 18:26:18 <grmontpetit> No exp with Tacker 18:26:51 <grmontpetit> is the project still in incubation ? 18:27:16 <adetalhouet> grmontpetit: yes it is 18:27:47 <adetalhouet> ok so while waiting for other to show up I guess let me present the deliverables for our release plan 18:28:16 <adetalhouet> #info Sequence diagram presenting the whole integration from a user perspective 18:28:30 <anipbu> I'm embarrassed to say that I do not have experience with Tacker. :/ 18:28:47 <adetalhouet> So here it's basically finish to work that Maros started, including the community feedback 18:29:40 <adetalhouet> #info NF Catalog - I think you guys are pretty much aware of what it is. The model is there, could be remodel based on our need. We could add the NF instances list there also 18:30:01 <adetalhouet> #info Driver registery - this is to be done 18:30:17 <adetalhouet> #info Workload manager - we have ariel patch to review 18:30:39 <adetalhouet> I reviewed it in fact, it needs to use the MDSAL artifacts for binding-parent 18:30:41 <alagalah> adetalhouet, I'll have a look at the model for NF Catalog... last time I looked there was a lot of duplicate information with the SF YANG model, but that may not be a bad thing, as long as we stay true to what is CONF data and what is OPER thats the main thing 18:31:38 <alagalah> adetalhouet, So what is Driver ? I've seen it mentioned in the context of Tacker being a Driver, but shouldn't this really be an external orchestrator ? 18:31:41 <adetalhouet> alagalah: I totally agree, I'm not even sure knowing what it the CONF and OPER data needed here, and for sure we don't want to replicate SFC 18:31:52 <adetalhouet> but we need enough data to be able to spin up VNF 18:32:29 <alagalah> adetalhouet, Right, some duplication I think is unavoidable, and in some instances desirable (for cohesiveness) ... ideally we may borrow some groupings from it... but then you will have a project dependency (?) 18:32:56 <adetalhouet> Tacker is an external orchestrator, we will leverage it in Armoury to make it useable through Armoury 18:33:08 <alagalah> adetalhouet, Right, hence do we want to keep calling them Drivers? 18:33:12 <adetalhouet> The purpose in Armoury is not to only have Tacker's driver, but many others 18:33:15 * alagalah was a little confused by that 18:33:33 <adetalhouet> Well for Tacker, it might not be a full driver per se 18:33:40 <alagalah> adetalhouet, Oh trust me, I'm not getting all "Marsha marsha marsha" about Tacker... :) ... 18:33:44 <adetalhouet> But for the other, like Docker, maybe the term driver is accurate 18:33:57 <alagalah> adetalhouet, Its the term Driver that is confusing me, but lets not sidetrack... 18:34:19 <alagalah> adetalhouet, I'll mentally %s/Driver/ExternalOrchestrator/g :) 18:35:03 <adetalhouet> alagalah: that works for me, but we will keep the term driver in Armoury, because it's not all about Tacker here 18:35:28 <adetalhouet> alagalah: in fact I don't fact changing the name, I just need some more feedback from others 18:35:36 <adetalhouet> Nothing is sealed in rock here ;) 18:35:45 <anipbu> So will we have driver-registry api for registry of drivers ... and then a separate driver-tacker, driver-docker, and driver-{INSERT_OTHER_DRIVER_HERE}? 18:35:54 <alagalah> adetalhouet, Apologies, I have to leave in a few minutes... apart from making any changes to the NF YANG I'd like to potentially propose, is there a use-case we want to focus on for be ? 18:36:18 <alagalah> anipbu, Can you say more about the driver-docker ? 18:36:27 <alagalah> anipbu, Would this be to work with docker compose? Or Swarm ? 18:36:29 <adetalhouet> alagalah: good question, and yes there is. The one you mentioned in the mail. SFC/Armoury/Tacker 18:36:35 <alagalah> adetalhouet, Ok cool 18:36:38 <adetalhouet> I think this could be accomplish in a Be timeframe 18:36:52 <adetalhouet> And this could be a good way to showcase the benefit of Armoury in ODL 18:36:58 <alagalah> adetalhouet, I do too 18:37:16 <adetalhouet> alagalah: Np for you leaving, thanks for attending and the feedback :)_ 18:37:17 <alagalah> adetalhouet, Ok, I have to head off for an appt... I'm terribly sorry... I'll look for update on email 18:37:23 <alagalah> Thanks 18:37:29 <adetalhouet> alagalah: Sure, thanks 18:37:46 <adetalhouet> anipbu: Yes I agree with what you're saying 18:37:58 <adetalhouet> This is exactly the point of the dfiver-registery 18:38:19 <adetalhouet> So the user will specify in the NF data what kind of drive to use 18:38:40 <adetalhouet> And based on it, Armoury will create the appropriate workload for the requested NF 18:40:34 <adetalhouet> ok so back on the release plan 18:40:37 <adetalhouet> last item is 18:40:39 <adetalhouet> #info SFC use case - as per as the description in this mail: https://lists.opendaylight.org/pipermail/armoury-dev/2015-October/000039.html 18:41:13 <adetalhouet> Does anyone has any deliverables to add? 18:41:31 <adetalhouet> anipbu: edwarnicke: grmontpeti: subh: ? 18:42:01 <anipbu> The list of deliverables look good for Be. 18:42:46 <adetalhouet> anipbu: ok thanks for being there, I think we're only 2 in this meeting 18:42:55 <adetalhouet> #topic On going tasks 18:43:14 <adetalhouet> #info the sequence diagram is still ongoing, did not have much feedback 18:43:33 <adetalhouet> #link https://git.opendaylight.org/gerrit/#/c/27263/ initial diagram 18:44:02 <adetalhouet> #link https://lists.opendaylight.org/pipermail/armoury-dev/2015-September/000028.html Mail thread 18:44:10 <subh> adetalhouet: I am also here.. listening. 18:44:33 <adetalhouet> #info the workload manager model 18:44:36 <adetalhouet> subh: good to know :) 18:44:42 <adetalhouet> #link https://git.opendaylight.org/gerrit/#/c/27182/ patch to review 18:44:46 <adetalhouet> #undo 18:44:46 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x18d7350> 18:44:51 <adetalhouet> #link https://git.opendaylight.org/gerrit/#/c/27182/ patch in review 18:45:03 <adetalhouet> Do you guys have anything you're interested in? 18:45:12 <adetalhouet> Or any thought of things we could achieve? 18:45:22 <anipbu> On my side, I am still digesting the sequence diagram and designs proposed by the other team members. 18:45:33 <adetalhouet> please feel free to add any card to our trello board 18:45:36 <adetalhouet> #link https://trello.com/b/zsERKgeV/odl-armoury 18:45:38 <subh> adetalhouet: I am new, you can assign few task to me 18:45:50 <adetalhouet> anipbu: ok good, do you have any feedback to give? 18:46:34 <anipbu> I am still translating it to Chinese to share with our extended team. I will collect feedback and share later. 18:46:35 <adetalhouet> subh: Great, thanks for the involvement, you could create the model for the dfiver-registery 18:46:52 <adetalhouet> anipbu: Ok thank you very much 18:47:23 <anipbu> I am adding a new card to trello for some M3 items. Such as adding documentation outlines per M3 requirements. 18:47:34 <subh> could you please add some pointers so that It will help me for the task 18:47:39 <adetalhouet> anipbu: Great thank you 18:48:12 <adetalhouet> subh: Of course, so what we need for the driver register is a list of supported driver 18:48:30 <subh> ok 18:48:53 <adetalhouet> in the model you could create a grouping specifying information needed for a driver 18:49:05 <subh> I think first i should read once the driver model 18:49:14 <subh> please correct me if I am wrong 18:49:24 <adetalhouet> such information can be seen in the SFC yang model, but we don't want to replicate everything 18:49:33 <subh> ok 18:49:38 <adetalhouet> subh: there is no driver model yet 18:49:51 <adetalhouet> that's the whole thing, it needs to be done 18:49:56 <subh> ok .. 18:50:20 <adetalhouet> but on a high level perspective, this model need a list and a grouping 18:50:22 <adetalhouet> list of driver 18:50:31 <adetalhouet> grouping to define a driver 18:50:53 <subh> oK I'll check once the SFC project and let you know 18:51:09 <adetalhouet> then inside this grouping could be for instance the name, the type, the CPU, the RAM, ... and many others information to create the VM 18:51:24 <subh> ok .. ok 18:51:44 <adetalhouet> subh: ok sure, don't hesitate to send question to the ML and/or in the IRC - I'm almost always there 18:51:54 <subh> sure :) 18:52:23 <subh> so the list will give the detail of vm/container right 18:52:53 <subh> then we'll use this information to launch the VM 18:53:02 <adetalhouet> not quite, the list will list all the available drivers, and will contain information for each driver 18:53:21 <adetalhouet> And yes, this info will be use to spawn the VM 18:53:48 <anipbu> Now that we have finalized our Release Plan, I think we should start an email thread for our features list: odl-armoury-workloadmanager, odl-armoury-driver-registry, odl-armoury-categlog, odl-armoury-driver-tacker is my proposal 18:54:36 <adetalhouet> Sure, this seems right to me 18:54:38 <subh> ok, but you mentioned RAM, CPU in the details, i think that should be in instance detail 18:54:42 <adetalhouet> anipbu: could you send the mail? 18:55:18 <anipbu> Yes, please pound action for me. 18:55:37 <adetalhouet> subh: yes, I must have been confused, RAM, CPU, ..., those kind of details are regarding the NF not the driver 18:55:44 <adetalhouet> the driver will leverage those 18:56:05 <adetalhouet> #action anipbu to send mail proposing Armoury features list 18:56:30 <anipbu> subh: it should list info for drivers, not the VM 18:56:31 <subh> adetalhouet I will try to check the driver data from docker 18:57:15 <adetalhouet> subh: Yes perfect. anipbu is right 18:57:56 <adetalhouet> Anything you want to add? 18:58:12 <subh> thanks anipbu and adeltalhouet , i'll check and let you know for any question 18:58:19 <adetalhouet> ok good 18:58:19 <subh> :) 18:58:28 <adetalhouet> #topic cookies 18:58:38 <adetalhouet> #endmeeting