16:00:08 <xarses> #startmeeting fuel
16:00:08 <xarses> #chair xarses
16:00:08 <xarses> Todays Agenda:
16:00:08 <xarses> #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
16:00:09 <openstack> Meeting started Thu Aug 27 16:00:08 2015 UTC and is due to finish in 60 minutes.  The chair is xarses. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:13 <openstack> The meeting name has been set to 'fuel'
16:00:14 <openstack> Current chairs: xarses
16:00:24 <xarses> Who's here?
16:00:32 <kozhukalov_> \o
16:00:33 <angdraug> o/
16:00:33 <evgenyl> Hey
16:00:34 <akislitsky__> hi
16:00:37 <mwhahaha> hi
16:01:02 <rmoe> hi
16:01:18 <sbog> hi all
16:02:14 <angdraug> lets start?
16:02:14 <xarses> ok, lets get started
16:02:21 <xarses> #topic Fuel branching strategy (angdraug)
16:02:27 <angdraug> I have summarized the discussion of the Fuel branching strategy on openstack-dev:
16:02:27 <angdraug> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072762.html
16:02:27 <angdraug> comment period ends tomorrow, if you have concerns please catch up on the thread and respond NOW
16:02:27 <angdraug> initial agreement on the thread is that we do short 2 week feature freeze in 8.0
16:02:27 <angdraug> this will allow us to start decoupling Fuel release cycle from MOS and move closer to OpenStack dates
16:02:30 <angdraug> we can't align to OpenStack release schedule in 8.0 because we'll have a late start
16:02:32 <angdraug> but if we open master branch early, we can start Mitaka support for 9.0 early enough
16:02:34 <angdraug> thoughts?
16:03:33 <xarses> seems good
16:04:18 <kozhukalov_> looks good to me
16:04:34 <kozhukalov_> 2 weeks is not so long
16:04:55 <angdraug> I think we won't be able to follow the OpenStack dates exactly, but we should have a relatively small lag behind Puppet OpenStack and RPM/DEB packaging projects
16:05:43 <xarses> ya, it should be helpful
16:05:57 <xarses> ok, moving on then
16:06:01 <angdraug> yup
16:06:10 <xarses> #topic Plan for puppet-librarian for 8.0 (mwahaha)
16:06:14 <mwhahaha> As we approach the start of 8.0 we are going to continue our migration of modules to leverage librarian for upstream modules within fuel-library.
16:06:14 <mwhahaha> #link https://blueprints.launchpad.net/fuel/+spec/fuel-puppet-librarian
16:06:14 <mwhahaha> #link https://review.openstack.org/#/q/topic:bp/fuel-puppet-librarian,n,z
16:06:16 <mwhahaha> We have put together the list of modules, their upstream repositories and various differences from the existing version we synced with and what actually lives within fuel-library today.
16:06:18 <mwhahaha> #link https://etherpad.openstack.org/p/fuel-librarian-repos
16:06:24 <mwhahaha> As part of preparation for 8.0, we have already begun to get these modules synced over to fuel-infra so that we can beging the module cutover to librarian.
16:06:24 <mwhahaha> #link https://bugs.launchpad.net/fuel/+bug/1487568
16:06:26 <openstack> Launchpad bug 1487568 in Fuel for OpenStack "additional repos for puppet modules for librarian" [High,In progress] - Assigned to Sergey Otpuschennikov (sotpuschennikov)
16:06:26 <mwhahaha> We are going to primarily focus on the OpenStack puppet modules as the main set of modules that must be cut over by the end of 8.0. With the help of Ivan Berezovskiy, we have begun to create MOS-8.0 branches based on master for the OpenStack modules.
16:06:26 <mwhahaha> Our goal is to try and have this branch be as close as possible to master. We will be manually synchronizing from master -> MOS-8.0 on a regular basis. Once we have stabilized for liberty, we will need to cut a tag that we will be using for the Puppetfile (hopefully prior to FF).
16:06:32 <mwhahaha> At the moment the modules that have most diverged from upstream and will be the most problematic are rabbitmq, mysql, corosync, haproxy, rsync and mongodb. We will be working towards getting these trued up but they currently are not as high of a priority to the OpenStack puppet modules which we will be attempting to migrate to first.
16:06:32 <mwhahaha> I am planning to review the list of modules and their upstream differences and will be compiling a list for the OpenStack Puppet mid-cycle next week in hopes that any outstanding requests can be addressed at that time. Our goal should be to work in the upstream first, and only diverge if we absolutely must.
16:06:45 <mwhahaha> end wall o' text
16:07:52 <sbog> How we will deal the cases when changing of upstream module needed for bug fixing?
16:08:08 <mwhahaha> in terms of new version?
16:08:11 <angdraug> sbog: a branch on review.fuel-infra.org
16:08:13 <sbog> Yep
16:08:38 <mwhahaha> we can update the puppetfile with the new tag or us a branch & custom tag via fuel-infra
16:08:47 <angdraug> worst case, we can refer a sha1, ideally it should always be a tag
16:08:58 <sbog> ok, got it, thanks
16:09:12 <angdraug> mwhahaha: or do you plan to always have integration tags on fuel-infra?
16:09:47 <mwhahaha> ideally I would like to use the actual upstream tag version
16:10:04 <angdraug> yeah, I'm asking about a fall-back case
16:10:18 <mwhahaha> I think it depends on timing and the fix itself
16:10:25 <angdraug> e.g. upstream master or stable has the commit but it's not tagged yet
16:10:50 <angdraug> #link https://wiki.openstack.org/wiki/Fuel/Library_and_Upstream_Modules
16:11:01 <mwhahaha> i would use an '<upstream version>-mos' tag until the new upstream release is cut
16:11:04 <angdraug> I think best practices section in ^^^ will need an update
16:11:25 <mwhahaha> yes it most likely will as we work on this and find what works and what doesn't
16:11:35 <angdraug> mwhahaha: can't move a tag, so it has to be more specific than *-mos
16:11:49 <mwhahaha> *-mos-#
16:11:54 <mwhahaha> doesn't have to
16:11:55 <angdraug> yes, that would work
16:12:10 <mwhahaha> we need to see how many times we run into this before trying to over engineer it
16:12:33 <angdraug> true
16:12:52 <angdraug> ALL: note the mention of Puppet OpenStack mid-cycle irc meetup next week
16:13:28 <angdraug> if you've got a commit on review that we need to land in order to move a module to librarian, watch for the Fuel session in the meetup
16:13:52 <angdraug> moving on?
16:13:59 <mwhahaha> sure
16:14:25 <xarses> #topiv Brief report on bug status in Fuel (adidenko)
16:14:47 <xarses> alex_didenko: ^
16:15:13 <alex_didenko> just a brief report on the current state
16:15:21 <alex_didenko> Open bugs in library: 15, on review: 5, avg review wait: 20hrs
16:15:21 <alex_didenko> Open bugs in python: 10, on review: 7, avg review wait: 18hrs
16:16:03 <xarses> how does the burn down rate look?
16:16:04 <angdraug> alex_didenko: what is the churn rate (how many are opened/closed every day)?
16:16:09 <angdraug> haha )
16:16:34 <alex_didenko> well, it's hard to share burndown in IRC
16:17:16 <alex_didenko> but we're still above the guide line
16:17:37 <angdraug> how about fixed per day / opened per day?
16:18:17 <alex_didenko> the numbers are different, but the trend is positive, for instance on the last week: 62 incoming, 78 outgoing
16:18:35 <alex_didenko> this week so far 40/51
16:18:42 <angdraug> so roughly 10-25 per day on average
16:18:45 <alex_didenko> those are only crit/high
16:19:05 <angdraug> looks like we're in good shape for HCF then
16:19:27 <alex_didenko> yep
16:20:28 <alex_didenko> we managed to handle the problem with high amount of in progress bugs, so thanks to all how did a good job on code review
16:20:57 <alex_didenko> I guess that's it from my side
16:21:14 <xarses> #topic Throw away local ubuntu mos repo from the master node in 8.0 (kozhukalov)
16:21:30 <kozhukalov_> today we had a discussion about removing debug packages from
16:21:30 <kozhukalov_> the MOS mirror we put on the master node https://review.openstack.org/#/c/217590/
16:21:38 <kozhukalov_> it would safe about 600MB of place on the ISO
16:21:51 <kozhukalov_> but to me it looks much more attractive to avoid having MOS mirror on the master node
16:21:58 <kozhukalov_> it immediately allows us to avoid building DEB packages together with ISO
16:22:34 <kozhukalov_> the only obstacle to remove building deb package during building ISO is custom_iso jobs
16:22:38 <xarses> don't we build packages for the fuel-library still?
16:23:16 <kozhukalov_> yes, but fuel-library is also built by perestroika
16:23:44 <kozhukalov_> and we can just take all those packages from online repository
16:24:06 <kozhukalov_> we upgrade public MOS link every 6 hours
16:24:28 <angdraug> sounds good to me
16:24:32 <kozhukalov_> so once a change is merged it is going to become available in several hours
16:24:51 <angdraug> I agree that it's 8.0 scope, too late for 7.0
16:25:08 <kozhukalov_> sure it is too late for 7.0
16:25:54 <kozhukalov_> ok, we then will keep this in our scope
16:25:56 <angdraug> since we're out of agenda and have time, can you catch us up on fuel build cleanup plans for 8.0?
16:26:05 <xarses> seems good here
16:27:08 <kozhukalov_> 1) will continue to split fuel-web into separate projects
16:27:32 <kozhukalov_> for example UI is going to become the first one after HCF
16:27:52 <angdraug> fuelmenu and shotgun are my personal favorites there :)
16:28:34 <kozhukalov_> 2) will re-work fuel upagade script so we can put it into package and avoid having upgrade tarball
16:29:22 <kozhukalov_> 3) will integrate centos image build script into fuel-agent (like for ubuntu currently)
16:29:58 <kozhukalov_> 4) move building docker images package to perestroika
16:30:30 <kozhukalov_> 5) and of course stop building packages both rpm and deb together with iso
16:30:57 <kozhukalov_> all packages will come the mirrors built by perestroika
16:31:11 <kozhukalov_> these are plans
16:31:14 <angdraug> looks simple enough :p
16:31:34 <kozhukalov_> re-working upgrade tarball is not so simple
16:32:21 <kozhukalov_> because we need to get rid of some approaches we have been using since the beginning of Fuel project
16:32:55 <angdraug> at least it has unit tests
16:33:14 <angdraug> how long do you think it's going to take?
16:33:45 <kozhukalov_> python code is not a problem at all, the upgrade approach is a problem
16:34:07 <kozhukalov_> we usually put rpm and deb repos into upgrade tarball
16:34:23 <kozhukalov_> and the we mark this tarball by build id
16:34:50 <kozhukalov_> but it totally contradicts with package based approach
16:35:30 <kozhukalov_> how long do you think it's going to take? - depends on the rate of discussions
16:36:07 <kozhukalov_> 3-4 weeks ago I sent e-main about getting rid of version.yaml
16:37:19 <kozhukalov_> to throw it away, we need to make available some info from this file via other sources
16:37:51 <kozhukalov_> like for example sha commits can be easily substituted by rpm -qa
16:38:12 <kozhukalov_> we can throw away api version
16:38:13 <mihgen> sorry I just joined, but I have an opinion - all needs to be flexible. If some will want to have that repo on an ISO, fine - just allow it in a build system
16:38:40 <angdraug> not sure rpm -qa by itself is enough to substitute sha commits
16:38:47 <kozhukalov_> mihgen: why?
16:39:08 <mihgen> kozhukalov_: why to keep an option to have openstack packages on an ISO?
16:39:14 <angdraug> only if we begin enforcing recording of commit ids in the rpm changelogs
16:39:36 <kozhukalov_> angdraug: it can, because the package version contains the number of commit as its part
16:39:39 <angdraug> mihgen: you missed the part where it was only abug *-dbg packages
16:39:53 <kozhukalov_> and package itself contains the info about sha
16:40:28 <angdraug> that's what I'm saying: package only contains git sha if spec committer has put it there, no?
16:40:29 <mihgen> disregard my message then
16:40:57 <kozhukalov_> mihgen: yes, i don't see any reason why we need to put this repo on the ISO, anyway we can not deploy ubuntu nodes w/o ubuntu mirror
16:41:05 <kozhukalov_> the same for mos
16:42:13 <kozhukalov_> angdraug: my topic started from discussing dbg packages
16:42:34 <kozhukalov_> angdraug: but my suggestion is to use only online mos repo
16:43:08 <kozhukalov_> we don't need this local repo on the master node by default
16:43:31 <angdraug> ok, I missed that part
16:44:14 <kozhukalov_> if one needs to have local repo, it can use rsync or fuel-createmirror script
16:44:39 <kozhukalov_> s/it/he/
16:44:49 <angdraug> in that case mihgen's question is still valid: why not make it a build time option to include mirrors in the iso?
16:45:23 <xarses> angdraug: +12
16:45:26 <xarses> angdraug: +1 even
16:45:33 <xarses> the downstreams tend to make use of this
16:45:46 <angdraug> ideally, use fuel-createmirror for that
16:45:52 <kozhukalov_> because it is more complicated to deal with this stuff
16:45:59 <xarses> and would allow for an inhouse to have repos
16:46:07 <angdraug> so that the default ISO has no mirrors, and you use fuel-createmirror to create them later
16:46:10 <mihgen> folks it should be just flexible. Ideally, user would have all-in-one thing if he wants
16:46:14 <xarses> which is a noted problem people have with the change
16:46:15 <mihgen> so we just need to allow this.
16:46:25 <angdraug> but you can pre-cook the result of running fuel-createmirror into the ISO if you wanted
16:46:35 <kozhukalov_> we don't need this logic both in our default deployment flow as well as in our upgrade procedure
16:46:55 <mihgen> it should be part of artifact-based build system flexibility
16:47:11 <angdraug> not in upgrade procedure, just an option that custom iso builders can use
16:47:12 <xarses> kozhukalov_: we dont need it
16:47:16 <mihgen> we need to be able to have as well as separate pieces and modules built, or the all things on one iso
16:47:19 <xarses> but our users very much do
16:47:27 <kozhukalov_> mihgen: anyway a user does not have all in one thing
16:47:39 <kozhukalov_> ubuntu repo is online anyway
16:47:52 <mihgen> kozhukalov_: true. But I'd like this to evolve at some point
16:47:56 <mihgen> and have debian support
16:48:00 <xarses> kozhukalov_: which alot of people can't work with
16:48:03 <kozhukalov_> mihgen: i agree about artifact based approach
16:48:10 <xarses> I hear many complaints about it
16:48:15 <mihgen> and an option to get all upstream community DEB pacakges on ISO to get offline install
16:48:48 <mihgen> and so instead of introducing limitations, just make it flexible. We can focus on one needed use case for now though
16:49:02 <mihgen> and then evolve as needed. But design should allow flexibility.
16:49:15 <kozhukalov_> once it is available and once we have mature tool to deal with any artifacts the same way, it is not gonna bring additional complexity
16:49:52 <angdraug> kozhukalov_: package repo mirror is an artifact, too
16:50:04 <kozhukalov_> angdraug: yes
16:50:27 <angdraug> why not have a) job to build it with fuel-createmirror; and b) an option in the build to add it into the iso?
16:50:38 <kozhukalov_> good example is fedora-release package
16:50:55 <angdraug> how so?
16:51:01 <kozhukalov_> it just configures /etc/yum.repos.d/fedora.repo
16:51:56 <kozhukalov_> or we can even put repo into artifact
16:52:08 <angdraug> that's what I'm suggesting
16:52:19 <kozhukalov_> let say into rpm package for simplicity
16:52:59 <angdraug> sure
16:53:12 <kozhukalov_> i mean the way to deal with repo must not differ from the way how we deliver other components
16:53:46 <angdraug> not as elegant as letting the artifact based build system recognize yum/apt repos as their own artifact types, but as a first iteration, sure
16:54:19 <kozhukalov_> that level of flexibility is ok, but having yet another variable in our make scripts does not look like flexibility, but rather complexity
16:55:57 <kozhukalov_> 5 minutes
16:56:09 <kozhukalov_> do we have any other stuff to discuss
16:56:11 <xarses_> fun, bad internet connection...
16:56:22 <xarses_> my exact thoughts
16:57:28 <xarses_> ok, I will cose the meeting
16:57:30 <xarses_> thanks all
16:57:34 <xarses_> #endmeeting
16:57:49 <xarses_> #chair xarses_
16:58:03 <xarses_> fun, i guess not
16:58:12 <kozhukalov_> looks like bot is dead
16:58:20 <xarses> #endmeeting