14:00:02 <bh526r> #startmeeting Weekly Technical Discussion
14:00:02 <collabot`> Meeting started Thu Dec 13 14:00:02 2018 UTC.  The chair is bh526r. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:02 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:02 <collabot`> The meeting name has been set to 'weekly_technical_discussion'
14:00:11 <bh526r> #topic Roll Call
14:00:18 <bh526r> #info Brandon Wick
14:00:25 <bh526r> #info Trevor Cooper
14:00:29 <bramwelt> #info Trevor Bramwell
14:00:54 <bh526r> #info Cristina Pauna
14:01:25 <dmcbride_> #endmeeting
14:01:40 <CristinaPauna> #info Cristina Pauna
14:01:50 <dmcbride_> #info David McBride
14:01:50 <bh526r> dmcbride: https://zoom.us/j/2362828999
14:02:01 <dmcbride_> thank you
14:05:18 <bh526r> #info Al Morton
14:05:42 <bh526r> #topic Infrastructure Evolution
14:06:01 <acm> #info Al Morton
14:06:01 <bh526r> #info Trevor summarized what has been discussed in email thread
14:06:32 <bh526r> #info Trevor reviewed the background of looking into packet.net
14:07:42 <bh526r> #info David further added that the reason of adding packet.net was because the Cisco server was not supported in LF lab in Portland
14:08:23 <bh526r> #info Comments from email indicated that current Pharos lab (community lab) was under-utilized
14:09:21 <mj_rex> #info Rex Lee
14:09:35 <bh526r> #info If we roll Intel lab into LaaS, we will get all benefits to Intel lab and community
14:10:10 <bh526r> #info Suggestion is to add Pharos lab in LaaS
14:11:13 <bh526r> #info At beginning, although LaaS was not visioned to support the use case of spanning over multiple Pharos labs
14:13:00 <bh526r> #info Trevor C understands that packet.net will replace all LF-hosted services
14:13:22 <bh526r> #info Does it include all servers that Intel donated?
14:15:15 <bh526r> #info David M and Trevor B clarified that packet.net will replace those 16 (or 13) Cisco UCS servers, because no one in LF lab was trained to support those hardware. We used to have support contract, but not any more because of budget. Thus those 16 (or 13) Cisco UCS server has not support (though Frank arranged some kind of ad-hoc support as a favor from some Cisco engineer).
14:16:14 <bh526r> #info What will be remaining in LF lab?
14:16:30 <bh526r> #info Answer is Intel servers (3 or 6), used for XCI
14:19:19 <bh526r> #info Packet.net is VM based. The only option of baremetal is AWS, but it needs some kind of configuration of networking which may or may not work for OPNFV
14:20:17 <bh526r> #info Trevor B and David M further indicated that we may have a good deal with packet.net that intends to support LFN, and replacing hardware could be free of charge.
14:20:47 <bh526r> #info David M indicated that we can have a trial of packet.net for a couple of months, like test drive, for free.
14:21:54 <bh526r> #info Trevor C thinks that if those 16 Cisco UCS server was replaced, we should compare those 16 UCS server with packet.net.
14:22:38 <bh526r> #info David M indicated we had this comparison a couple of months ago
14:23:17 <bh526r> #info Trevor C indicated that we should compared the support of UCS v.s. support of packet.net
14:24:19 <bh526r> #info Current support of 6 Intel is very low. If we replace those 16 UCS server with 16 vanilla servers, the support will still be low.
14:26:52 <bh526r> #info The cost of replacing 16 server is $300k, and support of packet.net is $300k for 18 months. So the break-even point is 18 months. And the cost of $19k per server is very expensive. Usual cost of each server is about $4k-5k
14:27:16 <bh526r> #info David M clarified it is based on cost model in UNH-IOL lab
14:27:43 <bh526r> #info Trevor C mentioned that many of UNH-IOL lab hardware was donated by Intel
14:31:51 <bh526r> #info Trevor B agrees that we should have a clearer picture.
14:35:19 <bh526r> #info David M, Trevor B and Trevor C work together to find out more accurate estimate of the cost v.s. support, and the break-even point.
14:35:43 <bh526r> #info Once we have that information, it is easier to agree to a way to move forward
14:37:10 <bh526r> #info The information should also cover the information such as capacity, networking options, etc., as much as possible, for evaluation purpose.
14:39:46 <bh526r> #info David M mentioned that perhaps the best way of evaluation is to design a trial
14:51:10 <bh526r> #info Jack Morgan
14:52:21 <bh526r> #info Trevor C asked the question is if we use packet.net, is it feasible to do dynamically-allocated pods?
14:53:05 <bh526r> #info Trevor B said it actually makes it easier to do dynamic pods
15:03:59 <bh526r> #topic AOB
15:04:08 <bh526r> #info Meeting adjourned
15:04:12 <bh526r> #endmeeting