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