15:00:31 #startmeeting OPNFV BGS/Genesis weekly synch 15:00:31 Meeting started Mon Aug 10 15:00:31 2015 UTC. The chair is frankbrockners. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:31 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:00:31 The meeting name has been set to 'opnfv_bgs_genesis_weekly_synch' 15:00:38 #topic roll call 15:00:45 #info Frank Brockners 15:00:51 #info Dan Radez 15:00:56 #info Tim Rozet 15:01:01 #info Fatih Degirmenci 15:01:13 #info Peter Bandzi 15:01:23 #info Stuart Mackie 15:01:40 #info Szilard Cserey 15:02:42 #info Narinder Gupta 15:02:52 while we're waiting for others, let's already start with agenda bashing... 15:03:03 #topic agenda bashing 15:03:11 #info draft agenda is found here: https://wiki.opnfv.org/meetings/bgs#aug102015 15:03:51 #info topics for today are (1) LF lab reconfig, (2) Arno SR1 status, (3) Get ready for Genesis creation review 15:03:57 Anything else to add? 15:04:32 Does not seem to be the case 15:04:44 let's move to the first topic 15:04:58 #topic LF lab reconfig - status and next steps 15:05:18 pbandzi, trozet, fdegir - could you give an update? 15:05:43 #info As trozet mentioned in octopus meeting: the lab reconfig works for Foreman, and there were some updates made for Fuel. Fuel still needs to finish a few changes and still test before we take down POD1 15:06:37 and szilard_ is working from fuel side now 15:06:43 yes 15:06:48 pbandzi - thanks. do we have an expectation on when things will be done? 15:07:22 szilard_ let me know if you need any help 15:07:28 I try to finish until tomorrow 15:07:55 #info plan is to do the fixes for Fuel by tomorrow (per szilard_) 15:09:18 Do we already have a plan how to re-use POD1? trozet wants one VM for nested virt deploys afaik. how about the other servers. fdegir - do you have some info? 15:09:56 frankbrockners: I think we were thinking of taking 4 of them 15:10:07 if I remember correctly 15:10:09 #info I think we should set aside at least 2 UCS blades to be single server PODs for virtual deployment 15:10:15 4 would be better :) 15:10:28 but 2 of them are for build/verify stuff :D 15:10:38 and that leaves 2 for virt deployment 15:10:55 we have 6 in total 15:11:03 #info we also need 2 servers for builds 15:11:17 #info which makes 2 build + 2 virt deployments 15:11:27 with 2 spare for now? 15:11:37 I think so 15:11:49 we can connect those 2 spare ones to jenkins as well 15:12:03 fdegir: so E/// lab is used right now for build right? 15:12:09 and they can be utilized for other needs as needed 15:12:11 so we will move build to LF? 15:12:12 you could do parallel virt deploys for the time being 15:12:13 trozet: thatäs right 15:12:41 frankbrockners: I think we need to do parallel virt deploys 15:13:01 since we might get multiple changes/patchsets for instlallers 15:13:14 and they will be verified from deployment point of view as well 15:13:33 so could we agree the following for now? POD1 will be (2x build verify) + (2x virt-deploy-1) + (2x virt-deploy-2)? 15:13:48 it sounds good 15:13:59 what does virt-deploy-1 and virt-deploy-2 mean? 15:14:25 is that Fuel vs Foreman? 15:14:27 I think 1st pool definitely dedicated for virt deploys 15:14:27 virt-deploy-x would mean 2 servers for a virt-deployment job 15:14:52 so that we could run two virt deploys in parallel 15:15:03 initially this would be fuel, foreman 15:15:10 why couldnt we just run 4 in parallel? 15:15:10 but soon there will be additional installers 15:15:19 isn't 1 server enough for 1 virt deploy? 15:15:34 yeah 15:15:38 that is what I initially thought 15:15:58 unless you want to separate jumphost and deploy host 15:16:03 so we could have 4 parallel deploys 15:16:18 jumphost can be virt as well I think 15:16:19 they are separate VMs, but they all run on the same host (at least in our case) 15:16:43 cool 15:16:50 unless I'm mistaken 15:16:53 so we could just have a pool of 4 single server PODs for virtual deployments? 15:16:53 what about the other installers? 15:17:08 that would be great 15:17:12 yes 15:17:13 but 15:17:19 szilard_: can you comment on if Fuel virtual deployments use a single host? 15:17:50 szilard_: ping 15:18:01 yes a single host is enough for virtual deployment 15:18:06 cool 15:18:10 perfect 15:18:12 now coming back to my but 15:18:23 4 servers is cool 15:18:33 but we need to support other development work as well 15:18:43 such as test frameworks 15:18:57 they need to run some verification activities for fw and test cases 15:18:58 that is a good point 15:19:01 fdegir: right 15:19:04 and they might need some resources 15:19:18 that's why first 2 servers can be dedicated to virt deploys 15:19:23 so should we use 3 servers for the virtual pods, and reserve 1 pod for other activities? 15:19:26 ok 15:19:32 second 2 servers can be shared between virt deploys and the other work 15:19:37 and evaluate while we move on 15:19:40 ok 15:20:31 so POD1 will be (2x build verify) + (2 x virt-deploy) + (2 x test / virt deploy)? 15:20:47 yes 15:21:13 we can do some tricks to maximize the utilization 15:21:20 but that's for later 15:21:34 fdegir - is there a way make the allocation of 2 x test "dynamic"? I.e. the test team could use some nob to stop virt deploys and grab the server? 15:22:13 we can assign priorities to jobs 15:22:28 so test jobs could have higher priortiy then installers on second 2 servers 15:22:40 and they could grab the resource before installers on those servers 15:23:13 #agree POD1 will be reconfigured to (2 servers for build/verify - migrate task from Ericsson lab) + (2 servers for virtual deploys - 1 server per virtual deploy) + (2 servers to test or other activities, incl. virt deploys) 15:23:21 but aborting/stopping would leave installer verifies without verified+1 so it is not advised 15:24:19 ok - sounds good - let's see how things work once we have operational experience. 15:24:39 looks like we're done with the LF-lab reconfig topic 15:24:58 #topic Arno SR 1 status 15:25:21 szilard_ could you give a brief update on where things are for Fuel? 15:25:32 we did not have a lot of news the past few weeks 15:25:49 are we still ok to target SR1 for end of September? 15:26:17 #info: I have uploaded a patch for Autodeployer that installs ODL from Fuel 15:26:24 #info I think yes 15:26:36 #undo 15:26:36 Removing item from minutes: 15:26:53 #info Fuel team is on track for Arno SR1 15:27:34 anything else worthy to report? (e.g. user experiences / issues found etc?) 15:28:02 for both installers? 15:28:13 let's finish Fuel first... 15:28:16 ok 15:28:27 szilard_: anything else to report? 15:28:35 that's all 15:28:46 thanks szilard_ 15:28:52 trozet... now :-) 15:29:03 anything on Foreman/quickstack? 15:29:12 Still good with SR1 target for Sept? 15:29:33 #info We are good for Sept. We have a several more fixes to submit, would like to have deploy verification first so holding off 15:29:53 #info We have had several users trying out the latest SR1 and it looks to be working/stable for them 15:30:14 sounds good - szilard_ promised to have things working by tomorrow - so waiting will be over soon :-) 15:30:21 #info One user indicated that when he goes into the DLUX gui of ODL and selects the Yang UI tab, ODL stops working...could be a bug here 15:30:37 yes, I'll let you know 15:31:08 trozet: did you manage to reproduce the bug? 15:31:12 #info but I think things are in place for SR1 in Sept. Maybe we should discuss a code freeze date? 15:31:30 frankbrockners: not yet, need to do it 15:31:50 will TSC provide a code freeze date for SR1? 15:32:00 or is it more when we are ready we will tell htem 15:32:02 them* 15:32:08 if we want the TSC to do this - we can have this 15:32:15 I'd rather decide this here first... 15:32:43 i.e. I'm not too keen to drive the conversation to the TSC before we know we're all good 15:33:11 on ODL DLUX - might be good to check with Harman Singh if there is a bug 15:33:55 frankbrockners: ok Let me try it first see if I see the same thing 15:34:18 back on the SR1 freeze date: Do we feel like we're already ready to pick a date? szilard_, trozet? 15:34:45 frankbrockners: its more of...if there is a date, I want to know asap so I can plan for it 15:35:02 we were able to use the ODL GUI, but I'll double check the Yang UI today with our install. 15:35:07 frankbrockners: but if we can hold off then thats good 15:35:29 thanks RandyLevensalor that would be great if you can verify 15:35:42 If we target end of Sept, then we should freeze around mid Sept - we can use this as an implicit target 15:35:43 what about mid september ? 15:35:49 :) 15:35:54 I agree 15:37:00 mid september is fine with me 15:37:05 e.g. Sept/14 (Monday) for freeze, Sept/30 (Wed) for release could be an "objective" 15:37:35 frankbrockners: I'm OK with that 15:37:39 let's use those dates as "loose targets" for now 15:37:54 it's OK for me too 15:37:58 frankbrockners, Is there going to be a review process or something for any critical defects found between the code freeze and release? 15:39:35 RandyLevensalor: We can probably decide what we think is critical as a team - it is a small group. So if something comes up which is worth fixing, I would assume that we fix it. 15:39:48 (and push back on "cosmetic fixes") 15:40:17 let's move to the final topic 15:40:40 #topic Genesis proposal: Get ready for project creation review 15:41:02 #info Genesis is up for creation review in tomorrow's TSC call 15:41:40 #info current version of the proposal: https://wiki.opnfv.org/genesis/genesis_project_proposal 15:42:16 Could everyone scan it once more right now - just to make sure that the thing that you care about is included? 15:42:35 * trozet looking 15:42:45 Question - in Genesis scope, does "common user-observable behavior" include specification of a common CLI and API for deployment? 15:44:31 StuartMackie - it could - but it does not have to. If the Genesis team agrees to create such a requirement, i.e. have a single CLI and API for all installers, then yes. But this is something that the team would need to decide... 15:44:39 Question/Comment - have some concerns regarding this: Continue to maintain this CI/CD integration point under the genesis repository 15:44:43 any other takes on the question? 15:45:09 StuartMackie: I think the only common requirement currently is there must be a build.sh and deploy.sh to execute creating/installing a deployment 15:45:41 frankbrockners: One question... 15:46:06 frankbrockners: Is it explicitly listed here that Genesis will interface with other OPNFV projects to incorporate their requirements into installers? 15:47:38 trozet: Good point. We might want to have some verbiage around this. 15:48:01 We have the Genesis work procedures: https://wiki.opnfv.org/genesis/genesis_work_procedures - but it would be great to see them reflected in the proposal as well 15:48:53 trozet: Do you have a sentence in mind? I would be good to say that Genesis interfaces with other projects, but expects other projects to do the integration work 15:49:01 frankbrockners: I think that is an important thing to highlight in the review 15:49:24 fdegir: Good observation. Should we remove that sentence? build.sh/deploy.sh might live in the installer repos 15:49:36 that would be good 15:50:08 genesis defines what scripts should be placed where as we did for arno 15:50:20 and they live in installer repos as you said 15:50:23 trozet: yes it is - I had several conversations on the topic. projects need to understand that the integration effort is on them - not on a magic helping hand in Genesis or installer projects 15:50:27 frankbrockners: Genesis will serve as an interface for projects with OPNFV Platform dependencies to initiate requests for their requirements. The requesting project will be responsible for assisting with the implementation work itself. 15:51:01 does that sound ok? 15:51:55 trozet: How about making it even stronger: The requesting project is responsible for the integration and implementation work of their requirements. 15:52:17 sure 15:52:32 installer projects can assist in the implementation too 15:52:34 Couldn't some of the implementation be done by the installers and not the requesting project? 15:52:57 fdegir: Sentence in question removed 15:53:21 thx frankbrockners 15:53:34 trozet: of course installer projects will assist - but let's state responsibilites clearly 15:53:34 there should probably be collaboration from installers and requesting project 15:53:38 ok 15:54:14 folks will collaborate - but if you bring something new, it is up to you to drive the integration & implementation 15:54:40 ok 15:55:03 Should the collaboration also that Genesis will level set the priority of the requests for the installers. (i.e. Is it required to be a complete installer for a release or just a nice to have feature) 15:55:05 otherwise I fear that people will put requirements out and say "now go and implement this" 15:55:38 RandyLevensalor: thats a good idea, we probably should prioritize them 15:55:50 RandyLevensalor - that is the expectation, i.e. choose what goes into the next release and what is "nice to have in the future" 15:58:48 trozet: just updated the wiki: https://wiki.opnfv.org/genesis/genesis_project_proposal?&#scope - have a look 15:58:58 How about this for the wording.: Genesis will serve as an interface for projects with OPNFV Platform dependencies to initiate and prioritize the requests for their requirements. The requesting project is responsible for the integration and implementation work of their requirements. Requesting projects and individual installers will collaborate on the implementation. 15:58:59 (last bullet) 15:59:29 RandyLevensalor: sounds good to me 15:59:35 RandyLevensalor: even nicer.. 16:00:07 wiki got updated again 16:00:21 we're at the top of the hr 16:00:32 any additional things that need fixing? 16:00:59 nope 16:01:02 looks good to me 16:01:06 if so, we can switch to opnfv-bgs for that discussion and free up this channel... 16:01:09 ok cool... 16:01:15 then let's call it a day 16:01:18 thanks everyone! 16:01:21 #endmeeting