| *** trevor_intel has joined #edge-computing-group | 02:52 | |
| *** ad_ri3n_ has joined #edge-computing-group | 06:48 | |
| *** ad_ri3n_ has quit IRC | 07:04 | |
| *** ad_ri3n_ has joined #edge-computing-group | 07:04 | |
| *** ad_ri3n_ has quit IRC | 08:16 | |
| *** ad_ri3n_ has joined #edge-computing-group | 08:59 | |
| *** ad_ri3n_ has quit IRC | 09:00 | |
| *** ad_ri3n_ has joined #edge-computing-group | 09:00 | |
| *** cdent has joined #edge-computing-group | 10:00 | |
| *** markvoelker has quit IRC | 10:30 | |
| *** markvoelker has joined #edge-computing-group | 10:30 | |
| *** trevor_intel has quit IRC | 10:33 | |
| *** markvoelker has quit IRC | 10:35 | |
| *** markvoelker has joined #edge-computing-group | 12:02 | |
| *** javier_ has joined #edge-computing-group | 12:19 | |
| *** cdent has quit IRC | 12:32 | |
| *** dpertin has joined #edge-computing-group | 12:56 | |
| *** rcherrueau has joined #edge-computing-group | 12:57 | |
| *** pcarver has joined #edge-computing-group | 12:57 | |
| csatari | #startmeeting Review of Dublin edge notes | 12:58 |
|---|---|---|
| openstack | Meeting started Fri Apr 20 12:58:54 2018 UTC and is due to finish in 60 minutes. The chair is csatari. Information about MeetBot at http://wiki.debian.org/MeetBot. | 12:58 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 12:58 |
| *** openstack changes topic to " (Meeting topic: Review of Dublin edge notes)" | 12:58 | |
| openstack | The meeting name has been set to 'review_of_dublin_edge_notes' | 12:58 |
| *** trevor_intel has joined #edge-computing-group | 12:59 | |
| csatari | #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG | 12:59 |
| ChrisPriceAB | Good afternoon csatari. | 13:00 |
| csatari | Hi | 13:00 |
| csatari | I plan to go though the Wiki page topic by topic and record the comments in actions. | 13:02 |
| ad_ri3n_ | Hi | 13:02 |
| jdandrea | Sounds good. (Will there be a roll call?) | 13:02 |
| csatari | Oh, yes :) | 13:02 |
| csatari | #topic Roll Call | 13:02 |
| *** openstack changes topic to "Roll Call (Meeting topic: Review of Dublin edge notes)" | 13:02 | |
| *** esarault has joined #edge-computing-group | 13:03 | |
| csatari | #info csatari - gergely.csatari@nokia.com | 13:03 |
| ad_ri3n_ | #info alebre - adrien.lebre@inria.fr | 13:03 |
| pcarver | #info Paul Carver | 13:03 |
| jdandrea | #info jdandrea - jdandrea@research.att.com | 13:03 |
| esarault | #info Eric Sarault - eric.sarault@kontron.com | 13:03 |
| ad_ri3n_ | #info s/alebre/ad_ri3n_ | 13:04 |
| dpertin | #info dpertin dimitri.pertin@inria.fr | 13:04 |
| ChrisPriceAB | #info Chris Price - christopher.price@est.tech | 13:04 |
| ad_ri3n_ | sorry … stupid habit | 13:04 |
| csatari | No worries :) | 13:04 |
| rcherrueau | #info rcherrueau - ronan-alexandre.cherrueau@inria.fr | 13:04 |
| csatari | Okay, let's jump into the document. | 13:05 |
| ad_ri3n_ | so the idea was to go through the Dublin PTG wikipage. | 13:05 |
| ad_ri3n_ | :D | 13:05 |
| ad_ri3n_ | #link https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG | 13:05 |
| csatari | Yes, chapter by chapter. | 13:05 |
| * jdandrea (change topic?) | 13:05 | |
| csatari | #topic Review Intro | 13:06 |
| *** openstack changes topic to "Review Intro (Meeting topic: Review of Dublin edge notes)" | 13:06 | |
| csatari | Anything to the intro part? | 13:06 |
| ad_ri3n_ | not from my side | 13:06 |
| csatari | Okay, moving forward. | 13:06 |
| csatari | #topic Definitions | 13:06 |
| *** openstack changes topic to "Definitions (Meeting topic: Review of Dublin edge notes)" | 13:06 | |
| ad_ri3n_ | Original Site : The site to where the operator is connected | 13:07 |
| ad_ri3n_ | should be probably reworded as: | 13:07 |
| ad_ri3n_ | The site where the operation is performed/executed initially | 13:07 |
| csatari | Okay for me. | 13:07 |
| ad_ri3n_ | (BTW where are we taking notes? are we using an etherpad or something else? | 13:07 |
| ad_ri3n_ | ) | 13:07 |
| csatari | #action reword "The site to where the operator is connected" to "The site where the operation is performed/executed initially" | 13:08 |
| ad_ri3n_ | :-) | 13:08 |
| ad_ri3n_ | efficient ;) | 13:08 |
| javier_ | #info jrbalderrama - javier.rojas-balderrama@inria.fr | 13:08 |
| csatari | I hope, that the meeting minutes will be enough,. | 13:08 |
| csatari | Let's see :) | 13:08 |
| ad_ri3n_ | So based on that I think we should also reword the Remote site by | 13:08 |
| csatari | Okay, any proposals? | 13:08 |
| ad_ri3n_ | Site(s) that are involved in an operation launched from the Orginal one. | 13:08 |
| ad_ri3n_ | but not sure it is clear enough | 13:09 |
| ad_ri3n_ | … | 13:09 |
| csatari | maybe affected instead of involved? | 13:09 |
| ad_ri3n_ | better yes | 13:09 |
| *** fdag has joined #edge-computing-group | 13:09 | |
| csatari | #action reword Remote Site to "Site(s) that are affected in an operation launched from the Orginal one." | 13:10 |
| ad_ri3n_ | The items Application Sustainability/Site Sustainability should be close each other | 13:10 |
| fdag | #info Francis Dagenais - francis.dagenais@kontron.com | 13:10 |
| csatari | The definitions are in alphabetical order now. | 13:11 |
| ad_ri3n_ | ok | 13:11 |
| csatari | Should I break the alphabetical order? | 13:11 |
| csatari | ok | 13:11 |
| ad_ri3n_ | don't know which one is the best one. | 13:11 |
| ad_ri3n_ | But since we do not have too many definitions, sorting by semantic is probably more relevant? | 13:11 |
| ad_ri3n_ | that's all from my side for 'Definitions' | 13:12 |
| csatari | I would prefer to keep the alphabetical order to aviod long discussions about semanthics | 13:12 |
| esarault | FOr those that's aren't well versed it might be easier to be alphabetical | 13:12 |
| ad_ri3n_ | ok | 13:12 |
| csatari | and I hope we will have more definitions. | 13:12 |
| csatari | Okay | 13:12 |
| csatari | Anyonelese on the definitions ? | 13:12 |
| csatari | #topic Review of 3 Edge use cases | 13:13 |
| *** openstack changes topic to "Review of 3 Edge use cases (Meeting topic: Review of Dublin edge notes)" | 13:13 | |
| ChrisPriceAB | hmm maybe | 13:13 |
| ChrisPriceAB | ^^ | 13:13 |
| csatari | ChrisPriceAB> to definitions? | 13:13 |
| ChrisPriceAB | Is "original site" the way we want to represent the "operative site". I assume an "original site" could be anywhere and refers to the site where an operation is being performed that may impact multiple sites. | 13:14 |
| csatari | I always wanted to try to switch back to a previous topic :) | 13:14 |
| ChrisPriceAB | lol | 13:14 |
| * ChrisPriceAB loves being fashionably late to a topic | 13:14 | |
| ChrisPriceAB | I'm just not 100% sure we are using the right term. but I lack a better idea. | 13:15 |
| *** cdent has joined #edge-computing-group | 13:15 | |
| ad_ri3n_ | In my mind original site could be anywhere | 13:15 |
| ad_ri3n_ | if you have three sites A, B, C | 13:15 |
| ChrisPriceAB | original is rather concrete for what I assume is a transactional definition. | 13:15 |
| *** parus has joined #edge-computing-group | 13:16 | |
| ad_ri3n_ | user a connects to A to launch a request (whatever the request), | 13:16 |
| csatari | Original - remote sounds better for me than Operative - Remote, but I let this be decided by native english speakers. | 13:16 |
| ad_ri3n_ | this is the original site for user a | 13:16 |
| ad_ri3n_ | user b connects to C, then C is the original site for the b request | 13:16 |
| ad_ri3n_ | then the request can be mono site or multi sites | 13:16 |
| csatari | Yes, but the definition is per operation "The site where the operation is performed/executed initially" | 13:16 |
| ChrisPriceAB | anyway, it's not urgent. The context is an operation, and the way "original" presents does not help the reader understand the meaning. | 13:16 |
| ad_ri3n_ | (in the latter case, then the request, which is multi sites, includes remote sites) | 13:17 |
| ad_ri3n_ | per operation = per API request | 13:17 |
| ad_ri3n_ | exemple: openstack server create …. | 13:17 |
| ChrisPriceAB | it will probably create a situation where the author understands, but maybe not the reader. | 13:17 |
| ad_ri3n_ | if the operation is start a VM on A with an image from B (sorry for this red thread), then the original site is A while site B is a remote one. | 13:18 |
| ad_ri3n_ | Maybe we can add a small schema to clarify that point? | 13:18 |
| * ChrisPriceAB is one of those people who doesn't read the definitions section before reading the document. :) | 13:18 | |
| csatari | For now should I add a note to the page about this dilemma? | 13:18 |
| esarault | Original makes me think of the "Primary" site, if the relation is relative to the sender's point of view, it needs ot be clarified | 13:18 |
| ad_ri3n_ | not sure it is a dilemma | 13:18 |
| ad_ri3n_ | if we draw a figure? | 13:18 |
| esarault | A diagram would resolve that uncertainty for sure | 13:19 |
| csatari | Got it. | 13:19 |
| csatari | Okay | 13:19 |
| csatari | #topic Definitions | 13:19 |
| *** openstack changes topic to "Definitions (Meeting topic: Review of Dublin edge notes)" | 13:19 | |
| ad_ri3n_ | @dpertin do we have any figure related to that point? | 13:19 |
| ad_ri3n_ | from our side? | 13:19 |
| csatari | #action Create a drawing to explain Original and Remote sites | 13:20 |
| dpertin | let me check | 13:20 |
| csatari | dpertin: if you have anything please send it to me ;) | 13:21 |
| csatari | Okay, anything else to the Definitions? | 13:21 |
| * ChrisPriceAB will try to stop making things difficult. (but may fail to do so) | 13:21 | |
| * ildikov is sneaking in and hiding in the corner at the back of the room :) | 13:21 | |
| csatari | Moving forward | 13:22 |
| csatari | #topic Review of 3 Edge use cases | 13:22 |
| *** openstack changes topic to "Review of 3 Edge use cases (Meeting topic: Review of Dublin edge notes)" | 13:22 | |
| dpertin | csatari: sure | 13:22 |
| esarault | If you need some help on "beautifying" it let me know. Could probably get someone doing something in Adobe quickly | 13:22 |
| ad_ri3n_ | :-) | 13:22 |
| ad_ri3n_ | ok nothing csatari from my side | 13:22 |
| ad_ri3n_ | the use-cases are I think correctly explained in the White Paper (at least from now ;)) | 13:22 |
| csatari | dpertin, esarault Thanks. I deffinetly need someone with beutifying capabilities ;) | 13:23 |
| ad_ri3n_ | s/from/for now | 13:23 |
| csatari | ok | 13:23 |
| csatari | #topic Review of 4 Deployment Scenarios | 13:23 |
| *** openstack changes topic to "Review of 4 Deployment Scenarios (Meeting topic: Review of Dublin edge notes)" | 13:23 | |
| csatari | Only chapte 4 for now. | 13:23 |
| csatari | (the sentrence) | 13:24 |
| ad_ri3n_ | ? | 13:24 |
| csatari | If you have comments specific to 4.1 that should go to that topic. | 13:24 |
| ad_ri3n_ | Small Edge: I 'm wondering whether we can have information related to the storage capacity? | 13:25 |
| csatari | #topic Review of 4.1 Small edge | 13:25 |
| *** openstack changes topic to "Review of 4.1 Small edge (Meeting topic: Review of Dublin edge notes)" | 13:25 | |
| ad_ri3n_ | i.e. a single hyperconverge server (i.e. ceph for instance will be also deployed to store VM/containers/baremetal images…) ? | 13:25 |
| csatari | This is all the info what I could collect from all the etherpads. | 13:25 |
| ad_ri3n_ | Maybe it can make sense to open questions? | 13:26 |
| esarault | Maybe one thing abour small edge, most SSDs are 240GB, not 225GB. | 13:26 |
| ad_ri3n_ | at least that a note on that? | 13:26 |
| esarault | And for the Maximum, if the tagret is a Xeon-D type or ARM processor, probably 16 cores could eb the max tagret | 13:26 |
| csatari | #action Change 225 GB to 24o GM | 13:26 |
| fdag | Just a quick comment about Edge use cases (section 3). I'd like to stress that while yes, high amount of data vs low latency is a challenge, predictive, guaranteed maximal response times should be there somewhere | 13:27 |
| fdag | This heavily implies RT schedulers support | 13:27 |
| csatari | @all Is it OK if I add the 16 cores to the max specs of the Small edge? | 13:27 |
| csatari | And the processor types. | 13:28 |
| csatari | #action add to the maximum hardware specs that the tagret is a Xeon-D type or ARM processor, probably 16 cores | 13:28 |
| csatari | fdag predictive, guaranteed maximal response time is a requirement, not an use case. Here we should describe why do we need predictive, guaranteed maximal response time. | 13:29 |
| csatari | I'm happy to add more use cases if you have anything in mind. | 13:30 |
| *** ChrisPriceAB has quit IRC | 13:30 | |
| *** ChrisPriceAB has joined #edge-computing-group | 13:31 | |
| csatari | Anything else to Small Edge? | 13:31 |
| esarault | I'd also liek to point out that it's unlikely people will refresh every OpenStack release their Small edge appliance. What we're seeing mostly from Tier 1/2 is them starting to be comfortable with a 2 years update cycle, opened to discuss 1 year | 13:31 |
| esarault | updating every release is aggressive and time consuming for them and they typically have the mindset of "If it ain't broken, don't touch it" | 13:32 |
| csatari | esarault even if the upgrade will be possible remotely without any affect to the running workload? | 13:32 |
| esarault | Yeah the challenge is, you bring risk into the mix, a chance to mess with your SLA | 13:33 |
| ad_ri3n_ | csatari: did you consider my remarks regarding the containers/vm/baremetals image repository (and more generally what are the requirements in terms of cloud functionality) | 13:33 |
| csatari | esarault: Understood. | 13:33 |
| fdag | Are we expecting a FW release cycle of approx. 1month? This generally means downtime which may impact your on premise equipment. | 13:33 |
| csatari | Should I change the update frequency to 1-2 years, then? | 13:34 |
| esarault | An upgrade a year is managable I think. Sounds simple if you have a box, but if you have 10 000 of them scattered across the US, updating every 6 months becomes a burden | 13:34 |
| ad_ri3n_ | ^^ maybe we have general notes? It seems such a challenge will be valid for every edge deployments? | 13:34 |
| parus | On Small Edge, the section on Remote access/connectivity reliability: It sounds like we assume allways on.... Why 100% uptime? I thought we assumed WAN link could fail often! | 13:34 |
| parus | perhaps we should have a note that small edge availability is low. | 13:34 |
| parus | Upgrades + Failures | 13:35 |
| ad_ri3n_ | parus: it depends from which side the endusers/devlops will be. | 13:35 |
| parus | ? | 13:35 |
| fdag | csatari: understood for the requirements vs use case, but I see it more as a 'needs' in that case (as with 'needs high amount of data' and 'needs low latency handling') | 13:35 |
| ad_ri3n_ | maybe the connectivity between the enduser and the small edge site can be quite stable | 13:35 |
| ad_ri3n_ | while the connectivity between the edge site and the rest of the edge infrastructure can be intermittent | 13:35 |
| ad_ri3n_ | csatari: seems there are a couple of comments/questions on that part. should we open an etherpad and copy/paste the text in order to refine it? | 13:36 |
| parus | Ok. but Failure or Management Upgrades may cause downtime without a local backup. | 13:36 |
| ad_ri3n_ | (i.e. on the depployment scenarios section). | 13:36 |
| csatari | fdag: Okay, let's open an ehterpad for the Edge Use Cases text. | 13:37 |
| *** Arkady_Kanevsky has joined #edge-computing-group | 13:37 | |
| esarault | Given the case is a small CPE box, I don't think the expectation is to maintain uptime during upgrade of software nor firmware. Target would be to minize the downtime but I don't think 100% is feasible given it's only one unit in the Min/Max specs | 13:37 |
| csatari | #topic Review of 3 Edge use cases | 13:38 |
| *** openstack changes topic to "Review of 3 Edge use cases (Meeting topic: Review of Dublin edge notes)" | 13:38 | |
| csatari | #info the text needs refinement. | 13:38 |
| esarault | It would definitely be expected in the Medium edge however | 13:38 |
| parus | Spelling: Autonomous | 13:38 |
| csatari | #link https://etherpad.openstack.org/p/Dublin-edge-notes-wiki | 13:39 |
| csatari | #action Anyone who would like to make modifications on 3 Edge use cases go to https://etherpad.openstack.org/p/Dublin-edge-notes-wiki and add your proposals | 13:40 |
| *** rohitsakala has quit IRC | 13:40 | |
| csatari | Okay, back to the reliability of Small Edge-s | 13:40 |
| ad_ri3n_ | can we do the same for the deployment scenarios section? | 13:40 |
| *** rohitsakala has joined #edge-computing-group | 13:40 | |
| ad_ri3n_ | (I copied/pasted the current text). | 13:41 |
| csatari | yes, someone already dud :) | 13:41 |
| csatari | did | 13:41 |
| csatari | #topic Review of 4 Deployment Scenarios | 13:41 |
| *** openstack changes topic to "Review of 4 Deployment Scenarios (Meeting topic: Review of Dublin edge notes)" | 13:41 | |
| esarault | First timer with EtherPad here, you propose to just update the pad with what we propose directly? No need for comments or anything else? | 13:42 |
| csatari | #action Proposals about 4 Deployment Scenarios should be added to https://etherpad.openstack.org/p/Dublin-edge-notes-wiki | 13:42 |
| esarault | Don't want to break your usual process ^^ | 13:42 |
| csatari | esarault: No, just add your text. If you would like to add a note prefix it with "Note:" and I will not copy that to the wiki. | 13:43 |
| *** msimonin has joined #edge-computing-group | 13:44 | |
| csatari | Okay, back to the reliability of the Small Edge-s | 13:44 |
| csatari | Should I add anything more or differnet, than the current text "No 100% uptime expected."? | 13:45 |
| csatari | Okay, I see a "No 100% uptime expected and variable connectivity (e.g. connected car)" in https://etherpad.openstack.org/p/Dublin-edge-notes-wiki | 13:45 |
| csatari | #topic Review of 4.2 Medium edge | 13:47 |
| *** openstack changes topic to "Review of 4.2 Medium edge (Meeting topic: Review of Dublin edge notes)" | 13:47 | |
| esarault | About the hardware specs concerning the image repo, expect the small edge, being a single unit to likely only have 1x M.2 SSD or 1.8" SSD drive | 13:47 |
| * esarault added quantity to the Etherpad | 13:47 | |
| ad_ri3n_ | csatari: I just read you comment on the pad. how do you want to process, actually I asked the question twice on the IRC, not sure you saw it (if yes sorry, I apologize but I just want to keep traces on that remark ;)) | 13:48 |
| parus | I think we should envision the compute node scenario. | 13:48 |
| ad_ri3n_ | we also discuss the two connectivy aspects. i.e. connectivity between end-users and the edge site and connectivity between the different edge sites? | 13:49 |
| esarault | Regarding Medium Edge, I think 2U should be the minimum specs. There are units out there with Xeon Scalable with 4 independant servers within 2U and also some hyperconverged appliance with up to 18 servers in a 2U unit. | 13:49 |
| ad_ri3n_ | 10 min left should we try to put all the questions we may have somewhere ? | 13:49 |
| csatari | ad_ri3n_ You mean the "i.e. a single hyperconverge server (i.e. ceph for instance will be also deployed to store VM/containers/baremetal images…) ?" issue? | 13:50 |
| ad_ri3n_ | yes | 13:50 |
| parus | ad_ri3n_: who is the end-user here? the user of the VM? or an openstack tenant | 13:50 |
| ad_ri3n_ | parus: the devops who requests the provisionning of a new VM | 13:51 |
| ad_ri3n_ | so both | 13:51 |
| csatari | ad_ri3n_ We can start recording the open issue in info statements. | 13:51 |
| csatari | s/issue/issues/ | 13:51 |
| ad_ri3n_ | can be the end-user with his/her smartphone that requires to launch a new VM in the edge site | 13:51 |
| ad_ri3n_ | or can be a VM that is already running on the edge site and that wants to scale the service by provisionnng a new VM (just basic examples that come to my mind). | 13:52 |
| csatari | esarault: I think 2U-s are too big for a small edge :) | 13:53 |
| parus | The end-user may be on his smartphone watching you-tube.... but it might be goodgle who would launch the VM on the web-site. | 13:53 |
| ad_ri3n_ | csatari: not sure I'm following you but ok, you are chairing the discussion. So I do what you propose ;) | 13:53 |
| csatari | ad_ri3n_, parus: Maybe we should add a definition for the end user | 13:53 |
| fdag | csatari: The comment from esarault applies to Medium Edge | 13:53 |
| fdag | ;) | 13:53 |
| csatari | fdag: okay. | 13:53 |
| esarault | whatever fadg said :) | 13:54 |
| esarault | *what | 13:54 |
| csatari | :) | 13:54 |
| csatari | #topic Definitions | 13:54 |
| *** openstack changes topic to "Definitions (Meeting topic: Review of Dublin edge notes)" | 13:54 | |
| parus | How much longer can you guys go on this meeting? | 13:54 |
| esarault | +30m here | 13:55 |
| fdag | +30m | 13:55 |
| csatari | #action add a defininition for the ones who are interaction with the edge cloud infrastructure and for the ones who a re using the services running on top of the edge cloud infrastructure. | 13:55 |
| parus | good with me. | 13:55 |
| csatari | +30 OK for me too. | 13:55 |
| csatari | #topic Review of 4.2 Medium edge | 13:56 |
| *** openstack changes topic to "Review of 4.2 Medium edge (Meeting topic: Review of Dublin edge notes)" | 13:56 | |
| csatari | @All can we change the mimium specs of Medium edge from 4U to 2U? | 13:56 |
| ad_ri3n_ | I will leave in 3 min | 13:57 |
| esarault | I'll say yes but then that's voting for myself :p | 13:57 |
| ad_ri3n_ | sorry I have another meeting from my side | 13:57 |
| ad_ri3n_ | what will be the difference | 13:57 |
| ad_ri3n_ | between 2U and 4U | 13:57 |
| csatari | ad_ri3n_ okay | 13:57 |
| esarault | 2U tagrets multi-node systems | 13:57 |
| esarault | also ensures you're able to fit more compute when replacing an old 6U unit that dates from the WW1 | 13:58 |
| ad_ri3n_ | csatari: would it be possible to five a follow up to this meeting (actually I have several questions regarding the different acronyms such as MVS…. discussed lated in the wiki page). | 13:58 |
| esarault | also allows to think that within "one box" they can be more than 1 server | 13:58 |
| *** dims has quit IRC | 13:58 | |
| csatari | ad_ri3n_ Yes, I plan to have more sessions until we reach the end of the doucment :) Also if you have questions or comments feel free to send them to the edge DL or to this IRC channel. | 13:59 |
| ad_ri3n_ | ok thanks for all the great work you are doing ;) | 14:00 |
| ad_ri3n_ | it is really great to see more and more people contributing to this subject | 14:00 |
| ad_ri3n_ | thanks | 14:00 |
| ad_ri3n_ | CU | 14:00 |
| ad_ri3n_ | ++ | 14:00 |
| csatari | Okay, I do not have any prefernce on this to I'm happy to change it to 2RU | 14:00 |
| csatari | ad_ri3n_: Thanks, my pleasure. | 14:00 |
| csatari | #action Change the Minimum hardware specs of Meduim Edge to 2RU. | 14:00 |
| csatari | There is a comment in the etherpad: Expected frequency of updates to hardware: 5-7 years | 14:01 |
| csatari | Anyone against this? | 14:01 |
| esarault | Yes, that's me. That's the typical lifeyccle of a server from a fianncial standpoint | 14:01 |
| esarault | amortization in done in 3-5 years, system keep running for a few years afterward and slowly gets replaced | 14:02 |
| csatari | esarault okay, thanks for the info. | 14:02 |
| esarault | also ties to Intel's warranty on embeedded processors | 14:02 |
| csatari | About this one: "Expected frequency of updates to firmware: Never unless required to fix blocker/critical bug(s)" | 14:02 |
| csatari | I think we have more and more blocker/critical bugs in firmwares. | 14:02 |
| csatari | never sounds a bit too optimistic. | 14:03 |
| esarault | The thing is it'll create downtime | 14:03 |
| csatari | Yes, that is clear. | 14:03 |
| esarault | and from what we so, customers rarely update if ever there BIOS/BMC once in production | 14:03 |
| esarault | *their | 14:03 |
| fdag | csatari : You are right, but then qualification cycles of a specific FW is so long, most providers decide to live with the quirks instead | 14:04 |
| *** dims has joined #edge-computing-group | 14:04 | |
| csatari | Okay | 14:04 |
| csatari | Anyone against this: Expected frequency of updates to control systems (e.g. OpenStack or Kubernetes controllers): 12 to 24 months | 14:04 |
| csatari | ? | 14:04 |
| fdag | Unless it's a big *cough* security flaw *cough* | 14:05 |
| esarault | and this feedback comes from seeing Tier 1 customer and major public cloud providers | 14:05 |
| esarault | Yeah, Specter let's say | 14:05 |
| csatari | can you solve Spectre with a firmware update? | 14:05 |
| esarault | @fadg by enforcing default disabling of options allowing Specter/Meltdown exploits, correct? | 14:06 |
| csatari | Isn't is a screwdriver kind of update if not solved in every software piece (however some parts of the CPU can be also updated as a software) | 14:06 |
| csatari | Okay, I will copy the text from the etherpad to the wiki based on this discussion. | 14:08 |
| csatari | Moving on . | 14:08 |
| fdag | Disabling some BIOS/ME options will 'workaround' the issue, yes | 14:08 |
| csatari | #topic Review of 5 Features and requirements | 14:08 |
| *** openstack changes topic to "Review of 5 Features and requirements (Meeting topic: Review of Dublin edge notes)" | 14:08 | |
| csatari | If nothing, then | 14:09 |
| csatari | #topic Review of 5.1 Architectural paradigms | 14:09 |
| *** openstack changes topic to "Review of 5.1 Architectural paradigms (Meeting topic: Review of Dublin edge notes)" | 14:09 | |
| dpertin | what do you mean by cloud metadata? | 14:10 |
| esarault | nothing here either I guess | 14:10 |
| csatari | #topic Review of 5.2 Features | 14:11 |
| *** openstack changes topic to "Review of 5.2 Features (Meeting topic: Review of Dublin edge notes)" | 14:11 | |
| csatari | #action There are no levels mentioned anymore. Remove it from the sentence. | 14:11 |
| csatari | #topic Review of 5.2.1 Base assumptions for the features | 14:12 |
| *** openstack changes topic to "Review of 5.2.1 Base assumptions for the features (Meeting topic: Review of Dublin edge notes)" | 14:12 | |
| csatari | #topic Review of 5.2.2.1 Elementary operations on one site | 14:13 |
| *** openstack changes topic to "Review of 5.2.2.1 Elementary operations on one site (Meeting topic: Review of Dublin edge notes)" | 14:13 | |
| fdag | Typo: Network unreability -> Network unreliability | 14:13 |
| csatari | #action Network unreability -> Network unreliability | 14:13 |
| csatari | fdag Thanks | 14:13 |
| dpertin | csatari: what do type: MVS and Non-MVS mean in the document? | 14:14 |
| csatari | dpertin: MVS is minimum viable soluiton | 14:14 |
| dpertin | ok thanks | 14:14 |
| csatari | Anything else to 5.2.2.1? | 14:15 |
| csatari | #topic Review of 5.2.2.2 Use of a remote site | 14:15 |
| *** openstack changes topic to "Review of 5.2.2.2 Use of a remote site (Meeting topic: Review of Dublin edge notes)" | 14:15 | |
| csatari | #action remove "Level 1" | 14:16 |
| csatari | #topic Review of 5.2.2.3 Network unreability | 14:16 |
| *** openstack changes topic to "Review of 5.2.2.3 Network unreability (Meeting topic: Review of Dublin edge notes)" | 14:16 | |
| esarault | This is Nono-MVS? | 14:16 |
| esarault | *Non | 14:16 |
| csatari | yes, according to my first guess. | 14:17 |
| csatari | I'm open to discussions. | 14:17 |
| csatari | Without this we can still have an edge infrastructure if we have good networks :) | 14:17 |
| esarault | What's the impact if this is not there? | 14:17 |
| esarault | True | 14:17 |
| esarault | Just curious what a connection drop of 15 seconds impact's will be | 14:18 |
| csatari | Network issues will result in failed operations and maybe inconsistent config data in the edge cloud infra. | 14:18 |
| esarault | Some the user "resends" the command | 14:18 |
| esarault | No notion of command buffering to retry x amount of time until accepted or declined? | 14:18 |
| esarault | So basically "manual automation" until implemented :p | 14:19 |
| csatari | This is what I mean on "Have a policy for operation retries" | 14:19 |
| fdag | csatari : great! | 14:20 |
| esarault | Yeah fair enough :0 | 14:20 |
| esarault | :) | 14:20 |
| csatari | In the final solution I would keep trying for ever, but with some smartness to aviod killing the network in the minue as it returned from an outage. | 14:20 |
| esarault | Yeah otherwise it might flag it as DDOS | 14:21 |
| csatari | Yes | 14:21 |
| dpertin | furthermore a site is supposed to provide L1 operations, even if it is not able to contact other sites | 14:21 |
| csatari | Yes, and we miss this form this section | 14:22 |
| csatari | #action a site is supposed to provide L1 operations, even if it is not able to contact other sites | 14:22 |
| esarault | On that point, it might be good to clearly list the levels if they are to be refered to. Otherwise we'll loose people on terminologies here | 14:22 |
| csatari | Hehe, I just wanted to ask what are the L1 operations :) | 14:23 |
| csatari | At the moment I do not have a clear list of operation in mind. | 14:23 |
| esarault | No worries, just wanted to point out some of us are closer to the hardware than the network ;) | 14:24 |
| csatari | :) | 14:24 |
| csatari | Okay | 14:24 |
| csatari | #topic Review of 5.2.2.5 Containers | 14:25 |
| *** openstack changes topic to "Review of 5.2.2.5 Containers (Meeting topic: Review of Dublin edge notes)" | 14:25 | |
| dpertin | From my viewpoint, L1 operations are the ones already provided in OpenStack | 14:26 |
| esarault | Regarding containers, are we expecting to leverage Kuryr for this? | 14:26 |
| csatari | I would limit those operations. | 14:26 |
| csatari | Eg.: I would not let to overwrite the metadata locally what is received from a "parent" edge cloud instance. | 14:27 |
| csatari | esarault It is not clear at the moment. There are several architecture options for this. | 14:28 |
| esarault | I'm sure there's folks on the Medium edge that'll expect a symbiosis with K8S | 14:28 |
| dpertin | csatari: what do you mean by metadata? images, flavors, etc? | 14:28 |
| csatari | dpertin yes, things like that. See https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Metadata_distribution | 14:28 |
| dpertin | csatari: thanks | 14:29 |
| csatari | #topic What's Next | 14:29 |
| *** openstack changes topic to "What's Next (Meeting topic: Review of Dublin edge notes)" | 14:29 | |
| csatari | #info We reached 5.2.2.5 Containers. More similar meetings to come. | 14:29 |
| fdag | @all I'll need to leave now, thank you very much for this session, great work! | 14:30 |
| csatari | #action Csatari to organize the next meeting. | 14:30 |
| parus | Thank you all | 14:30 |
| csatari | fdag: Thank you. | 14:30 |
| esarault | Thanks all, this was great. Looking forward to the next meeting! | 14:30 |
| csatari | Anything to he AoB section? | 14:30 |
| dpertin | Thanks | 14:30 |
| csatari | Okay | 14:30 |
| esarault | A0B? | 14:30 |
| csatari | Thanks all. | 14:31 |
| csatari | esarault: Any other business. | 14:31 |
| csatari | #endmeeting | 14:31 |
| *** openstack changes topic to "#edge-computing-group" | 14:31 | |
| openstack | Meeting ended Fri Apr 20 14:31:15 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:31 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-04-20-12.58.html | 14:31 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-04-20-12.58.txt | 14:31 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/review_of_dublin_edge_notes/2018/review_of_dublin_edge_notes.2018-04-20-12.58.log.html | 14:31 |
| csatari | Humm, switching back to a topic does work a bit differently than I expected ;) | 14:32 |
| *** parus has left #edge-computing-group | 14:32 | |
| csatari | Anyways, the minutes are not that bad. | 14:32 |
| esarault | Hehehe I see that | 14:32 |
| esarault | Not it's actually great | 14:32 |
| *** msimonin has left #edge-computing-group | 14:32 | |
| *** fdag has quit IRC | 14:33 | |
| *** esarault has quit IRC | 14:35 | |
| *** cdent has quit IRC | 14:52 | |
| *** rcherrueau has quit IRC | 15:04 | |
| *** dpertin has quit IRC | 15:09 | |
| *** javier_ has quit IRC | 15:21 | |
| *** ad_ri3n_ has quit IRC | 15:39 | |
| *** ad_ri3n_ has joined #edge-computing-group | 15:40 | |
| *** ad_ri3n_ has quit IRC | 15:40 | |
| *** cdent has joined #edge-computing-group | 15:41 | |
| *** dims has quit IRC | 16:06 | |
| *** dims has joined #edge-computing-group | 16:11 | |
| *** ad_ri3n_ has joined #edge-computing-group | 16:29 | |
| *** ad_ri3n_ has quit IRC | 16:34 | |
| *** cdent has quit IRC | 17:09 | |
| *** trevor_intel has quit IRC | 17:27 | |
| *** trevor_intel has joined #edge-computing-group | 17:52 | |
| *** trevor_intel has quit IRC | 22:22 | |
| *** Arkady_Kanevsky has quit IRC | 22:41 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!