12:59:04 <s_berg> #startmeeting Weekly Fuel meeting
12:59:04 <collabot`> Meeting started Thu Jan 14 12:59:04 2016 UTC.  The chair is s_berg. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:59:04 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:59:04 <collabot`> The meeting name has been set to 'weekly_fuel_meeting'
12:59:40 <z0d> #info Peter Barabas
12:59:53 <s_berg> #info Stefan Berg
13:00:01 <s_berg> https://global.gotomeeting.com/join/173997389
13:00:33 <mskalski> #info Michal Skalski
13:01:50 <s_berg> mskalski: You on GTM as well?
13:02:14 <z0d> GTM is 'waiting for meeting to start'
13:02:18 <mskalski> s_berg: yes, but it says waiting for organizer
13:02:59 <Guest48551_> No gtm today Jonas
13:03:18 <s_berg> OK, let's turn this into an IRC only meeting for now then.
13:03:48 <s_berg> #topic Status of Fuel 8 uplift
13:04:18 <Guest48551_> Im on a mobile device so stefan takes the lead/Jonas
13:04:44 <z0d> I'm debugging why fuelmenu doesn't show up. it's probably the last problem before I can deploy using Fuel 8
13:05:06 <s_berg> So I've been struggling with the Fuel 8 uplift for a while, but now both the Fuel upstream and the changeset in OPNFV are looking quite good.
13:05:21 <mskalski> z0d: did you add showmenu=yes to kernel options in grub menu?
13:05:27 <z0d> mskalski: yes
13:06:04 <s_berg> A few changes are needed, not for the OPNFV builds but rather for the build to work in the Ericsson internal environment. :) Hopefully this will be concluded by tomorrow.
13:06:08 <z0d> well, the main problem is that I get a half-complete /etc/fuel/astute.yaml: the variables aren't filled in (e.g. ${mos_version})
13:06:26 <Guest48551_> I think we merge fuel8 to master
13:07:06 <s_berg> #info Fuel 8 uplift almost concluded.
13:07:12 <s_berg> #link https://gerrit.opnfv.org/gerrit/#/c/5913/
13:07:52 <s_berg> Yes, that was my thought as well. Now the B-release activitites are on stable, so I propose the same - let's merge into master and start getting plugins and deployer in shape.
13:08:11 <z0d> mskalski: so even if I start fuelmenu manually, astute.yaml will be incomplete. where should it be filled in?
13:08:12 <s_berg> Meanwhile things will of course break in different places, which is expected.
13:08:20 <Guest48551_> +1
13:08:26 <z0d> +1
13:08:26 <s_berg> Anyone opposed that idea?
13:08:33 <ruijing> great. I have another question: so B-release use fuel 7.0?
13:09:04 <ruijing> +1. to merge to master branch
13:09:09 <s_berg> ruijing: At least for the time being.
13:09:12 <Guest48551_> No we go for fuel8
13:09:40 <ruijing> ok. so we need to go to master and get stable then possibly go to B-Release Branch
13:09:55 <s_berg> The important thing is to stabilize the Fuel 8 proper in master to start with, and not disrupt the activities in stable until plugins have rebased.
13:09:58 <Guest48551_> But we dont cherry before all plugins work
13:10:16 <s_berg> Exactly.
13:10:28 <ruijing> yes.
13:10:45 <s_berg> #agree We merge the Fuel 8 in master and uplift it, but do not merge into stable until all plugins are proven to work.
13:11:00 <s_berg> #topic Status of deploy with Fuel 8
13:11:15 <mskalski> z0d: we are talking here about /etc/fuel/astute.yaml ?
13:11:21 <z0d> mskalski: yes
13:11:32 <s_berg> z0d, you're working with the deploy uplift for Fuel 8. What's the current status?
13:12:29 <z0d> s_berg: I'm trying to find out why astute.yaml isn't properly filled in. after that we can run deployments with deploy.py.
13:13:18 <s_berg> So values are missing?
13:13:36 <z0d> variables aren't expanded and some values are missing from the end of it
13:13:37 <s_berg> Isn't it the deployer that provides /etc/fuel/astute.yaml?
13:14:19 <s_berg> #info The Fuel 8 deploy uplift it currrently blocked with configuration changes in /etc/fuel/astute.yaml
13:14:32 <z0d> not the whole part
13:14:47 <s_berg> #info Peter Barabas (z0d) is working together with Michal Skalski (mskalski) to resolve.
13:14:54 <s_berg> Right?
13:15:14 <z0d> right
13:16:18 <z0d> I might have found the problem. If not, I'll send an email to Michal
13:16:52 <ethfci> z0d what the problem is in a nutshell?
13:17:10 <ruijing> for deploy, we mannually update deb repo. can we set default deb repo?
13:17:55 <s_berg> OK, you guys seems to be on track then. :)
13:18:26 <ethfci> ruijing you can set by fuel cli/settings upload
13:18:47 <ruijing> yes. I use cli to set deb repo.
13:19:10 <s_berg> Not sure if I get this about the repo ruijing. The plugins adds debs to the repo on Fuel master?
13:19:11 <ruijing> but for our users, they don't know how to set (difficult for our user)
13:20:01 <s_berg> #topic Other issues
13:20:21 <ruijing> I think the deb repo is updated due to offline mode or we change some deb packages?
13:20:54 <s_berg> Yes, the repo is pre-populated so the deploy doesn't require Internet access.
13:21:35 <s_berg> What we've said before (as far as I know) is that any dependencies not in the pre-populated package repo on Fuel master needs to be packaged in the plugin?
13:22:08 <ethfci> ruijing the ponfv cd installs everything itself, no additional file access needed
13:22:47 <ruijing> I will send email to clarify the problem.
13:23:08 <s_berg> ruijing: Thanks!
13:23:19 <ruijing> Thanks, s_berg:)
13:23:29 <s_berg> #info Ruijing will send e-mail describing deb repo issue.
13:24:00 <mskalski> s_berg: or add them to fuel-createmirror script https://gerrit.opnfv.org/gerrit/#/c/3679/
13:25:48 <ethfci> Jonas of Fuel experts, what ha_compact mode is?
13:25:57 <s_berg> mskalski: Yes, that's an idea. But that decouples the changes from where they're needed though, so maybe a little bit more difficult to keep track? If they are packaged in the plugin, obsoleted packages will break in "the right place".
13:26:26 <s_berg> (but cause the opposite problem if multiple plugins need the same package...)
13:28:12 <mskalski> s_berg: not sure If got your point, but for me adding upstream packages to fuel-createmirror is a way better than managing version and dependencies inside plugin
13:28:40 <mskalski> s_berg: the different situation is when you have your own custom package
13:29:01 <ethfci> Michal You are right.
13:29:09 <s_berg> mskalski: Yes, you have a point there.
13:30:56 <s_berg> So maybe the recommendation for now should be to add packages needed to the fuel-createmirror config, but very clearly denote which plugin/functions introduces the requirement.
13:31:07 <s_berg> OK?
13:32:44 <ethfci> Stefan I feel however opnfv basic should not have dependencies on plugins
13:34:14 <s_berg> ethfci: I think we're discussing the opposite scenario, if a plugin needs an additional Debian package not available by default (during offline deployment), should the plugin carry the the upstream package or should it be added to the package mirror carried by the Fuel master.
13:34:47 <mskalski> s_berg: putting requirements-deb.txt in plugin catalog is not enough to track which plugin added package to download?
13:36:11 <ethfci> Stefan, opendaylaght plugin had an option wether to include requred packages or not
13:36:20 <ethfci> as i recall
13:36:26 <s_berg> mskalski: Sorry Michal, I'm on a small device today - now I managed to open the change!
13:36:40 <s_berg> mskalski: Yes, of course, that's great!
13:36:56 <mskalski> s_berg: repobuild shoud automaticaly fetch the list and try add only uniq packages
13:37:49 <s_berg> mskalski: OK, *now* I get it. Yes, of course, this is the way to go!
13:38:22 <ethfci> Michal repobuild is ok if we won't have homebrew packages
13:38:42 <mskalski> ethfci: yes it is still there but keeping current list of versions of packages is a nightmare, and with fuel-createmirror it is easier
13:38:54 <s_berg> #agree https://gerrit.opnfv.org/gerrit/#/c/3679/ is the method to use for a plugin depending on additional upstream packages
13:39:15 <mskalski> ethfci: of course packages which are not available in upstream repos are still a part of the plugin
13:39:33 <s_berg> Agree, that is the only way to do it.
13:40:00 <s_berg> But all other plugins should be pulled using Michal's method - it's a great improvement.
13:40:19 * s_berg thinks he had too long vacation...
13:41:05 <ethfci> :D
13:41:19 <s_berg> Anything else to bring up from anyone?
13:41:48 <z0d> -
13:42:09 <ethfci> Stefan where can i found info for fuel8 based opnfv?
13:42:12 <mskalski> when we have a deadline for stable version of plugin?
13:43:08 <s_berg> ethfci: Right now it's in https://gerrit.opnfv.org/gerrit/#/c/5913/
13:43:17 <ethfci> ok
13:43:27 <s_berg> ethfci: Will need to to a couple of more fixes, but it has build successfully at least once. :)
13:44:30 <ethfci> one stupid question: if i update Szilard scripts shall i reuse the existing structure?
13:44:47 <ethfci> the scripts has a lot of ip addresses
13:44:55 <s_berg> mskalski: Plugins in general stable for the B release? I don't by heart, we need to ask Jonas tomorrow.
13:45:07 <mskalski> s_berg: ok
13:45:38 <mskalski> btw can we make next meting on gtm?
13:46:04 <billyoma> re repos discussion above does that mean that plugins need to tell fuel team about all standard packages that they need so that they can be put in the main fuel-master repo?
13:46:06 <s_berg> mskalski: Of course! Jonas was called away, and I can't host GTM so today was a special case.
13:46:36 <mskalski> s_berg: no problem at all, just asking :)
13:47:39 <ethfci> Steafa will we use the GoToMeeting in the future?
13:48:02 <s_berg> billyoma: I think plugins rather need to add the requirement file (see https://gerrit.opnfv.org/gerrit/#/c/3679/) to the plugin integration directory of the Fuel repo. .)
13:48:51 <s_berg> billyoma: But yes, it needs to be in the Fuel repo to actually be added to the Fuel master package cache. And it is *only* relevant for packages available in Ubuntu upstream. Any other package needs to be carried by the plugin.
13:49:18 <s_berg> ethfci: Yes.
13:49:25 <ethfci> what is the difference between multinode nad ha ?
13:49:27 <billyoma> s_berg: ok, thanks. So add to build/f_isoroot/f_XXXpluginbuild/requirements-deb.txt.
13:49:42 <s_berg> billyoma: Correct (or it is if mskalski agrees...). :)
13:50:17 <mskalski> ethfci: now it is only ha, multinode was used in previous fuel releases
13:50:24 <billyoma> Can we also leave them in fuel-plugin-xxx/.../dependencies.txt ? Where pre_build_hook wgets them into repositories/<OS>/ directory ?
13:50:41 <mskalski> ethfci: even it is ha mode you can still deploy 1 OpenStack controller
13:51:18 <s_berg> billyoma: You mean in the plugin's own repo? They won't be picked up on from there.
13:52:18 <s_berg> So closing the formal meeting in 3...
13:52:29 <s_berg> 2...
13:52:37 <s_berg> 1...
13:52:39 <s_berg> #endmeeting