14:00:33 <uli-k> #startmeeting Octopus & Releng weekly meeting
14:00:33 <collabot> Meeting started Mon Sep 14 14:00:33 2015 UTC.  The chair is uli-k. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:33 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:33 <collabot> The meeting name has been set to 'octopus___releng_weekly_meeting'
14:00:54 <uli-k> #chair fdegir
14:00:54 <collabot> Current chairs: fdegir uli-k
14:00:55 <kaipule> #info kaipule
14:01:03 <uli-k> #topic roll-call
14:01:04 <fdegir> #info Fatih Degirmenci
14:01:33 <chigang> #info chigang
14:01:45 <May-meimei1> #info meimei
14:01:50 <trozet> #info Tim Rozet
14:02:00 <dduffey> #info David Duffey
14:02:13 <uli-k> Hi everybody!
14:02:23 <chigang> hi uli
14:02:28 <uli-k> #topic agenda bashing
14:02:43 <uli-k> as usual I was late putting it on the wiki.
14:02:52 <uli-k> but there are no surprises... :D
14:02:52 <morgan_orange> #info Morgan richomme
14:02:54 <chenshuai> #info chenshuai
14:03:13 <uli-k> Anything I should add?
14:03:59 <uli-k> OK. Then let's go. I want to give fdegir more time for releng this week :D
14:04:07 <uli-k> #topic Action Items
14:04:39 <uli-k> #info First AI uli-k trozet ChrisPriceAB: clarify the need of doing Brahmaputra release on LF Lab
14:04:54 <uli-k> I think this will be open for a few more weeks.
14:05:08 <radez> #info Dan Radez
14:05:13 <fdegir> #info If Pharos could create Lab compliance and validate lab(s) for their compliance
14:05:23 <fdegir> #info It should be possible to do B release from those labs
14:05:36 <uli-k> True
14:05:39 <fdegir> so TSC & Pharos
14:05:55 <trozet> #info I still don't think we have an answer on this yet
14:06:19 <uli-k> But we need a TSC decision whether a single lab should be used or multiples
14:06:19 <fdegir> at least we can check this with TSC in this way
14:06:51 <uli-k> #info so let's keep it open....
14:07:00 <May-meimei1> we have not take this to TSC?
14:07:10 <uli-k> #action uli-k trozet ChrisPriceAB: clarify the need of doing Brahmaputra release on LF Lab
14:07:27 <uli-k> #info next AI uli-k talk to Huawei lab guys to support Pharos
14:07:37 <bryan_att> #info Bryan Sullivan
14:07:39 <uli-k> #I did but not finished.
14:07:51 <uli-k> So another one open.
14:07:56 <uli-k> #action uli-k talk to Huawei lab guys to support Pharos
14:08:21 * fdegir suggests increasing the Huawei lab bandwidth
14:08:24 <uli-k> #info next AI uli-k to trigger other lab reps according to community lab overview wiki
14:08:28 <uli-k> :D
14:09:00 <uli-k> That one I didn't do yet, so also keep open.
14:09:05 <uli-k> #action uli-k to trigger other lab reps according to community lab overview wiki
14:09:30 <uli-k> #info next: uli-k Clean up the Octopus committer list
14:09:50 <uli-k> I have 3 committers agree to step down.
14:10:15 <uli-k> Others still no response. So for some others we will need to run to the TSC.
14:10:29 <fdegir> do we need to go through the TSC?
14:10:47 <fdegir> if they don't respond then what else to do?
14:10:56 <fdegir> is it written on some bylaws and whatnot?
14:11:08 <uli-k> Yes.
14:11:19 <uli-k> I will look it up.
14:11:34 <bryan_att> is 3 committers enough?
14:11:56 <uli-k> There are a few more inactive committers.
14:12:04 <fdegir> we have 2 active octopus committers
14:12:04 <bryan_att> those on the list at https://wiki.opnfv.org/genesis are very busy
14:12:48 <bryan_att> I suggest we see additional committers. AT&T is prepared to step up to this role, as we will be putting extra focus on this project going forward.
14:12:57 <fdegir> agree with that
14:13:13 <uli-k> Happy to have people from ATT join Octopus
14:13:28 <bryan_att> let me check with David - either he or I will propose to be added
14:13:44 <uli-k> first start contributing :D
14:13:46 <fdegir> but to me, people should first help out with stuff
14:14:16 <uli-k> agree
14:14:42 <fdegir> we will at least openings for 3 committers :D
14:14:45 <fdegir> which is a good start
14:15:08 <uli-k> We have a few people who have contributed recently and are not committers.
14:15:17 <bryan_att> sure,  reviewing patches is the start. to make sure that things can move fast though we need to ensure that we have enough committers around the table
14:16:02 <fdegir> things move relatively quick if you ask me
14:16:06 <uli-k> We have currently 11 or so committers in Octopus. So I will not promote anybody before we have cleaned up.
14:16:13 <fdegir> also people should involve in more projects not just their own
14:16:18 <fdegir> that's a criteria for me personally
14:16:34 <fdegir> if they come, fix their own stuff, and disappear
14:17:01 <fdegir> anyway, can discuss this later
14:17:21 <uli-k> Anyways. I would like to not disturb the INFO file more in this week. Ray has a difficult job anyways.
14:17:46 <uli-k> So after that election is done, I will remove 3 committers that have agreed to step down.
14:18:12 <uli-k> Then we decide what to do with the remaining silent committers.
14:18:30 <uli-k> And then we promote people who have worked in octopus for a few months.
14:18:56 <uli-k> (if the remaining committer community agrees then :D)
14:19:05 <uli-k> Next AI.....
14:19:24 <uli-k> sorry, I will keep that one living...
14:19:28 <uli-k> #action uli-k Clean up the Octopus committer list
14:19:53 <uli-k> #info Next AI chigang, chenshuai clarify kvm4nfv workflow and how to use their kernel
14:20:33 <chenshuai> yes, I confirmed that kvm4nfv is using pkg to install
14:21:24 <fdegir> they produce rpm
14:21:32 <fdegir> (or they'll produce)
14:21:50 <chenshuai> and I think they need raise a requirement to genesis first so that installers will integrate
14:22:03 <fdegir> chenshuai: right
14:22:11 <fdegir> but that's part of the story
14:22:31 <fdegir> they also need/want to have testing done by verify jobs
14:22:46 <fdegir> so they can do this even before they get installer integration done
14:22:47 <chenshuai> and genesis guys will discuss more detail for the format of pkg
14:23:32 <chigang_> yes, if they don't change kernel, installer can integrate as a normal package, but they need to upload their package into artifacts.opnfv.org
14:23:39 <chenshuai> fdegir: yes, you are right
14:23:46 <uli-k> and then how does our build job look like, so installers will deploy that kernel with the rest of OPNFV?
14:24:15 <fdegir> uli-k: as chenshuai says, that part needs to be clarified between kvm and genesis/installer projects
14:24:22 <fdegir> and then we adjust build/deploy jobs
14:24:51 <chigang_> uli-k: it is no need for installers to rebuild the kernel
14:25:11 <fdegir> chigang_: depends
14:25:24 <fdegir> if installers accept the artifacts built in advance, then what you say is valid
14:25:38 <fdegir> if installers say "we want to build it in scope of our own build" then it is something else
14:26:10 <uli-k> So installers will be responsible to create a build job over all projects?
14:26:29 <fdegir> not like that
14:26:38 <uli-k> Or releng?
14:26:47 <fdegir> kvm might have a build job that builds their stuff independently
14:26:47 <fdegir> or
14:26:59 <fdegir> installers use kvm build script to build stuff in scope of their build
14:27:26 <chigang_> uli-k: I think each project should have their build/verify job
14:27:36 <fdegir> not everyone agrees that
14:27:45 <fdegir> that's what I'm trying to say
14:27:53 <fdegir> verify is something else
14:28:18 <bryan_att> I would rather that the installers support all projects in the release scope, not the other way around
14:28:21 <fdegir> what I say is how the artifacts that are going to be included/integrated into installers might depend on what installers support
14:28:26 <uli-k> Since we cannot decide here, where will we decide such things?
14:28:41 <fdegir> I say genesis/installers and kvm/etc. sort this out
14:28:47 <fdegir> we're secondary here
14:28:57 <bryan_att> unless there is some fundamental incompatibility with a projects' scope for an installer
14:28:59 <fdegir> we align ourselves to the outcome
14:28:59 <chenshuai> fdegir: yes, agree
14:29:07 <fdegir> if that outcome is sane enough
14:29:23 <fdegir> if they come up with 5 different ways of doing stuff
14:29:29 <fdegir> then we should raise concerns
14:30:01 <uli-k> I think from Octopus that is the right way.
14:30:10 <fdegir> all these are just speculation so I say we should watch and see
14:30:18 <uli-k> Agree.
14:30:30 <uli-k> I try to summarize for the minutes
14:30:34 <fdegir> :)
14:30:58 <fdegir> it will be like kvm -> genesis -> installers -> genesis -> octopus
14:31:10 <chenshuai> fdegir: yes
14:31:11 <fdegir> in very high level
14:31:31 <uli-k> #info overall build/deploy still needs to be designed. Octopus will waitfor genesis and others to work this out and then adjust.
14:31:45 <uli-k> one more AI:
14:31:54 <fdegir> #info verify jobs can be created independently from genesis/installers
14:32:13 <uli-k> #info last remaning AI: fdegir to update Wiki for Arno SR1 release
14:32:39 <fdegir> #info Arno SR1 release will be done in same way as Arno
14:32:44 <fdegir> #link https://wiki.opnfv.org/octopus/releasepipeline#arno_sr1_release
14:32:54 <fdegir> open for comments
14:32:56 <fdegir> or updates
14:33:25 <uli-k> For Arno we had two LF PODs. How will we do SR1?
14:33:37 <fdegir> we have 1 POD, POD2
14:33:53 <fdegir> and both installers are deployed/tested on the POD
14:33:59 <fdegir> but there have been issues recently
14:34:12 <fdegir> with foreman deploy if I'm not mistaken
14:34:21 <fdegir> I suppose trozet and morgan_orange are looking into it
14:34:48 <morgan_orange> fdegir: we will re discuss it during BGS meeting
14:35:01 <fdegir> anyone wants to know more can jump to BGS meeting
14:35:04 <fdegir> thx morgan_orange
14:35:13 <uli-k> OK. So we can at least close that one....
14:35:18 <uli-k> #info closed.
14:35:44 <uli-k> next on agenda
14:35:51 <uli-k> #topic lab compliancy
14:36:41 <uli-k> We have worked with Pharos, but not finished.... (as said also in AIs)
14:36:55 <uli-k> So move on?
14:37:03 <fdegir> yes
14:37:23 <uli-k> #topic Status C-milestone for B-Release
14:38:25 <uli-k> I had a small meeting with meimei and fdegir, agreeing on the main Jira stories&epics.
14:39:20 <uli-k> I didn't have to time to go over everything once more completing descriptions and dependencies.
14:40:08 <uli-k> So please everybody have a look and comment
14:40:23 <fdegir> #info Initial Octopus R2 backlog has been created in Jira and available on below link
14:40:25 <fdegir> #link http://bit.ly/1NrG0PK
14:40:56 <fdegir> please comment directly under the jira item
14:41:07 <fdegir> so we keep the discussion there and look back what we discussed later on
14:41:43 <uli-k> Should we ask projects to come forward and create dependencies?
14:42:20 <fdegir> I think we should highlight those dependencies by linking our jira issues to theirs
14:42:26 <fdegir> if they have the jira populated
14:42:42 <fdegir> for example we have pharos dependency
14:42:46 <fdegir> and pharos backlog is there
14:42:50 <fdegir> so we can do this pharos
14:42:56 <fdegir> and so on
14:43:25 <uli-k> But that's the other direction. Most projects will ask us to setup their pipeline.
14:43:26 <fdegir> it is valid for the other projects as well
14:43:40 <uli-k> So they have dependency on us.
14:43:42 <fdegir> agree
14:43:50 <fdegir> it mostly happens on the mailing list
14:44:07 <fdegir> and we have some items in jira for the ones that raised the question
14:44:33 <uli-k> Right. Should we ask missing projects to come forward?
14:45:07 <fdegir> we can raise this during B-release meeting
14:45:18 <fdegir> tomorrow
14:45:22 <uli-k> Good Idea. Less work :D
14:45:44 <fdegir> and tbh our part with setting up basic CI is simple
14:46:04 <fdegir> as long as they come up with what they need as it happened in kvm and ovs cases
14:46:11 <uli-k> #action uli-k to raise the issue in project meeting so projects come forward with their dependency on octopus to setup their pipeline
14:46:17 <fdegir> and given that we have hw resources as well
14:46:37 <uli-k> Yes.
14:46:56 <uli-k> Let's move on.
14:47:06 <uli-k> SR1 we already covered.
14:47:21 <uli-k> #topic AoB
14:47:33 <uli-k> Anything?
14:47:41 <fdegir> I have
14:47:45 <fdegir> need to change the topic
14:47:59 <uli-k> I've chaired you
14:48:01 <fdegir> #topic (Re)Claiming servers from LF POD1
14:48:34 <fdegir> #info We got 3 VLAs as requested by pbandzi
14:48:52 <fdegir> #info So the work with reclaiming servers from POD1 and using them for CI can start
14:49:20 <fdegir> #info The plan is to have 2 ubuntu 14.04 as build servers and 4 Centos 7 as virt deploy/testing purposes
14:49:41 <fdegir> will chase pbandzi for this
14:50:07 <fdegir> #topic Test Result Reporting API
14:50:13 <uli-k> sounds good
14:50:18 <fdegir> #info morgan_orange did the demo last week
14:50:26 <fdegir> #info Work with it continues
14:50:34 <fdegir> I'm not sure if morgan_orange wants to add anything?
14:50:49 <morgan_orange> API is available
14:51:04 <morgan_orange> DB has been deployed in LF but we still use Orange VM (to change the API)
14:51:15 <morgan_orange> target is LF DB
14:51:31 <fdegir> so it is fair to say the test projects can start aligning their reporting accordingly
14:52:10 <morgan_orange> yes even if the goal is not to have the same reporting - each project is free, but we want to a c ommon base for a dashboard
14:52:22 <fdegir> #info The API is available except the move to target DB which is located in LF
14:52:42 <morgan_orange> we should start a sprint with LF web team
14:52:48 <morgan_orange> to start a proof of concept
14:52:50 <fdegir> #info the test projects are free to start aligning their reporting accordingly ti have common base for a dashboard
14:53:15 <morgan_orange> #info dashboard portal proof of concept to be initiated with LF team
14:53:40 <fdegir> thx morgan_orange
14:53:42 <fdegir> last point
14:53:49 <fdegir> #topic Automatic Doc Generation
14:54:23 <fdegir> #info With the help from aricg and r-mibu, we are switching to sphinx for doc generation for all projects
14:54:49 <fdegir> #info We will have 1 script and 1 job for all OPNFV projects to produce documentation
14:55:12 <fdegir> #info The updates have been sent to all projects for review
14:55:18 <fdegir> that's all from me
14:55:30 <uli-k> Thanks!
14:56:06 <uli-k> There are only five minutes left. Do you need more for releng?
14:56:13 <uli-k> I am sorry
14:56:24 <fdegir> trozet morgan_orange: would you like to bring anything for releng?
14:56:30 <uli-k> May be we should start with releng next time!
14:56:51 <fdegir> I think releng works without needing the meetings :)
14:56:59 <fdegir> perhaps we should kill releng meetings :D
14:57:03 <trozet> fdegir: deploy is working for stable/arno, Jose is debugging some functest stuff
14:57:03 <uli-k> Great project!
14:57:14 <trozet> fdegir: but no problems with releng infra at this time
14:57:15 <uli-k> #topic AoB
14:57:21 <fdegir> thx trozet
14:57:27 <uli-k> I will be travelling next week.
14:57:40 <uli-k> fdegir, can you run the meeting?
14:57:56 <fdegir> can do
14:58:00 <uli-k> (try to leave more time for releng >D)
14:58:04 <morgan_orange> trozet: you are sure. As far as I can see in jenkins, genesis-foreman-deploy fails
14:58:06 <uli-k> :D I mean
14:58:16 <fdegir> will do
14:58:27 <morgan_orange> they are working on the reconfig of the lab
14:58:37 <uli-k> Then thanks everybody! will close and leave the channel for BGS
14:58:41 <morgan_orange> but we will rediscuss it during the SR1 status in BGS
14:59:04 <uli-k> #endmeeting