fuel-dev team mailing list archive

[Dmitry Borodaenko <dborodaenko@xxxxxxxxxxxx>]

1319046 is an upstream bug and there's already a fix available:
https://review.openstack.org/90644

We should add this patch to our cinder package.

On Wed, May 14, 2014 at 1:09 PM, Mike Scherbakov
<mscherbakov@xxxxxxxxxxxx> wrote:
>> If the teams not involved in correcting the HA issues can move on to
>> creating 4.1.1 (with 2013.2.3 support & HA fixes), 5.0.1 (with 2014.1.1
>> support and lower priority defect fixes) and working on blueprints for 5.1,
>> I think that’s a good idea so that we don’t lose velocity.
> David, yep, that's the idea.
>
> Dmitry, thanks. Should we move 1319106 to 5.1 then? Also, I bet we need your
> thoughts about https://bugs.launchpad.net/fuel/+bug/1319046.
>
> Thanks,
>
>
> On Wed, May 14, 2014 at 8:40 PM, Dmitry Borodaenko
> <dborodaenko@xxxxxxxxxxxx> wrote:
>>
>> 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
>
>
>
>
> --
> Mike Scherbakov
> #mihgen
>



-- 
Dmitry Borodaenko