fuel-dev team mailing list archive

[Dmitry Borodaenko <dborodaenko@xxxxxxxxxxxx>]

It turns out 1319106 was caused by having a cinder node in an
environment configured to use ceph for volumes, so I downgraded it to
low. I've posted a fix but I'm not sure it's worth merging this before
stable/5.0 is branched, this kind of configuration is a really low
priority corner case, most people using Ceph for volumes don't need
Cinder LVM nodes. We need to fix the test not to assign cinder roles
to nodes, too.

The only reason I originally set it to Critical is because the
exception I saw in the logs was the same I've seen in Nova where it
was caused by a different kind of bug that would unconditionally break
the rbd backend. I have confirmed that such bug is not present in
Cinder.

-DmitryB

On Wed, May 14, 2014 at 11:26 AM, Mike Scherbakov
<mscherbakov@xxxxxxxxxxxx> wrote:
> 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
> Wrong interface in dnsmasq.conf inside cobbler container
>
> High priority - 8 bugs
> HA. Nova-compute is down after destroying primary controller
> mcollective failed to upload image but error was deployment timed out
> [OSTF]After succesfull cleanup button 'run test' does not appear
> Cannot create bootable volume on CEPH backend for cinder
> keystone-manage db_sync failed on first controller in ha mode
> add stickiness=1 to neutron agents PM resources
> [UI] Node renaming issues
> 'list index out of range' error on group node disks configuration
>
> All of them are taken by engineers and being addressed.
>
> We need to think about two questions:
>
> 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
> 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.
> 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
>
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Dmitry Borodaenko