====== BGS Meeting June 22, 2015 - Minutes ====== 5:00 PM #startmeeting BGS weekly team meeting 5:00 PM i think meetbot isnt working frankbrockners 5:00 PM hello, Frank 5:00 PM yes 5:00 PM yup - I saw this from Fathi's ealier meeting 5:00 PM but wanted to try again :-) 5:01 PM let's just pretend that it would work 5:01 PM we can still use #info -- makes filtering and creating notes easier... 5:01 PM #info Frank Brockners 5:01 PM #info Dan Radez 5:01 PM #info Fatih Degirmenci 5:01 PM #info Arnaud Morin 5:02 PM #info Tim Rozet 5:02 PM #info Weidong Shao 5:02 PM #info Agenda for today: https://wiki.opnfv.org/meetings/bgs#june222015 5:03 PM anything we should add to the agenda? 5:03 PM → rprakash_ joined (1806bda8@gateway/web/freenode/ip.24.6.189.168) 5:03 PM sounds like this isn't the case.... 5:03 PM → JonasB joined (~jonas.bju@sessfw99-sesbfw99-86.ericsson.net) 5:03 PM #topic Arno release recap 5:04 PM → narinder joined (~narinderg@122.162.216.85) 5:04 PM just thought that it would be a good idea to do a round-table and gather some learnings 5:04 PM i.e. what went well and what did not 5:04 PM are you on gotomeeting or have I got the wrong meeting id? 5:04 PM #info Jonas Bjurel 5:04 PM ⇐ narindergupta quit (~narinderg@182.69.186.193) Ping timeout: 246 seconds 5:04 PM Debra - we're IRC only 5:04 PM OK, challenge to show slides then 5:05 PM → RandyLevensalor joined (~randyl@c-73-181-103-172.hsd1.co.comcast.net) 5:05 PM even in irc only on #opnfv-meeting and not #opnfv-bgs 5:05 PM #info Manuel Rebellon 5:05 PM Debra - if you have slides, you could post them to the wiki or send out via email 5:05 PM #info I thought the cross project collaboration (functest, octopus) worked very well in the chaos towards release 5:06 PM trozet - much agreed. it brought all of us much closer together 5:06 PM #info As said befor alot of good collaboration and engagement. 5:06 PM #info we could have had better planning of requirements for the target system earlier in the project 5:07 PM I also think that we did well wrt/ deliver per agreed schedule (once we had a plan we pretty much followed it) 5:07 PM #info But we need to structure things differently when we get more projects, more installers, and more complicated functest 5:07 PM #info agree on the requirements, I feel like we were kinda figuring them out as we went 5:07 PM → amaged_ joined (sid87897@gateway/web/irccloud.com/x-zjjzxgceimlgeoew) 5:07 PM Agree 5:08 PM agreed radez - we pretty much learned as we were crawling forward 5:08 PM we should know better for R2 5:08 PM this is part of why we need Genesis - aka common requirements 5:08 PM I think that created frustrations... 5:09 PM on the other hand we did work together well in spite of having a moving target to hit 5:09 PM frank you missed Compass from Arno release 2 and Uli wanted me to remind you on that 5:09 PM frankbrockners: I think genesis need to be more than requirements. 5:09 PM JonasB: What else do you see needed? 5:10 PM I think genesis going forward either need to dictate how projects need to package their artifacts such that installers can consume them in a generic way, or do the packaging in Genesis 5:11 PM JonasB: this topic is release recap 5:11 PM JonasB - I like the term "requirement for packaging" a bit better than "dictate" 5:11 PM I also see genesis is the focal point for functest and CI to adress their requirements to. 5:11 PM maybe save those comments for later topic 5:11 PM frankbrockners: We can work on wording - sure 5:11 PM trozet - good point, let's table the genesis topic for a bit and return to "what went well and where do we need to do better" 5:12 PM JonasB: what do you think went well or poorly for Arno? 5:12 PM so early articulation of requirements - and common agreement of these requirements is a key one 5:12 PM what else? 5:12 PM Maintenance of Arno should be minimum and not sure as CI too discussed it and so there is some confusion on where genesis stops and ocutopus takes over 5:13 PM frankbrockners: the LF lab took a bit of debugging. Not sure how we could have made that more efficient 5:13 PM #info LF lab bring up took 4-6 weeks -- would be great to do better next time 5:13 PM maybe a description of the network topology 5:13 PM or better communication with LF admins 5:13 PM before it is all setup 5:14 PM there were layer2 collisions between pod 1 and pod 2 5:14 PM we should have informed LF lab to set them up as separate broadcast domains from the beginning 5:14 PM yes - and for the next pod (which cisco donates) we'll plan things ahead of time... 5:14 PM Should we not have more PODs allcated in LF for future work. looks like this shortage of PODs is making things harder 5:14 PM #info So went well: collaboration, engagement, commitment! 5:15 PM rprakash_ has a point -- it would have been nice if more of the field labs would have really been available to developers 5:15 PM agree to that 5:16 PM let's info that 5:16 PM due to some "development" work going on LF PODs 5:16 PM we can't run stuff properly 5:16 PM #info less well as said: Integration with LF lab, support of LF-lab, clear definition of requirements/use-cases 5:16 PM #info it would have been nice if more of the field labs would have really been available to developers - LF should be for deploy/test - less so for development 5:16 PM #info Clarification regarding the purpose of LF lab is needed 5:16 PM and we'll improve once we have another POD at the LF - as a common sandbox 5:17 PM #info Is it for development work or the CI 5:17 PM fdegir - good point - and we also re-purposed the equipment on the fly 5:17 PM We cant scale with the static config we have in LF lab, we need to have a MaaS to sort that. 5:17 PM additional topics? 5:17 PM I think we need more videos on youtube to explain what the project is, and maybe a demo. A lot of people are still finding it hard to understand what the project is about, so this could fall under documentation. 5:18 PM amaged_ agreed - this is "for next steps" (next topic on the agenda) 5:18 PM Repurposing is finr, but we should havd two more PODS i LF , one for CI and onr for Testing 5:19 PM which is also about next steps... 5:19 PM any additional topics on "retrospective" 5:20 PM Frank Uli asked me to remind you to include Compass & Arthur for JoID is installers for Rel 2 5:20 PM we have (+) collab & teaming (-) better def. of requirements (-) better doc of LF lab and definition of purpose 5:20 PM #info Another good thing is that we had many people getting their hands dirty with CI 5:20 PM so it is under collab & teaming 5:20 PM rprakash_ let's work through the agenda topic by topic 5:21 PM → anac joined (~eanapau@sessfw99-sesbfw99-90.ericsson.net) 5:21 PM one more thing to add is to patch the things that caused issues on last day 5:21 PM does anyone have feedback about Arno from outside the inner circle? 5:22 PM upstream repos and what is pulled down from where 5:22 PM fdegir - agreed 5:22 PM frankbrockners: I tried to search in blogs/tweets but i couldnt find anything more than people talking about its existence. 5:23 PM → chenshuai_ joined (dfa64473@gateway/web/freenode/ip.223.166.68.115) 5:23 PM #info better documentation and understanding of external dependencies 5:23 PM One thing I think needs to be fixed is a way to increas SNR on the mailing lists. 5:23 PM SNR? 5:23 PM signal to noise 5:23 PM ratio 5:23 PM agreed 5:24 PM very hard to follow different topics 5:24 PM for email tagged BGS that was ok 5:24 PM One could try filtering, but there is a big risk that you miss things as there are weak instructions on how to tag topics 5:24 PM but many people don't tag 5:24 PM JonasB - very much agreed - tagging does not always work (or you miss important stuff) 5:25 PM #info improve communications over email (signal to noise ratio isn't great - project tagging isn't used throughout the community) 5:25 PM I think the only safe way to do it is to create distr lists per topic/project 5:25 PM ok... given that we have a bunch of additional topics on the agenda - let's move on 5:25 PM Ok! 5:26 PM #topic next steps for BGS 5:26 PM what I had in mind here is twofold: (a) how do we define the content of a service release for Arno - what do we need to do from a BGS perspective 5:27 PM How is BGS perspective on this different from CI? 5:27 PM and (b) how do we "finish up" BGS 5:27 PM Frank, did you start the meeting, it doesnt seem so. topic doesnt work? 5:27 PM JonasB: meetbot is dead 5:27 PM Ahh 5:27 PM will filter manually later 5:27 PM so please continue #topic 5:27 PM and #info 5:28 PM #nfo service release should fix bugs without adding new releases from upstream 5:29 PM rprakash_ - good question: from my perspective BGS is "deployment" focused - CI deals more with the packaging and delivery aspect 5:29 PM #info while back we had a discussion on what service/maintenance release would mean: https://wiki.opnfv.org/get_started/release_and_maintenance 5:30 PM A question, how can we fix issues if we do not pick new minors from upstream? 5:30 PM is it still needed to have such "deployment" focused perspective? 5:30 PM JonasB: Should we fix issues from upstream? 5:30 PM frankbrockners: Can we say that BGS will never finish, because there will always be new releases of the key components ? so if things changed, they would reflect on BGS 5:30 PM we need automated ways of doing things 5:30 PM or should we rather only fix what is in our control? 5:30 PM I think we should contribute upstream 5:30 PM fix issues 5:31 PM arnaud_orange - agreed - but new upstream sources IMHO would mean a new release, instead of a service release 5:32 PM IMHO we should only fix what is in our span of control for an "Arno-SR", i.e. bugs in our scripts etc. 5:32 PM Thoughts? 5:32 PM agreed 5:33 PM frankbrockners: agreed. This way, it wouldnt be confusing to users. They know the scope of changes, making it easier to spot problems in the components. 5:33 PM trozet, radez, JonasB, fdegir - any thoughts? 5:33 PM frankbrockners: We would ultimately have as much from upstream as possible, that also goes for installers. 5:33 PM #info my undertsnading is BGS was to facilitate first release and if we want to focus on deployment we just support what CI does , but note now we are taking a stand that we deploy whatever CI produces release 1 or 2 or for different installers, is that the BGS goal then? 5:33 PM what I meant was that we should propose upstream fix as well when needed, and made it available only on next release 5:33 PM #info yes we should only be fixing bugs for Arno branch 5:33 PM #info no upgrades to kilo, etc 5:33 PM So I can see where we need to get a OS service pack in, a patch for OVS, KVM etc. 5:34 PM trozet: Agree - no majors should slip in! 5:35 PM How about minors? 5:35 PM I think it would be strange if we couldnt get security patches in, etc, etc. 5:35 PM IMHO we should stay with what we have from upstream. 5:35 PM minor, I think that should be at the discreetion of commiters 5:36 PM how do we qualify "minor" vs "major" 5:36 PM once determined that upstream can not fix it sonn or not atall, a mnor work around or fix can be done and may be released to upstrem 5:36 PM ODL Helium SR1->SR2 is a minor. Helium -> Lithium is a major 5:37 PM that works for ODL and O/S 5:37 PM how about e.g. OVS 5:37 PM if we do e.g. 2.3.0 today 5:37 PM would anything 2.3.x be ok? 5:38 PM I'm trying to borrow analogies from Kernel releases in Linux and how it relates to Applications. 5:38 PM +1 for CI and adoption on minor upstream versions. 5:38 PM one requirement to the installers is to be able to patch the system for minor(os patches, etc) and possibly upgrade for major 5:38 PM OVS is linux distros choice we can possibly take linux.x.1 linux.x.2 distros for ovs depending on distro 5:38 PM frankbrockners: I think so, almost all projects have a way to qualify what is a major and what is a minor - they just do it differently. 5:39 PM frank well said but this is where committers ave freedom to fix what minor is based on uptream 5:39 PM frankbrockners: did we ever put out a requirement for OVS version? 5:40 PM ok - is everyone ok with including "minor" upgrades from upstream in a service release - but avoid "majors" 5:40 PM cant create a post release requirement :) 5:40 PM +1 5:40 PM +1 5:40 PM → smccann joined (4281f10d@gateway/web/freenode/ip.66.129.241.13) 5:40 PM trozet: there is one on https://wiki.opnfv.org/get_started/get_started_system_state - but I'm not sure it is followed 5:40 PM Should all installers continue to track the same minor version of OVS and the upstream / common dependencies? 5:41 PM +1 5:41 PM RandyLevensalor: That was the original plan - but we have to stay practical, given that we pull from upstream release repos 5:42 PM → snackewm joined (snackewm@nat/intel/x-oywrghuxfqpvotxs) 5:42 PM #info note every installers tried but based on centos7,7.1 or ubuntu 14.04 they had different ovs and hence the statrt state listed were matcahed as far as p[ossible and changed by different installers to make things work 5:42 PM #agree SR for Arno will only include minor updates from upstream but avoid major upstreams. In addition, it'll include bug-fixes to OPNFV provided scripts etc. 5:43 PM the second topic in that realm is: When would we plan for having a SR for Arno? 5:43 PM I thought that we wait for folks to continue trying Arno 5:44 PM and once we have an understanding of the main issues (and things start to repeat themselves) we create a SR 5:44 PM so something like late Aug/Sep timeframe... 5:44 PM thoughts? 5:45 PM makes sense 5:45 PM keep it Aug 15th time 5:45 PM Will give us 8-10 weeks 5:45 PM JonasB, trozet? 5:45 PM September is when Fuel will have something for SR1 5:46 PM OK then lets look at content of SR and then decide on dates 5:46 PM ⇐ chenshuai_ quit (dfa64473@gateway/web/freenode/ip.223.166.68.115) Quit: Page closed 5:46 PM frankbrockners: we probably need at least a few weeks 5:46 PM anytime after that is fine 5:46 PM so Sept sounds viable 5:46 PM #agree high-level target for SR for Arno would be September 2015 5:47 PM ok lets tale it sept 18th the third week 5:47 PM should give enough time for everyone to chip in 5:47 PM by then we probably also have the new project structure for installer projects in place and can shut down BGS 5:47 PM with this I wanted to give the floor to Debra 5:48 PM #topic Planning and communication tools for B-River 5:48 PM Debra - you were planning to give us an overview 5:48 PM frankbrockners thanks 5:48 PM slides sent out to mail list 5:49 PM slide 2 topic: ARNO retrospective feedback- communication of scope needs improvement 5:49 PM especially visibility for new people coming on the project 5:49 PM proposed: for high level only, use project box that I will maintain for the community 5:50 PM lower level engineering requirements still documented/tracked in spreadsheets or wiki 5:50 PM as team usually does 5:50 PM ⇐ sorantis quit (~sorantis@sessfw99-sesbfw99-84.ericsson.net) Ping timeout: 276 seconds 5:50 PM Project box has 4 quadrants on 1 page 5:51 PM upper left = minimum viable- those things the project will not release without 5:52 PM bottom left = working plan- things the team is working on that could be dropped in needed or that have a mild amount of risk. Team is working as if these are in plan 5:52 PM If risks not resolved by late milestone (D) (will talk about milestones shortly) then they would be moved to ouplan 5:53 PM ⇐ ildikov quit (~ildikov@sessfw99-sesbfw99-87.ericsson.net) Ping timeout: 252 seconds 5:53 PM upper right quadrant = requirements that are at significant risk but would like to get them into the release if possible. 5:54 PM If the risks for these are not resolved by an early milestone (C) they go outplan 5:54 PM Bottom right is requirements that are outplay- the community has decided no effort will be put into these this release. 5:54 PM Debra - makes sense to me to have (a) base, (b) highly desirable, (c) stretch, (d) future.. 5:55 PM Exactly 5:55 PM also looks like the proposed SR process resembles that of other OSS projects (e.g. ODL) 5:55 PM To build and maintain this document I will need help from project leads. 5:56 PM Since I am still getting to know who does what, would help me if leads send me an email with contact info & which project they lead 5:56 PM what I would recommend doing is to have a brief overview in the TSC call - and assemble a group of folks interested in working the topic 5:56 PM Yes, we plan TSC call intro of this too 5:56 PM there might be talented folks who are not project leads - which you want in the meeting 5:56 PM sounds great 5:56 PM yes agreed 5:57 PM 2nd topic is schedule & milestones 5:57 PM Milestone A - statement of intent B-Release participation 5:58 PM Milestone B - Per project plan for the B-Release Features and dependencies identified in Jira 5:58 PM Milestone C - Sprint planning ready (critical Jira tasks written) 5:58 PM — frankbrockners thinks that we're running out of time 5:59 PM Debra - IMHO the topic would really be better covered on a live call with audio 5:59 PM Requirements projects: All upstream requirements published 5:59 PM Yes, was hoping for that. Didn't realize you had switched to irc only 5:59 PM so how about you give a short intro at the TSC - and then schedule a dedicated follow up for folks interested 5:59 PM will do 5:59 PM that way you get everyones thoughts - also ask for thoughts over email 6:00 PM thanks much 6:00 PM we knew we will need to have multiple meetings to introduce the thoughts 6:00 PM we're pretty much at the top of the hr... 6:00 PM → HKirksey joined (~Kirklet@24.130.35.74) 6:00 PM Just wanted to add that yes we should go with voice besied irc as frank pointed out and we can differe installer stuff for next week 6:00 PM unforuntately we did not get to Genesis discussions - but we can do so next week 6:01 PM ok... thanks everyone - and have a great week 6:01 PM #endmeeting 6:01 PM Thanks for giving me time. Please review slides and send questions to me 6:01 PM thanks Debra 6:01 PM Thanks Debra for giving us the highlights