← Back to team overview

fuel-dev team mailing list archive

Almost ready for Hard Code Freeze

 

Fuelers,
we had a hard time squashing ton of bugs - 421 publicly reported bugs
already closed in 5.0.

Now we see quite low number of bugs coming daily with extensive testing,
and we fix more than we find. You can take a look at bug trends here:
http://fuel-launchpad.mirantis.com/project/fuel/bug_trends/5.0

Main issues which needs to be closed in 5.0 (excluding documentation / qa /
devops):
Critical - 2 bugs
image could not be stored in rbd in case if ceph is using as backend for
glance <https://bugs.launchpad.net/bugs/1319106>
Wrong interface in dnsmasq.conf inside cobbler
container<https://bugs.launchpad.net/bugs/1319412>

High priority - 8 bugs
HA. Nova-compute is down after destroying primary
controller<https://bugs.launchpad.net/bugs/1289200>
mcollective failed to upload image but error was deployment timed
out<https://bugs.launchpad.net/bugs/1312443>
[OSTF]After succesfull cleanup button 'run test' does not
appear<https://bugs.launchpad.net/bugs/1318631>
Cannot create bootable volume on CEPH backend for
cinder<https://bugs.launchpad.net/bugs/1319046>
keystone-manage db_sync failed on first controller in ha
mode<https://bugs.launchpad.net/bugs/1319087>
add stickiness=1 to neutron agents PM
resources<https://bugs.launchpad.net/bugs/1312177>
[UI] Node renaming issues <https://bugs.launchpad.net/bugs/1317107>
'list index out of range' error on group node disks
configuration<https://bugs.launchpad.net/bugs/1319306>

All of them are taken by engineers and being addressed.

We need to think about two questions:

   1. HA issues, summarized at
   https://etherpad.openstack.org/p/fuel-ha-rabbitmq. If we are about to
   provide fixes in 5.0, or we can address them in 5.0.1
   2. Current definition of HCF is strict -
   https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze. Pros is that we
   keep working in master and thus there is no need in providing patches to
   both master and stable/5.0 branch. Cons is that we block UI & Python teams
   which have almost 0 bugs to work on.
   My suggestion for now is to call for HCF even if we think about HA
   issues as those which are critical, and keep a small group of people
   addressing those issues, while the rest of the team will move ahead and
   start landing 5.1 changes into master. And I believe we should concentrate
   and call for HCF *already tomorrow*.
   3. For further, I think we would rather call for HCF not when we reach
   <=5 High bugs and 0 criticals, but somehow based on bug trends over last
   days. With a few components in Fuel, it seems to be pretty strict (no more
   than 1 bug per component), and velocity of bug fixing is pretty high - over
   3 last days we had 21 incoming, 37 outcoming bugs. Any ideas on best
   formula for this?

Your thoughts, folks?

Thanks,
-- 
Mike Scherbakov
#mihgen

Follow ups