13:59:09 #startmeeting Weekly Fuel meeting 13:59:09 Meeting started Thu Jul 2 13:59:09 2015 UTC. The chair is Jonas1. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:59:09 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:59:09 The meeting name has been set to 'weekly_fuel_meeting' 13:59:23 #info Jonas Bjurel 13:59:28 #info Szilard Cserey 13:59:49 #info Stefan Berg 14:00:02 * stefan_berg (talk about stating the obvious...) 14:00:31 #info Fatih Degirmenci 14:01:19 Please info your attendance! 14:01:31 ok 14:01:55 #info Michal Skalski 14:02:03 #topic Agenda bashing 14:02:37 So I would like too discuss what we need to do til SR1 in terms of refactoring etc. 14:02:55 good 14:03:07 More ideas for the Agenda? 14:04:05 #info 1) SR1 planning 14:04:16 Hi, team. I just join the project. can somebody have sumary for current status and gap? 14:04:36 Hi Ruijing! welcome :) 14:04:40 ruijing - Welcome 14:04:55 Thanks:) 14:04:56 * stefan_berg waves happily in the general direction of ruijing - nice to have you on board! 14:05:14 ruijing: Hope we can cover that as we go along 14:05:37 #info 2) Fuel@OPNFV incubation 14:06:03 #topic SR1 plans 14:06:15 Welcome Szymon 14:06:31 Hi Guys. 14:07:14 So my view of the status is that we almost done on component level. I.e. ODL and production autodeploy 14:07:15 Cześć 14:07:27 Am I right? 14:07:55 how to maintain the code ?https://github.com/stackforge/fuel-main? or clone from stackforge? 14:07:57 yes we are done 14:08:33 We clone from stackforge today 14:08:46 ruijing: plugin code is here https://github.com/stackforge/fuel-plugin-opendaylight 14:09:16 Michal, do you agree that most of the ODL plugin is ready? 14:09:17 what about ODL, I have to create additional patch for the autodeployer 14:09:48 becuase ODL is handled separately, and have to be installed by autodeployer after Fuel Master is brought up 14:09:57 szilard: I guess so 14:09:57 I mean the ODL plugin 14:10:16 I think that yes, keeping on mind limitation like no HA and l3 managed by neutron 14:10:16 yes, so there will be some additional patches coming in the next days 14:10:35 mskalski: limitations agreed 14:10:56 #info Components are ready for the SR1 release. 14:11:12 components ? 14:11:25 So now we need to refactor the buildsystem, adjust autodeployer, etc. 14:11:33 yes 14:11:58 #info With components is meant ODL plugin and autodeploy production code 14:12:08 I will add some minor improvement to the Autodeployer regarding blade handling 14:12:23 szilard: good 14:12:56 So we should be good to start the refactoring on master already now 14:13:20 I agree 14:13:25 will do 14:13:36 #info refactoring build system can start on master now. 14:14:21 So what strategy do we have. Build Fuel 6.1 or just use an .iso image or have the capabilities to do both? 14:14:51 I would vote for scaling back the build system to the barebones needs of building the iso. 14:15:18 Should most be a matter of removing some patches, I would believe. 14:15:47 Yes its like today, but remove all patches, install.sh, etc. 14:15:50 So basically keeping the ability to build the iso from Docker, and then start building it up again. 14:16:17 (porting current additions to plugins, where applicable) 14:16:55 End product of building iso will be the same for all jobs since 6.1 is stable, I don't if we need to do this 14:18:02 But it is good to have the possibility, if you sometime would want to try new stuff 14:18:03 Well, we need to be able to build from the repos at some point. I'd rather see us starting with that if it is not too big of a task? 14:18:31 (That is, we can't release R2 without the ability to build from upstream.) 14:19:24 Do we build the ODL (and others) plugin from source? 14:21:11 mskalski: Can the upstream ODL tag/branch be specified in your build system for the plugin? 14:22:30 Jonas1: https://github.com/stackforge/fuel-plugin-opendaylight/blob/master/pre_build_hook#L10 14:22:45 here I point to the stable odl release 14:23:18 there are some patches which are applied on helium release during package build 14:23:24 ODL_TARBALL_LOCATION="https://nexus.opendaylight.org/content/groups/public/org/opendaylight/integration/distribution-karaf/0.2.3-Helium-SR3/distribution-karaf-0.2.3-Helium-SR3.tar.gz" 14:23:32 which can not work with lithium 14:24:02 mskalski: Good 14:24:39 to use new version of ODL we should create new version of plugin like 0.6.0 or soemthing like that 14:24:54 current is 0.5.1 14:25:35 you can also think about giving plugins different name 14:25:54 mskalski: I was more thinking on the ODL guys in the Service function chaining. They may want to experiment beyond our comfort zone :-) 14:26:25 or you can have 1.X with Helium or 2.X with Lithium 14:26:35 Which would not render into a release. 14:27:18 Jonas1: I not tested lithium since don't find any official tarbal with that 14:27:52 I can tray to compile it and test with 6.1 14:28:03 Agree on following. We will refactor the buildsystem such that it can build from fuel upstream repos or use a pre build Fuel 6.1 .iso? 14:28:45 Are we agreeing on one of the choices, or both? 14:29:00 I was thinking both 14:30:25 I still think that we should start by building the ISO straight away, and not postpone that to later. Baby steps... 14:30:32 If we want to switch in the future release to fuel 7.0 having a buildsystem for iso could be helpful until 7.0 will be officialy released 14:30:56 stefan_berg: +1 Anyone against. 14:31:27 And we would have the same caching mechanism as today. 14:32:23 sounds good 14:32:30 #Agree We will refactor the buildsystem such that it builds from fuel upstream repos using the same cache mechanism as today. 14:32:46 #agree We will refactor the buildsystem such that it builds from fuel upstream repos using the same cache mechanism as today. 14:34:19 Next Agree that any needed current paches will be implemented as fuel plugins 14:34:47 That is cool, I agree completely :) 14:34:53 A big +1 on that one, only plugins from now on. 14:35:23 #agree Any needed current paches will be implemented as fuel plugins 14:38:11 Should we use git submodules to mirror plugins for example resiging in stack-forge? 14:38:36 rsiding it should be:-) 14:38:48 I think that's a great idea. Then we have full tracability, which would be a must, but we can disconnect the lifecycles. 14:41:44 Anyone against? 14:41:53 (and for those not fully familiar with submodules, it is a way to refer to a specific commit in another git repo and populate this in the context of the local repo containing the reference. The commit ID to the external repo is thus fully tracable.) 14:42:40 agree 14:42:43 * stefan_berg points in the direction of https://git-scm.com/book/en/v2/Git-Tools-Submodules 14:42:48 #agree We will use git submodules to mirror plugins for example resiging in stack-forge? 14:43:06 #undo 14:43:06 Removing item from minutes: 14:43:21 #agree We will use git submodules to mirror plugins for example resiging in stack-forge 14:43:26 #link https://git-scm.com/book/en/v2/Git-Tools-Submodules 14:43:56 but where do you want to keep this submodules? in genesis repo: 14:43:58 ? 14:44:22 In the hopefully-to-be OPNFV Fuel repo I guess? 14:44:38 ok 14:44:42 (as Fuel has been proposed by Jonas as an installer project of its own right) 14:44:57 (not that it haven't been so from day one!) 14:45:10 stefan_berg: Correct 14:45:27 Anything more we need to do on the build system before we cover autodeploy? 14:45:52 Silence... 14:46:18 no 14:47:09 So what needs to be done on the deployer side to cope with 6.1 and plugins? 14:48:13 first we have to provide a new parameter for the Autodeployer, path to the plugins 14:48:34 where he can take it, and the install them one by one after Fuel Master is up and running 14:48:46 We need to look if metadata for deployment, provisioning, node etc has changed its format or has been made more granular between the revisions. 14:49:01 with: fuel plugins --install XXX 14:49:25 And they need to be configured. 14:49:28 yes good that you brought up 14:49:39 We can never reuse the DEA data between versions (likely so at least), but we need to make sure that we adapt so we can "carbon copy" an installation and catch everything that is needed to recreate it. 14:49:49 guys, I’m not sure whether it can help but there are some qa scripts which automate plugin installation/ env installation 14:49:51 https://github.com/stackforge/fuel-qa/blob/master/fuelweb_test/tests/plugins/plugin_zabbix/test_plugin_zabbix.py 14:50:05 new config parameters have to be handled by autodeploy 14:50:33 you might taka a look into it 14:50:43 sbanka: Cool 14:50:46 ok, thanks Szymon 14:51:08 And also the "opnfv" clause in the deployment information will be gone as we are removing patches to re-align using plugins, so that logic needs to be removed in the auto deployer. 14:51:21 allright 14:52:14 #info The auto-deployer need to be adapted to 6.1 configuration, add ability to install plug-ins and configure those plug-ins. 14:53:03 What about the separate download of the OS, who will do that - build system or deployer? 14:53:15 OS=Operating System 14:53:19 That's a really good question! 14:53:36 you mean the Mirantis.iso ? 14:53:37 I assume that the OPNFV artifact is supposed to be able to deploy without Internet access? 14:54:12 ahh the Ubuntu/Centos 14:54:15 ok 14:54:42 szilard: exactly 14:55:23 I think that needs to be handled by the Autodeployer in practice, but then the deployer becomes part of CM! 14:55:36 This is handled by Fuel I guess, that's why it requires internet access from now on 14:56:15 Or lets build a webserver plugin? 14:56:25 Yes, but I assume it would be possible to put in either an internal file URI, or use an internal cache of the distribution. 14:57:41 Jonas1: Either having a webserver+data "somewhere" locally, or copying the repos onto a (very?) large ISO which seems a bit unpractical should a physical ISO actually need to be used for installation of R2. 14:58:27 I vote for a webserver, but lets contemplate on that . 14:58:29 However it is technically achieved, it makes sense to separate this into separate artifacts I think - but not referring to an Internet connection. 14:59:09 No Internet should be required 14:59:09 (once the release artifacts - undefined at this point - are downloaded, they should require no external access.) Can we agree on that? 14:59:27 stefan_berg:+1 14:59:55 +! 14:59:57 +1 15:00:01 sorry doesn't understand what Operating System do you want to download, you talking about packages required during nodes provisioning ? 15:00:13 #agree No Internet connection should be required to deploy 15:00:16 mskalski: Sorry for using strange terminology. Yes! 15:01:01 In 6.1 there is option to point local repositories 15:01:10 https://docs.mirantis.com/openstack/fuel/fuel-6.1/operations.html#fuel-createmirror-usage 15:01:22 wonderfull 15:02:03 sorry direct link not work but it can be found on this page by searching createmirror 15:02:47 #info We need to look into how to store packages (OS, etc) needed for node provisioning deploying a local mirror. 15:03:04 So we're over time. 15:03:28 I think we know reasonably well what to do - or? 15:04:32 Yes, the "what" is quite clear I think, and some of the "who" but I think we all need to pitch in here. 15:04:52 yes it's pretty clear now what to do 15:04:55 Vacation times are starting in Sweden, so attendance will be spotty during July and 2 weeks into August 15:05:24 Some tasks, like experimenting with repo mirroring and other new concepts in 6.1 are perhaps a starting point to newcomers in this group to get up to speed using existing docs? 15:06:01 stefan_berg: Yes, that is an excelent proposal 15:06:36 But please, join in on Tue and Thu if you are not on vacation, and why not take notes as well. 15:06:42 Anything more? 15:06:53 3 15:07:08 2 15:07:09 * stefan_berg Yay, the old school countdown! :) 15:07:14 1 15:07:24 #endmeeting