18:16:08 #startmeeting Armoury weekly 18:16:08 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:16:08 The meeting name has been set to 'armoury_weekly' 18:16:23 #topic Roll Call 18:16:34 Please, #info in 18:16:41 #info mmarsale 18:18:09 alagalah: anipbu: edwarnicke: grmontpetit: subh: Are you joining the meeting? 18:18:19 #info grmontpetit 18:18:20 adetalhouet, I'm here 18:18:23 #info alagalah 18:18:32 #info anipbu 18:18:34 * alagalah is on another meeting though, couldn't avoid it 18:18:59 alagalah: ok sure, thanks for being here anyway 18:19:51 giving the others one more minute to pound in the meeting 18:20:04 I'd like to see that sequence diagram 18:20:21 ok so let's go over the Agenda 18:20:25 #topic Agenda bashing 18:20:35 #info Action Items from last meeting 18:20:49 #info mmarsale did start the diagram sequence 18:21:00 #link https://git.opendaylight.org/gerrit/#/c/27263/ diagram sequence 18:21:26 #info there is also its associated ML 18:21:33 #link https://www.websequencediagrams.com/ 18:21:42 #chair mmarsale 18:21:42 Current chairs: adetalhouet mmarsale 18:21:51 mmarsale: thxs 18:22:09 so regarding the diagram, I think this is a good start 18:22:23 Do we have any insight? 18:22:51 I agree with your comment mmarsale 18:23:15 adetalhouet: there was a short discussion on mailing list, but didnt go far... 18:23:49 mmarsale: yes, I agree with the comments you made on the ML 18:24:09 mmarsale: but this is true, we didn't have a lot of ideas/comments 18:24:18 what will be contained in the driver registry ? 18:24:32 and what is a "driver" ? 18:24:55 well so far I don't even know if we will use a driver registery - this was a proposition 18:24:55 grmontpetit: driver - code to interact with underlying infrastrucure e.g. openstack 18:25:16 and this will be use by the workload-manager 18:25:22 so there could be Openstack, docker, etc. & 18:25:26 in order to spin up VMs/containers 18:25:27 grmontpetit: adetalhouet: if we will have more drivers, we need to register them somewhere 18:25:50 grmonteptit: and choose from them somehow when initiating an NF 18:25:54 mmarsale: I totally agree 18:25:58 mmarsale can you give a concrete example of an ODL Driver ? is the ML2 mechanism driver one of them ? 18:26:08 This is why I introduce the notion of driver register 18:26:13 register/registery 18:26:22 but I didn't have a lot of feedback on this 18:27:12 I will re-trigger the mail thread to ask for review of our proposition/design 18:27:12 the driver is used in order to use the NF in the catalog rigth ? 18:28:01 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 is it the right time to ask questions ? 18:29:02 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 grmontpetit: if its not the right time, we might sum the questions and send to mailing list afterwards 18:30:13 #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 how are drivers registered to the catalog ? 18:30:26 err: driver registry 18:30:28 grmontpetit: mmarsale: I think this is the right time to ask questions 18:30:44 who is responsible to register the drivers to the driver registry ? 18:30:56 and who knows about the drivers ? 18:31:07 grmontpetit: probably the drivers themself ... or users to write the configuration for ODL 18:31:23 in the end I think the drivers will be available under the config tree in mdse. 18:31:33 mdse/mdsal 18:31:46 and as mmarsale the user write them 18:32:22 the catalog, what type of NF will it contains ? how will it be populated ? 18:33:16 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 will we provide an abstraction layer to NF ? 18:34:13 grmontpetit: in what sense ? 18:34:13 I agree with you mmarsale, but we shouldn't store images directly 18:34:26 URL to images is a good solution 18:34:34 adetalhouet: if we have URLs, they can be external so we dont have to store them 18:34:38 adetalhouet: agree 18:34:48 adetalhouet: and we can still hold images if we want 18:35:47 #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 mmarsale: and where would we hold them? 18:36:04 Q: So is the intention to be a catalog of existing INSTANCES of VNFs ? 18:36:28 alagalah: I would keep the catalog just for NF confiurations and NFs 18:36:37 alagalah: an have another list for instances 18:36:49 alagalah: linking to the NFs in catalog 18:37:01 well the instance could be either a sub-list for the workload-manager 18:37:04 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 right, those instances could also resides in the NF catalog under a different path 18:38:02 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 alagalah: sure, we are still trying to agree on how this ties together .. so its not yet 100% decided 18:38:59 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 alagalah: I would like to see that 18:39:30 mmarsale, Agreed, just wanted to get some perspectives... I have no preconceived notions other than avoiding duplicity and ensuring cohesiveness 18:40:05 alagalah: I really agree instances could be hold in Armoury for SFC 18:40:08 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 but yes we need a well define interaction diagram 18:40:32 mmarsale, Right, and there's some serious implications to that.... 18:41:22 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 (one of the reasons I really wanted to be involved in Armoury). 18:41:43 Does anyone have any thoughts on this ? 18:42:20 I really agree that Armoury could be the projects hosting all the images for SFC 18:42:38 I also agree that Armoury is at its early beginning and needs serious implication to get things done 18:42:42 adetalhouet, Ok, hence I asked about INSTANCES :) ... 18:42:49 adetalhouet, all goodness 18:43:16 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 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 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 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 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 In general, would armoury be the project hosting the catalog and images for other projects, including SFC and any other projects? 18:46:47 anipbu, I think it comes down to the workflow 18:46:51 anipbu: I think this is what we are discussing right now 18:47:00 anipbu, Who is responsible for being the single source of truth of state... 18:47:49 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 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 anipbu, And there in lies the question my friend :D 18:48:30 anipbu, PArt of this is going to be timing.... 18:49:03 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 anipbu, adetalhouet It will be purely a YANG model for community comment (ie it won't build) ... 18:49:47 alagalah: ok sure I would love to see that 18:51:04 alagalah: you're mentioning Tacker, so we need to implement the driver 18:51:28 so that brings me to the release plan 18:51:36 besides tacker, any other drivers intended? 18:51:38 #topic Release plan for M3 18:51:48 anipbu: yes many other drivers 18:51:53 must be implemented 18:52:01 but we need to start somewhere 18:52:14 will there be an abstraction that generalizes the drivers? 18:52:18 and from what I understand here is that we could have a good useless with SFC 18:52:49 anipbu: I think they should be one - we haven't thought a lot around this question so far 18:53:07 okay 18:54:20 so for the release plan 18:54:32 #link https://wiki.opendaylight.org/view/Armoury/Beryllium_Release_Plan <-armoury release plan 18:54:36 #info 1. i think that could be great to first define a global use case - as per as mmarsale started 18:55:05 adetalhouet, Agreed 18:55:11 anipbu: yes so far there is not much yet, this will be done by Wednesday 18:55:27 #undo 18:55:27 Removing item from minutes: 18:55:37 #info 1. Define a global use case - as per as mmarsale started 18:55:53 IF its helpful, I can ping Tim Rozet from RHAT,... he is doing a lot with Tacker 18:56:10 #info 2. Create the APIs for the workload manager, the NF catalog and the Driver inventory 18:56:46 I think on this second point we already have some APIs for the workload manager and the NF catalog 18:57:12 alagalah: sure that would be nice - I don't know Tacker well 18:57:41 adetalhouet, I don't either as much as I should 18:57:41 #info 3. Define an abstraction layer for the driver 18:57:56 as anipbu mentioned 18:58:08 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 #info 4. Complete one use case with SFC 18:58:59 anipbu: ok, thanks for letting me know. 18:59:13 I'm mostly talking about achievement here, rather than API freeze :) 18:59:27 okay 18:59:50 Is there anything we could add for the release plan? 19:00:32 or any comment to say regarding those 4 points? 19:01:37 So are these (items 1-4) the deliverables for beryllium? 19:01:58 Yes 19:02:04 Well this is what I'm proposing 19:02:14 And do we have a target for when the deliverables should be completed (say, by m5). 19:02:47 I have to do that - as of now we don't have any target 19:03:08 But as you mentioned, API freeze is M4 so by M4 we need all the APIs to be well defined 19:03:25 And I think this is achievable 19:03:35 okay 19:03:58 For the other deliverables, I would like to know from the others what are they thought also 19:04:05 Will bring this to the ML 19:04:25 Does anyone want to add something? 19:04:47 We're on top of the hours and I got to run in another meeting 19:05:09 #action present the deliverables to the ML 19:05:24 Ok so thanks guys 19:05:29 thanks! 19:05:34 #topic cookies 19:05:39 #endmeeting