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