18:16:08 <adetalhouet> #startmeeting Armoury weekly
18:16:08 <odl_meetbot> Meeting started Mon Sep 28 18:16:08 2015 UTC.  The chair is adetalhouet. Information about MeetBot at http://ci.openstack.org/meetbot.html.
18:16:08 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:16:08 <odl_meetbot> The meeting name has been set to 'armoury_weekly'
18:16:23 <adetalhouet> #topic Roll Call
18:16:34 <adetalhouet> Please, #info in
18:16:41 <mmarsale> #info mmarsale
18:18:09 <adetalhouet> alagalah: anipbu: edwarnicke: grmontpetit: subh: Are you joining the meeting?
18:18:19 <grmontpetit> #info grmontpetit
18:18:20 <alagalah> adetalhouet, I'm here
18:18:23 <alagalah> #info alagalah
18:18:32 <anipbu> #info anipbu
18:18:34 * alagalah is on another meeting though, couldn't avoid it
18:18:59 <adetalhouet> alagalah: ok sure, thanks for being here anyway
18:19:51 <adetalhouet> giving the others one more minute to pound in the meeting
18:20:04 <grmontpetit> I'd like to see that sequence diagram
18:20:21 <adetalhouet> ok so let's go over the Agenda
18:20:25 <adetalhouet> #topic Agenda bashing
18:20:35 <adetalhouet> #info  Action Items from last meeting
18:20:49 <adetalhouet> #info mmarsale did start the diagram sequence
18:21:00 <adetalhouet> #link https://git.opendaylight.org/gerrit/#/c/27263/ diagram sequence
18:21:26 <adetalhouet> #info there is also its associated ML
18:21:33 <mmarsale> #link https://www.websequencediagrams.com/
18:21:42 <adetalhouet> #chair mmarsale
18:21:42 <odl_meetbot> Current chairs: adetalhouet mmarsale
18:21:51 <adetalhouet> mmarsale: thxs
18:22:09 <adetalhouet> so regarding the diagram, I think this is a good start
18:22:23 <adetalhouet> Do we have any insight?
18:22:51 <adetalhouet> I agree with your comment mmarsale
18:23:15 <mmarsale> adetalhouet: there was a short discussion on mailing list, but didnt go far...
18:23:49 <adetalhouet> mmarsale: yes, I agree with the comments you made on the ML
18:24:09 <adetalhouet> mmarsale: but this is true, we didn't have a lot of ideas/comments
18:24:18 <grmontpetit> what will be contained in the driver registry ?
18:24:32 <grmontpetit> and what is a "driver" ?
18:24:55 <adetalhouet> well so far I don't even know if we will use a driver registery - this was a proposition
18:24:55 <mmarsale> grmontpetit: driver - code to interact with underlying infrastrucure e.g. openstack
18:25:16 <adetalhouet> and this will be use by the workload-manager
18:25:22 <grmontpetit> so there could be Openstack, docker, etc. &
18:25:26 <adetalhouet> in order to spin up VMs/containers
18:25:27 <mmarsale> grmontpetit: adetalhouet: if we will have more drivers, we need to register them somewhere
18:25:50 <mmarsale> grmonteptit: and choose from them somehow when initiating an NF
18:25:54 <adetalhouet> mmarsale: I totally agree
18:25:58 <grmontpetit> mmarsale can you give a concrete example of an ODL Driver ? is the ML2 mechanism driver one of them ?
18:26:08 <adetalhouet> This is why I introduce the notion of driver register
18:26:13 <adetalhouet> register/registery
18:26:22 <adetalhouet> but I didn't have a lot of feedback on this
18:27:12 <adetalhouet> I will re-trigger the mail thread to ask for review of our proposition/design
18:27:12 <grmontpetit> the driver is used in order to use the NF in the catalog rigth ?
18:28:01 <adetalhouet> well the NF will provide information to the driver so it can correctly create the desired workload-manager based on the desired NF
18:28:52 <grmontpetit> is it the right time to ask questions ?
18:29:02 <mmarsale> grmonteptit: my view: the catalog  has files and images necessary for the NF, Workload manager should provide APIs to spawn the NFs and drivers are used to do the heavy lifting on spawning a VM, loading image and configuring it ...
18:30:03 <mmarsale> grmontpetit: if its not the right time, we might sum the questions and send to mailing list afterwards
18:30:13 <adetalhouet> #info mmarsale view on how NF/driver/workload: the catalog  has files and images necessary for the NF, Workload manager should provide APIs to spawn the NFs and drivers are used to do the heavy lifting on spawning a VM, loading image and configuring it ...
18:30:19 <grmontpetit> how are drivers registered to the catalog ?
18:30:26 <grmontpetit> err: driver registry
18:30:28 <adetalhouet> grmontpetit: mmarsale: I think this is the right time to ask questions
18:30:44 <grmontpetit> who is responsible to register the drivers to the driver registry ?
18:30:56 <grmontpetit> and who knows about the drivers ?
18:31:07 <mmarsale> grmontpetit: probably the drivers themself ... or users to write the configuration for ODL
18:31:23 <adetalhouet> in the end I think the drivers will be available under the config tree in mdse.
18:31:33 <adetalhouet> mdse/mdsal
18:31:46 <adetalhouet> and as mmarsale the user write them
18:32:22 <grmontpetit> the catalog, what type of NF will it contains ? how will it be populated ?
18:33:16 <mmarsale> grmontpetit: good question, it should be very freeform to hold basically anything (URLs to files, configuration etc.) and should be populated by users ... or maybe a file system reading code for easier use
18:33:42 <grmontpetit> will we provide an abstraction layer to NF ?
18:34:13 <mmarsale> grmontpetit: in what sense ?
18:34:13 <adetalhouet> I agree with you mmarsale, but we shouldn't store images directly
18:34:26 <adetalhouet> URL to images is a good solution
18:34:34 <mmarsale> adetalhouet: if we have URLs, they can be external so we dont have to store them
18:34:38 <mmarsale> adetalhouet: agree
18:34:48 <mmarsale> adetalhouet: and we can still hold images if we want
18:35:47 <mmarsale> #link https://github.com/marosmars/yanglib - this is a prototype of ODL based catalog for YANG schemas I implemented some time ago
18:35:54 <adetalhouet> mmarsale: and where would we hold them?
18:36:04 <alagalah> Q: So is the intention to be a catalog of existing INSTANCES of VNFs ?
18:36:28 <mmarsale> alagalah: I would keep the catalog just for NF confiurations and NFs
18:36:37 <mmarsale> alagalah: an have another list for instances
18:36:49 <mmarsale> alagalah: linking to the NFs in catalog
18:37:01 <adetalhouet> well the instance could be either a sub-list  for  the workload-manager
18:37:04 <alagalah> mmarsale, Ok, just trying to think about how this all ties together. I am currently working on a patch for SFC for service-function.yang
18:37:54 <adetalhouet> right, those instances could also resides in the NF catalog under a different path
18:38:02 <alagalah> mmarsale, Instances of SFs are very much maintained there.... and I'm ok with there being one central place for instances that is referenced (actually would strongly want that) ...
18:38:46 <mmarsale> alagalah: sure, we are still trying to agree on how this ties together .. so its not yet 100% decided
18:38:59 <alagalah> adetalhouet, I guess I'd like to see (so would be happy to work on) a sequence diagram for how things like Tacker - Armoury - SFC SF work together
18:39:16 <mmarsale> alagalah: I would like to see that
18:39:30 <alagalah> mmarsale, Agreed, just wanted to get some perspectives... I have no preconceived notions other than avoiding duplicity and ensuring cohesiveness
18:40:05 <adetalhouet> alagalah: I really agree instances could be hold in Armoury for SFC
18:40:08 <alagalah> mmarsale, Also, there is a dire need for this NOW, and not sure its fair to push Armoury into too early an implementation
18:40:29 <adetalhouet> but yes we need a well define interaction diagram
18:40:32 <alagalah> mmarsale, Right, and there's some serious implications to that....
18:41:22 <alagalah> mmarsale, For instace, SFs are hardwired to SFFs today... ideally this would be dynamic, but before getting to that, I wanted to have a consistent SF model first... and since I'm working on it, makes sense to look at the interactions between external dependencies whilst I'm at it....
18:41:35 <alagalah> (one of the reasons I really wanted to be involved in Armoury).
18:41:43 <alagalah> Does anyone have any thoughts on this ?
18:42:20 <adetalhouet> I really agree that Armoury could be the projects hosting all the images for SFC
18:42:38 <adetalhouet> I also agree that Armoury is at its early beginning and needs serious implication to get things done
18:42:42 <alagalah> adetalhouet, Ok, hence I asked about INSTANCES :) ...
18:42:49 <alagalah> adetalhouet, all goodness
18:43:16 <mmarsale> alagalah: I would really like to see the interactions between armoury and SFC ... as you imagine them, because I dont know much about SFC
18:43:29 <adetalhouet> At first I thought we didn't want any instance in Armoury, but all discussion drives Armoury there - and in a way this make sense
18:43:35 <alagalah> adetalhouet, So at a high level, would someone request a chain, SFC say it doesn't have an SF to fulfil it, tell Tacker, Tacker asks Armoury what image info it needs, Tacker spins up a VM, then tells SFC that there is an instance of SF foo available at x,y ???
18:45:28 <alagalah> So in that case its Tacker -> SFC (give me a chain) ... SFC->Tacker (I can't right now, I don't have an instance of SF-foo). Tacker->Armoury (what info do I need to make an SF-foo?) Armoury->Tacker (here is the image URI, VM needs CPU RAM to make an SF Foo) Tacker->Tacker (spin up SF Foo).... Tacker->SFC (I have created an instance of SF-foo) etc
18:45:34 <adetalhouet> alagalah: so if I understand your above interaction, Armoury should be able to parse SFC yang to retrieve configuration for both NF and driver?
18:45:52 <anipbu> In general, would armoury be the project hosting the catalog and images for other projects, including SFC and any other projects?
18:46:47 <alagalah> anipbu, I think it comes down to the workflow
18:46:51 <adetalhouet> anipbu: I think this is what we are discussing right now
18:47:00 <alagalah> anipbu, Who is responsible for being the single source of truth of state...
18:47:49 <anipbu> Would armoury act as a middle man between Tacker and SFC, or would SFC talk directly to Tacker to request spinning up resources?
18:47:50 <alagalah> anipbu, I don't think having Armoury know create instances of Abstract VNF types is in quesion, and in that regard, SFC could query Armoury to say "I can make chains out of these things" ....
18:48:03 <alagalah> anipbu, And there in lies the question my friend :D
18:48:30 <alagalah> anipbu, PArt of this is going to be timing....
18:49:03 <alagalah> anipbu, adetalhouet I am going to propose  aYANG model for service-function later this week that consolidates a lot of stuff thats out there... I can add you to the gerrit if you like
18:49:28 <alagalah> anipbu, adetalhouet It will be purely a YANG model for community comment (ie it won't build) ...
18:49:47 <adetalhouet> alagalah: ok sure I would love to see that
18:51:04 <adetalhouet> alagalah: you're mentioning Tacker, so we need to implement the driver
18:51:28 <adetalhouet> so that brings me to the release plan
18:51:36 <anipbu> besides tacker, any other drivers intended?
18:51:38 <adetalhouet> #topic Release plan for M3
18:51:48 <adetalhouet> anipbu: yes many other drivers
18:51:53 <adetalhouet> must be implemented
18:52:01 <adetalhouet> but we need to start somewhere
18:52:14 <anipbu> will there be an abstraction that generalizes the drivers?
18:52:18 <adetalhouet> and from what I understand here is that we could have a good useless with SFC
18:52:49 <adetalhouet> anipbu: I think they should be one - we haven't thought a lot around this question so far
18:53:07 <anipbu> okay
18:54:20 <adetalhouet> so for the release plan
18:54:32 <anipbu> #link https://wiki.opendaylight.org/view/Armoury/Beryllium_Release_Plan <-armoury release plan
18:54:36 <adetalhouet> #info 1. i think that could be great to first define a global use case - as per as mmarsale started
18:55:05 <alagalah> adetalhouet, Agreed
18:55:11 <adetalhouet> anipbu: yes so far there is not much yet, this will be done by Wednesday
18:55:27 <adetalhouet> #undo
18:55:27 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x18d7050>
18:55:37 <adetalhouet> #info 1. Define a global use case - as per as mmarsale started
18:55:53 <alagalah> IF its helpful, I can ping Tim Rozet from RHAT,... he is doing a lot with Tacker
18:56:10 <adetalhouet> #info 2. Create the APIs for the workload manager, the NF catalog and the Driver inventory
18:56:46 <adetalhouet> I think on this second point we already have some APIs for the workload manager and the NF catalog
18:57:12 <adetalhouet> alagalah: sure that would be nice - I don't know Tacker well
18:57:41 <alagalah> adetalhouet, I don't either as much as I should
18:57:41 <adetalhouet> #info 3. Define an abstraction layer for the driver
18:57:56 <adetalhouet> as anipbu mentioned
18:58:08 <anipbu> fyi, the API don't have to freeze until M4, but for the release plan, we need to only list the set of externally consumable apis.
18:58:12 <adetalhouet> #info 4. Complete one use case with SFC
18:58:59 <adetalhouet> anipbu: ok, thanks for letting me know.
18:59:13 <adetalhouet> I'm mostly talking about achievement here, rather than API freeze :)
18:59:27 <anipbu> okay
18:59:50 <adetalhouet> Is there anything we could add for the release plan?
19:00:32 <adetalhouet> or any comment to say regarding those 4 points?
19:01:37 <anipbu> So are these (items 1-4) the deliverables for beryllium?
19:01:58 <adetalhouet> Yes
19:02:04 <adetalhouet> Well this is what I'm proposing
19:02:14 <anipbu> And do we have a target for when the deliverables should be completed (say, by m5).
19:02:47 <adetalhouet> I have to do that - as of now we don't have any target
19:03:08 <adetalhouet> But as you mentioned, API freeze is M4 so by M4 we need all the APIs to be well defined
19:03:25 <adetalhouet> And I think this is achievable
19:03:35 <anipbu> okay
19:03:58 <adetalhouet> For the other deliverables, I would like to know from the others what are they thought also
19:04:05 <adetalhouet> Will bring this to the ML
19:04:25 <adetalhouet> Does anyone want to add something?
19:04:47 <adetalhouet> We're on top of the hours and I got to run in another meeting
19:05:09 <adetalhouet> #action present the deliverables to the ML
19:05:24 <adetalhouet> Ok so thanks guys
19:05:29 <anipbu> thanks!
19:05:34 <adetalhouet> #topic cookies
19:05:39 <adetalhouet> #endmeeting