14:01:10 #startmeeting Review of Dublin edge notes II 14:01:11 Meeting started Wed Apr 25 14:01:10 2018 UTC and is due to finish in 60 minutes. The chair is csatari. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:14 The meeting name has been set to 'review_of_dublin_edge_notes_ii' 14:01:40 #topic Roll Call 14:01:52 #info Eric Sarault - eric.sarault@kontron.com 14:02:05 #info Gergely Csatari - gergely.csatari@nokia.com 14:02:08 #info Ildiko Vancsa - ildiko@openstack.org 14:02:11 #info dpertin - dimitri.pertin@inria.fr 14:02:57 #topic Previous meeting 14:03:14 #link http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-04-20-12.58.html 14:03:16 #info Periyasamy Palanisamy - periyasamy.palanisamy@ericsson.com 14:03:27 Anyone knows why I can not upload images to the FEMDC wiki? 14:04:00 #info pramchan 14:04:54 Okay, I will check it with #openstack-infra 14:04:58 Hi 14:05:25 Let's continue the review from Chapter 5.2.2.5 14:05:30 Hi trinaths 14:06:07 Hi. Can you please provide the chapter url if any 14:06:16 #topic Review of Chapter 5.2.2.5 Containers 14:06:24 #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Containers 14:06:30 trinaths: ^^^^ 14:06:41 csatari: I might be wrong but I think that last time we forgot to review 5.2.2.4 about "collaboration between edge cloud instances" 14:06:41 Thank you 14:07:08 dpertin: Can happen. Lets do that first, then. 14:07:28 #topic Review of 5.2.2.4 Collaboration between edge cloud instances 14:07:37 #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Collaboration_between_edge_cloud_instances 14:08:14 Why is this not MVS? 14:09:18 I think it is still possible to achieve "basic" edge infrastrucutre wihtout these features. 14:09:37 Like start applicaitons in a remote site or on several sites. 14:09:43 From my viewpoint collaboration is critical in edge infrastructure, but I might miss use cases where it is not 14:09:45 But I can be convinced. 14:10:26 I tried to put a pressure on *minimal* in MVS when I added the types. 14:11:26 Makes sense because then your small edge instance still needs to live on its own, expecting multiple small unit to interaction together might not be MVS to start with. Could be nice down the road but maybe not for the first release 14:11:55 Asper the topic, is that edge instance based applications management is also considered? 14:12:32 Yes, and mesh appliction and live migration are difficult things :) 14:12:54 ok then, thanks 14:13:05 trinaths: Can you clarify? 14:13:28 dpertin: Okay. hopefully once we will get to the non-MVS features also :) 14:13:43 another question, are those features sorted by complexity? 14:14:11 At edge there can be many vm/cn applications evolve as per the need. Any thoughts on how such app management is taken care 14:14:42 dpertin: Ordered around feature richness what also implies somehow complexity. 14:15:58 trinaths: At the moment the wiki does not talk about applicaiotns, but we cn put this question to the open questions list. 14:16:15 One way is to implement a MEC framework. 14:17:12 #action csatari Add to the open questions list "At edge there can be many vm/cn applications evolve as per the need. Any thoughts on how such app management is taken care". 14:17:23 Ok. Since this kind of app management is required when nfv is extended to edge for auto usecases 14:17:31 csatari: ok, just to highlight that network unreliability (5.2.2.3) should not only be handled for "basic operations" (which refers to 5.2.2.1 and 5.2.2.2 I guess) but also for collaborative operations - thus I propose to set "Network unreliability" after "Collaboration" 14:17:37 Vm - virtual Machine 14:17:45 Cn - container 14:17:54 trinaths: I totally agree, but this discussion is more about the edge cloud infrastructure. 14:18:02 +1 14:18:49 https://usercontent.irccloud-cdn.com/file/YSgWGSJV/image.png 14:19:00 Virtualisation Infrastructure and VIM on this picture. 14:19:11 All other boxes are to manage the applications :) 14:20:28 Ok thank you 14:20:28 dpertin: Okay, lets discuss this. I open a topic for this. 14:20:51 #topic Review of 5.2.2.3 Network unreliability 14:21:34 dpertin: The order of the chapters doe not mean any dependency. 14:22:47 On "Basic operations" I meant all operations which are valid in a case when there is no connectivity. I just could not figure out what are these. 14:23:00 But these are operations of th eedge cloud instance. 14:23:10 Ok, but I think network unreliability should mention mono-site operations and cross-site operations (collaboration) - thus it's better to define collaboration before 14:23:35 got it. 14:23:40 Would've be bad to be clear about the expected outcome of mono versus cross site, agreed 14:23:54 *wouldn't.... 14:24:20 #action csatari Move "Network unreliability" after "Collaboration between edge cloud instances" 14:25:03 esarault: I could not really get this comment. 14:25:29 csatari: no worries 14:25:35 For instance users connected to a site isolated by a split brain should be able to do basic operations regarding this site, while admins/users from the other partition of the network should be able to execute basic operations on any single site of this parition + any collaborative operation across those sites 14:26:24 (hope it's clear) 14:26:58 #action csatari to clarify that "users connected to a site isolated by a split brain should be able to do basic operations regarding this site, while admins/users from the other partition of the network should be able to execute basic operations on any single site of this parition + any collaborative operation across those sites" 14:27:02 dpertin: Yes. 14:27:04 Thanks 14:27:30 I think that all from my side on this point 14:27:37 Anything else for 5.2.2.3 Network unreliability ? 14:27:42 Moving forward. 14:28:15 #topic Review of Chapter 5.2.2.6 Automatic scheduling between edge cloud instances 14:28:30 #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Automatic_scheduling_between_edge_cloud_instances 14:29:08 Do we need location awareness in here? 14:29:47 I think yes 14:30:12 #action csatari to add location awareness 14:30:40 Anything else to 5.2.2.6? 14:30:48 Do you think 14:31:03 Edge host scaling is possible?? 14:31:39 You mean turning off not needed edge hosts and turning them back on based on load? 14:31:47 I think it is possible. 14:32:20 Will this turn on and off 14:32:48 Hit the appliance health.. or security threats 14:32:53 ?? 14:33:27 I feel edge appliances are not so good guys.. 14:33:27 Well it should not :) 14:33:41 Usually for such autonomous management follows some policies (e.g. performance, energy) and constraints (e.g. hardware requirements) - I don't know if it is relevant to determine specific policies of edge infrastructure 14:33:53 s/for// 14:34:22 like locality, but maybe there are others 14:34:53 trinaths: The infra should migrate the workload out from the hosts before it turns them off. 14:35:03 Since an edge device be at gateway or at user end. 14:35:35 and I can not get the security threat. Do you think about a hacked host what joins to the cluster and steals all the data? 14:35:40 They thin appliances with minimal support 14:36:14 @csatari yes 14:37:33 I can add a requirement, that authorisation of hosts is needed before they join ot the cluster, but this is a generic problem. 14:37:46 Not related only to the scaling of hosts. 14:38:12 But when moved to a cluster this may create an issue 14:38:20 Yeah, there needs to be some sort of gating to join a cluster otherwise you'll end up with hundreds if not thounsands of small CPE boxes/appliances joining a cluster that are at customer prem without knowing if they are compromised or not 14:38:54 esarault +1 14:38:57 And physicall access/security what estbalished at poor if not existent 14:39:05 *what=was 14:39:09 True 14:39:12 **at=as 14:39:14 #action csatari Add a requirement for arhorisation to join to the cluster of one edge cloud instance. 14:39:41 #info pramchan 14:39:41 We need this on both edge cloud instance host and edge cloud instance level. 14:39:56 The edge device need to prove its authenticity while joining the cluster 14:39:59 Basically a two-factor auth model 14:40:35 #action csatari Add a requirement for authorisation fo join to the edge cloud infrastructure 14:41:05 I will draft the requirements and send them for you to review. 14:41:28 Also, nfvi authenticity must be taken along with capabilities 14:41:42 #info authentication for Mobile device to connect to appalication occurs before as part of Provisioning and usage of APN by device 14:41:44 trinaths: I still do not get why the apps are interesting from this perspective. 14:42:22 No apps problem is different 14:42:26 This is different 14:42:39 Okay 14:42:51 #I missed earlier part due to another call but will like to understand this 14:42:52 Please don't mix them 14:43:04 Hi pramchan 14:43:17 I try not to :) 14:43:52 #action csatari to add a requirement "nfvi authenticity must be taken along with capabilities" 14:44:26 #link https://www.google.co.in/url?sa=t&source=web&rct=j&url=http://cache.freescale.com/files/32bit/doc/white_paper/QORIQSECBOOTWP.pdf&ved=2ahUKEwj_pdjX1NXaAhWGN48KHbvbBeAQFjANegQIBhAB&usg=AOvVaw3FwIOK1oraeB0H6WwUzoRQ 14:44:30 #sounds correct, sure we do that 14:44:38 Ok 14:45:21 #are we talking here of secure boot as well? 14:45:27 Okay, anything else for 5.2.2.6? 14:46:10 pramchan no - but regarding parameters for nfvi authenticity 14:46:15 pramchan: the docs trinaths shared yes. 14:46:19 https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG 14:46:37 Secure boot is touchy. I still have nightmares from all the false positives from Intel TXT 14:47:09 This would be optinal, right? 14:47:12 OK we only use parameters from the link trinath provided , I guess 14:47:14 Agree. But this will improve. 14:47:20 Yes optional 14:47:42 Ok lets move on 14:47:44 Should I mention this somewhere in the wiki? 14:47:50 Thing is of all CPE boxes and appliance I saw in the market, they are pretty much Intel based, not FreeScale 14:48:16 or ARM given their VNF is converted to ARM 14:48:43 There are ARM boxes too competing today.. 14:48:51 @csatari, the fact we talka bout it needs a note somewhere I believe 14:48:58 +1 14:49:00 True, espacially at the small edge 14:49:05 +1 14:49:29 Edge big or small needs Mano and Vim 14:49:41 #action csatari Add secure booting as an optional requirement for the small edges. 14:49:56 Ok 14:50:24 #topic Review of Chapter 5.2.2.7 Administration features 14:50:38 #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Administration_features 14:51:20 Zero touch provisioning should be in MVS i think 14:51:34 Otherwise it'll be very hard to get people to buy the edge story 14:51:37 what is full form of MVS? 14:51:38 heh, "Join the swarm" is the authentication of the edge cloud site 14:52:16 ZTP is one critical part 14:52:24 Basically everything in this section allows remote admins to properly manage their edge cloud 14:52:31 Minimum Viable Solution 14:52:41 I don't see how we can live without 3/4 of the stuff int his section 14:52:54 For it to be deemed a "production-grade" solution 14:52:55 ZTP i have some thoughts to share 14:53:03 thanks 14:53:29 Should we move this sevtion to MVS, then? 14:53:39 s/sevtion/section/ 14:53:47 Note ETSI has a new group call ZSM which is focussed on similar aspects 14:54:01 ZTP from Openstack perspective - can be installation of cloud components. 14:54:31 #link http://www.etsi.org/news-events/news/1245-2017-12-news-etsi-launches-zero-touch-network-and-service-management-group 14:54:35 pramchan: Thanks, I've heard about it: ) 14:55:11 trinaths: From the whole infra perspective it is also the host OS install. 14:55:22 ZTP from vendor - installation of business apps, environment, security updates and leaning apps as the requirements demand. 14:55:25 As part of edge cloud here should we then include a new use case for network slicing? 14:55:52 pramchan: Use case, feature or requirement? :) 14:55:59 may be a distarction but note thta for later use 14:56:10 csatari - only os?? How about requirements for inbox cloud controllers?? 14:56:23 eg the host OS. 14:56:29 Not only cloud components. 14:56:55 I would say say use of network slicing for specific application characterstics required like AR/VR needs one slicing 14:57:18 Network slicing is relevant to operators so it's not bad a idea to at least keep a note if it and think of how it could work, maybe not MVS though? 14:57:24 Yes. Any thing. ZTP must give a generic console to provision and manage the appliance 14:57:40 #action csatari to add a requirement for provisioning the things under the cloud components 14:57:49 Sorry, I have to switch in a few minutes to the femdc irc meeting - thanks everyone 14:57:57 And 14:58:01 thanks dpertin 14:58:06 * esarault need to move to another meeting as well 14:58:16 #topic Finishing up 14:58:30 This provisioning also depends on capabilities of the appliances 14:58:35 Ok 14:58:45 #info We will continue from 5.2.2.7 Administration features 14:58:55 #action csatari to organize th enext meeting. 14:59:14 Sorry guys, but I also neded to run 14:59:25 Thanks csatari 14:59:26 Thanks for the discusison. I will organize the next session. 14:59:31 #endmeeting