15:00:03 <frankbrockners> #startmeeting OPNFV BGS weekly team meeting
15:00:03 <collabot> Meeting started Mon Jul 13 15:00:03 2015 UTC.  The chair is frankbrockners. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:03 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:03 <collabot> The meeting name has been set to 'opnfv_bgs_weekly_team_meeting'
15:00:13 <frankbrockners> #topic rollcall
15:00:20 <frankbrockners> #info Frank Brockners
15:01:03 * frankbrockners is interested to see who isn't enjoying vacation...
15:01:09 <RandyLevensalor> #info Randy Levensalor
15:01:13 <fdegir> #info Fatih Degirmenci
15:01:36 <pbandzi> #info Peter Bandzi
15:02:35 <frankbrockners> Let's slowly get started - eventually others will join in.
15:02:45 <frankbrockners> #topic agenda bashing
15:03:56 <frankbrockners> #info Proposed agenda topics: (1) Arno SR1 focused work: status (2) LF lab reconfig (to allow for sequential deployment with different deployment tools
15:04:02 <frankbrockners> anything else to discuss?
15:04:03 <narindergupta> #info Narinder Gupta
15:04:28 <fdegir> frankbrockners: about genesis and standalone installer projects
15:04:46 <fdegir> I think we need to think about how to do the maintenance once the installers go into their own repos
15:04:55 <fdegir> fuel and apex for example
15:06:00 <frankbrockners> #info (3) discuss transition of installers in Arno to their own installer projects (Fuel, Foreman) to Fuel and Apex
15:06:22 <frankbrockners> thanks fdegir - good addition
15:06:40 <frankbrockners> let's see how much we can get done - seems that we're still missing quite a few folks
15:06:54 <frankbrockners> #topic Arno SR1 focused work: status
15:08:01 <frankbrockners> #info several minor fixes have been made to installers (e.g. flexibilitze IP address allocation) to meet specific deployment needs
15:08:34 <frankbrockners> #info successful demo of Fuel with plugins/adapters (to be used to integrate ODL properly in SR1)
15:09:03 <frankbrockners> anything else folks are aware of so far? From what I see we're on track towards SR1 in September
15:09:28 <frankbrockners> ah - I should info Fuel status
15:10:08 <frankbrockners> #info Fuel is a dedicated project now: https://wiki.opnfv.org/project_proposals/fuel_opnfv
15:10:38 <fdegir> #info There have been some improvements in fuel deployment mechanism for SR1
15:10:55 <frankbrockners> #info Apex (Foreman plus futures) is up for review by TSC tomorrow: https://wiki.opnfv.org/project_proposals/apex_opnfv
15:11:36 <trozet> #info Tim Rozet
15:11:37 <frankbrockners> anything else
15:11:46 <frankbrockners> hey trozet
15:11:48 <trozet> hi
15:11:59 <fdegir> hi trozet
15:12:13 <amaged_> hi
15:12:14 <frankbrockners> any updates on Foreman deployments worth mentioning here (as progress towards SR1)?
15:12:39 <trozet> #info there was a patch merged that greatly improves virtual deployments (will be part of SR1)
15:13:09 <trozet> #info we have a bunch of other JIRA tickets opened for improvements to SR1 which I am working on
15:13:22 <trozet> #info next patch to gerrit will migrate everything to genesis repo
15:13:46 <trozet> #info will also add a Jenkins verify job for virtual deployment on commits
15:13:54 * fdegir will have questions to trozet once we reach to the topic genesis vs fuel/apex
15:14:24 <trozet> #info an RDO manager demo was done last week in the octopus meeting (the new installer for R2).  It showed triple O functionality with Kilo and ODL Lithium working
15:15:27 <trozet> #info also Bryan Sullivan has put together a FAQ page for the opnfv-users, I need to update it with some Q/A but its a good start towards helping users and should be included in SR1
15:15:45 <fdegir> trozet: can you pound the link please?
15:15:48 <frankbrockners> trozet - would you mind to #link?
15:15:53 <trozet> yeah one sec
15:17:05 <trozet> #link https://wiki.opnfv.org/releases/arno/faq
15:17:15 <frankbrockners> thanks trozet
15:17:23 <trozet> I have a lot of Q/A I can add there
15:17:29 <frankbrockners> anything else on status?
15:17:51 <trozet> thats it from me
15:17:56 <frankbrockners> let's switch to the LF lab auto-reconfig discussion
15:18:09 <frankbrockners> #topic LF lab reconfig (to allow for sequential deployment with different deployment tools
15:18:29 <MR_Sandvine> #info Manuel Rebellon
15:18:57 <frankbrockners> #info TSC decided to switch the LF infra back to the original plan: Only a single POD will be used for deploy&test.
15:19:16 <frankbrockners> #info This means that deployment tools need to run sequentially
15:19:19 <fdegir> #info MOM to TSC meeting where this has been decided
15:19:21 <fdegir> #link http://meetbot.opnfv.org/meetings/opnfv-meeting/2015/opnfv-meeting.2015-06-30-13.59.html
15:19:41 <frankbrockners> thanks fdegir for the link
15:20:23 * fdegir has a question or two regarding the sequential deployment
15:20:26 <frankbrockners> question (pbandzi might know the best): Do we know what needs to be re-configured (if any) between runs on the LF infra?
15:20:36 <trozet> does this mean we need to get both installers running on the same pod?
15:20:49 <frankbrockners> trozet: yes - but sequentially
15:20:49 <fdegir> yes trozet
15:20:54 <fdegir> more than 2 in fact
15:21:00 <fdegir> more installers are coming
15:21:07 <frankbrockners> there will likely be at least 5
15:21:20 <trozet> i see.  What about another pod (single server) for virtual deployments?
15:21:25 <frankbrockners> the good thing with the current LF lab: HW can be reconfigured
15:21:32 <trozet> those are much faster and can be used for gerrit jenkins verify
15:21:41 <pbandzi> #info current pod setup: 1pod for fuel, 2 pod for foreman -> both uses different vlan settings
15:22:25 <pbandzi> #info what needs to be rconfigured depends on which project will use it and what are requirements of that project
15:22:41 <pbandzi> #info but vlna reconfiguration on POD is quite simple
15:22:51 <fdegir> I suppose installers need to adjust their configuration for target POD
15:22:57 <fdegir> so they can all be deployed there
15:23:11 <fdegir> but I'm no network person so this might be tricky
15:23:13 <frankbrockners> #info given the difference in vlan settings etc. there's a need for hardware reconfig between installer runs. those could be done via a script (UCS-manager comes with an API)
15:23:33 <trozet> when we say VLAN settings, do we mean tagged ports vs untagged?
15:23:54 <pbandzi> trozet yes
15:24:00 <frankbrockners> trozet: yes - along with the appropriate settings in the fabroc
15:24:06 <frankbrockners> s/fabroc/fabric
15:24:25 <trozet> so Fuel requires tagged, correct?
15:24:29 <trozet> foreman is untagged
15:24:37 <trozet> what about other installers?
15:24:52 <frankbrockners> for others we don't know yet
15:25:22 <fdegir> who has competence to script hardware reconfiguration?
15:25:24 <fdegir> pbandzi?
15:25:27 <frankbrockners> IMHO we could do the following: (1) document what the setup needs to look like (we have this for Fuel and Foreman) (2) create associated config scripts
15:25:42 <frankbrockners> (1) should be the task of any installer
15:26:06 <pbandzi> yes i can make thouse reconf scripts
15:26:19 <frankbrockners> great pbandzi - many thanks
15:26:24 <frankbrockners> let's info this
15:26:55 <frankbrockners> #info Installers need to document their network config needs (we have this for Fuel and Foreman - for Arno)
15:27:24 <frankbrockners> #info pbandzi will help installer teams with developing a script which creates the needed network config
15:27:40 <fdegir> trozet: a question regarding foreman vs apex: is their networking configuration same?
15:27:47 <frankbrockners> #info longer term Genesis goal would be to reduce deltas between network configs
15:28:10 <trozet> fdegir: I think RDO manager can work with tagged or untagged, but untagged keeps things simple so plan to go that route
15:28:32 <fdegir> ok, thx
15:28:34 <trozet> so what about my question of virtual pods? only require one server
15:28:41 <frankbrockners> the fewer "reconfig" scripts we need the better...
15:28:45 <trozet> we could take one unused pod and split it up into 5 or 6 virtual pods
15:28:50 <fdegir> trozet: we will have 5 nodes
15:28:56 <fdegir> + jumpstart
15:29:19 <fdegir> we perhaps need to take 2 of them for builds and leave the rest for the deploy/test or whatever
15:29:22 <fdegir> reamins to be seen
15:29:31 <RandyLevensalor> Will jumpstart be reinstalled for each sequential run?
15:29:31 <frankbrockners> we'll have 1 POD for "build and anything else"
15:29:35 <frankbrockners> so 6 servers
15:29:54 <fdegir> RandyLevensalor asks the exact question I have
15:30:14 <trozet> so if I understand..we are splitting up a POD to have 2 build servers, then the rest we can allocate, maybe 1 or 2 for virtual deployments?
15:30:22 <frankbrockners> fdegir: from the total of 6 servers - how many do you need for releng and octopus?
15:30:45 <fdegir> frankbrockners: 3 to start with
15:30:49 <fdegir> and see how much they can handle
15:30:59 <frankbrockners> so that leaves 3 for "anything else"
15:31:09 <frankbrockners> we could use 1 or 2 for virtual deployments per trozet
15:31:11 <fdegir> 3 includes build and anything else
15:31:27 <fdegir> 2 build + 1 anything else, and increase that 1 while we move on
15:31:40 <frankbrockners> sounds good
15:31:44 <frankbrockners> let's info that
15:31:56 <fdegir> so we can have 2 "free" servers for on-demand virtual deployments
15:32:04 <fdegir> outside of CI for teams
15:32:18 <frankbrockners> #info LF POD/Server usage: 1 POD (= 6 servers) for sequential deploy/test runs of different installers
15:32:21 <trozet> ok I would just like 1 virtual deployment option for CI with gerrit verify
15:32:36 <trozet> i was going to make a jjb for that soon
15:32:40 <trozet> so we can verify commits
15:32:46 <fdegir> yes
15:32:47 <frankbrockners> #info 2nd POD: 2 servers for build, 1 server for virtual deploys (this leaves 3 spare servers for now)
15:33:31 <fdegir> #info The resources will continuously be evaluated and more could be taken into CI for virtual deployments
15:33:46 <frankbrockners> #info virtual deployment would be used to run verify jobs (for gerrit)
15:34:02 <fdegir> and we can do the same for merge jobs
15:34:13 <fdegir> to make sure master branch has known quality
15:34:53 <frankbrockners> agreed
15:34:59 <fdegir> #info once verify jobs are fixed for virtual deployment, same can be done for merge jobs as well
15:35:14 <fdegir> and then we add 1 more server to CI pool for virt deploys
15:35:45 <frankbrockners> so you mean 2 for virt deploys?
15:35:49 <fdegir> yes
15:36:20 <frankbrockners> #info correction (after discussion): 2nd POD: 2 servers for build, 2 server for virtual deploys (this leaves 2 spare servers for now)
15:36:26 <fdegir> :)
15:36:49 <frankbrockners> looks like we're done with the topic.
15:37:06 <fdegir> can we go back to question raised by RandyLevensalor?
15:37:16 <fdegir> sequential deployments and jumstart
15:37:19 <frankbrockners> ready for the discussion on transition to Fuel and Apex?
15:37:28 <frankbrockners> ready for the discussion on transition to Fuel and Apex?
15:37:36 <trozet> yeah?
15:37:37 <fdegir> frankbrockners: not yet please
15:37:45 <fdegir> this jumpstart thing
15:37:53 <frankbrockners> go ahead
15:37:56 <fdegir> how we will make sure jumpstart is not messed up before the next installer kicks in?
15:38:08 <fdegir> fuel and foreman cleans up their own stuff before they start the deployment
15:38:11 * frankbrockners face a network glitch
15:38:22 <fdegir> but how we will handle this when it comes to different installers?
15:38:53 <frankbrockners> fdegir: clean-up should be a mandatory quality of an installer
15:39:03 <fdegir> yes but foreman cleans up virtualbox stuff
15:39:04 <frankbrockners> those are the things we hope to coordinate in Genesis
15:39:08 <fdegir> fuel cleans up libvirt stuff
15:39:15 <RandyLevensalor> For R2 could the installers be required to run in a VM on the jumphost?  That would allow for a fresh install and no risk of clean-up issues.
15:39:42 <fdegir> frankbrockners: agreed, definitely genesis
15:39:46 <frankbrockners> RandyLevensalor - we could try this. per my note: this is what Genesis is built for
15:40:03 <fdegir> can we info this please so we don't miss it
15:40:49 <trozet> only issue there is nested virt
15:41:22 <trozet> we may need to work through that a little bit
15:41:32 <fdegir> #info Genesis needs to make sure all participating installers have ability to clean up before they start deployments - even they start after different installer
15:41:39 <frankbrockners> #info Topics like Jumpstart host config, clean-up before/after installer runs, questions on whether an installer runs as a VM on the jumphost are questions to be decided as part of the Genesis project
15:42:19 <RandyLevensalor> Is there a separate meeting for Genesis?
15:42:26 <frankbrockners> given that we already touch on Genesis... - let's chat a bit about the transition
15:42:30 <frankbrockners> RandyLevensalor: Not yet
15:43:01 <frankbrockners> #topic discuss transition of installers in Arno to their own installer projects (Fuel, Foreman) to Fuel and Apex
15:43:21 <frankbrockners> Fuel project was approved
15:43:38 <frankbrockners> Apex (incl. Foreman and RDOMgr) is up for approval tomorrow
15:44:02 <frankbrockners> that means we can think of migrating things from genesis repo into the dedicated installer repos
15:44:25 <frankbrockners> hmm - let's even info this
15:44:35 <frankbrockners> #info Fuel project was approved by TSC last week
15:44:45 <frankbrockners> #info Apex (incl. Foreman and RDOMgr) is up for approval tomorrow
15:44:52 <frankbrockners> #info that means we can think of migrating things from genesis repo into the dedicated installer repos
15:45:45 <frankbrockners> anyone have any plans already? if does mean that things are then split across genesis (for common) and installer specific repos
15:46:05 <trozet> wont the deploy scripts and common stuff stay in BGS?
15:46:13 <trozet> or genesis i should say
15:46:27 <frankbrockners> trozet: yes common stays in genesis
15:46:37 <frankbrockners> but /foreman and /fuel would move out
15:47:24 <fdegir> trozet: ci (build/deploy) scripts are not common
15:48:01 <trozet> so we need to move those out?
15:48:15 <fdegir> I suppose
15:48:16 <fdegir> foreman dir goes to apex repo
15:48:20 <fdegir> fuel dir goes to fuel repo
15:48:31 <frankbrockners> that is my understanding as well
15:48:37 <fdegir> but
15:48:38 <trozet> for SR1?
15:48:42 <trozet> will that confuse users?
15:48:48 <fdegir> trozet: caught the question in the air
15:48:55 <fdegir> how we will do the maintenances/SR1
15:48:58 <trozet> :)
15:49:07 <frankbrockners> yup - that is the question
15:49:16 <trozet> I would suggest we leave it the way it is until SR1 is released
15:49:17 <frankbrockners> i.e. when do we do the switch-over?
15:49:21 <trozet> them migrate everything to installers
15:49:27 <trozet> for R2
15:49:40 <fdegir> or
15:49:46 <fdegir> should we do master work in isntaller repos
15:49:47 <trozet> or we can clone everything now and sync both :/
15:49:54 <fdegir> and stable/arno work in genesis repo
15:50:08 <fdegir> could be a bit more work for installer teams
15:50:15 <fdegir> but simpler for the rest
15:50:52 <frankbrockners> my preference would be to do the switch over at the earliest opportunity
15:51:22 <frankbrockners> so keep genesis/BGS until SR1 and then close BGS and migrate everything
15:51:30 <frankbrockners> otherwise we just extend the pain
15:51:35 <fdegir> and do nothing for arno after SR1
15:51:38 <fdegir> let it die?
15:51:42 <frankbrockners> yes
15:51:49 <trozet> I'm thinking for Apex (since we are introducing a new installer), easiest would be to continue work in Genesis for SR1, while working on Apex repo for R2, then merge SR1 into Apex when SR1 is released
15:51:55 <frankbrockners> not die - "put on maintenance"
15:52:04 <fdegir> frankbrockners: ok
15:52:29 <frankbrockners> trozet: that works for me
15:53:14 <frankbrockners> from a genesis project perspective, it would be good to move the installer specific things out as quickly as possible
15:53:35 <frankbrockners> SR1 would be a good milestone for that
15:54:04 <fdegir> frankbrockners: when you say move, would it mean removing non-common stuff from genesis repo as well for master branch?
15:54:24 <frankbrockners> fdegir: yes
15:54:36 <fdegir> ok
15:55:00 <frankbrockners> does this work for everyone?
15:55:18 <frankbrockners> we can info it in for now
15:55:21 <fdegir> it works for octopus/releng
15:55:23 <fdegir> can't speak for fuel
15:57:08 <frankbrockners> #info Work for Fuel and Foreman installers will continue in Genesis repo 'till Arno SR1. R2 work for installers will already start in dedicated installer repos. Once Arno SR1 is done, non-common code from Genesis will be moved/merged into installer specific repos.
15:57:32 <trozet> that sounds good to me
15:57:38 <fdegir> +1
15:58:20 <frankbrockners> #info As a consequence: Once Arno SR1 is released, everything which "non-common" will be removed from Genesis
15:58:56 <frankbrockners> thanks guys this gives us a good working assumption for now
15:59:10 <fdegir> can we say "only master branch"
15:59:28 <frankbrockners> dare to info?
15:59:48 <fdegir> #info genesis stable/arno branch should be left unctouched (no removal)
16:00:27 <frankbrockners> ... we're at the top of the hr. Any famous last words?
16:00:51 <fdegir> nope
16:00:57 <frankbrockners> looks like we're done. Thanks guys!
16:01:00 <frankbrockners> #endmeeting