fuel-dev team mailing list archive
-
fuel-dev team
-
Mailing list archive
-
Message #00539
Re: Fuel 4.1 Code Freeze Status
+1
On Tue, Feb 25, 2014 at 8:17 AM, Mike Scherbakov
<mscherbakov@xxxxxxxxxxxx>wrote:
> A few more things were nailed down during these hours.
>
> I've moved https://bugs.launchpad.net/fuel/+bug/1284261 to 5.0, I hope no
> objections to it.
>
> OpenVSwitch with bonding sometimes stops accepting ARPs<https://bugs.launchpad.net/bugs/1272842> -
> Critical, but looks like we can't configure LACP on our switches.
> Active-backup mode works fine.
> OSError: [Errno 13] Permission denied: for murano dashboard<https://bugs.launchpad.net/bugs/1282613> -
> should be already fixed by package update, waiting for someone to confirm
> Murano has too open dirs (o+w) <https://bugs.launchpad.net/bugs/1284574> -
> security issue. Waiting for patches from Murano team
> Glance Error: Could not find filesystem_store_datadir in configuration
> options. <https://bugs.launchpad.net/bugs/1284236> - waiting from Matt
> more details on this issue, but looks like it low-priority glance caching
> issue
>
> I believe we can call for code freeze for all components except Murano. It
> means that we will still need to merge trivial changes into Murano DEB
> specs, and start accepting testing of Murano only after it is done.
> For all other pieces of Fuel I believe we can start acceptance testing.
>
> Any objections?
>
>
> On Tue, Feb 25, 2014 at 3:42 PM, Mike Scherbakov <mscherbakov@xxxxxxxxxxxx
> > wrote:
>
>> Folks,
>> few more things were tested and merged. Please pay high attention to
>> every new bug created now, and try to triage immediately - we need to know
>> whether it's low priority and can be deferred to 5.0 or critical, which
>> must be addressed in 4.1.
>>
>> *We are one step away from calling for a code-freeze.*
>> Largest thing to verify is kernel 3.10 (
>> https://bugs.launchpad.net/fuel/+bug/1263072,
>> https://bugs.launchpad.net/fuel/+bug/1282493)
>>
>> Needs to be triaged/try/comments provided:
>> https://bugs.launchpad.net/fuel/+bug/1284092
>> https://bugs.launchpad.net/fuel/+bug/1284236
>> https://bugs.launchpad.net/fuel/+bug/1284177
>>
>> Update about bonding is needed from Andrey:
>> https://bugs.launchpad.net/fuel/+bug/1272842
>>
>> Murano-related issues:
>> https://bugs.launchpad.net/fuel/+bug/1282613 - Critical
>> https://bugs.launchpad.net/fuel/+bug/1284574
>>
>> Other:
>> https://bugs.launchpad.net/fuel/+bug/1284571 - slow getting of master
>> IP. Let's discuss if it's Ok to merge in 4.1.
>>
>> Thanks,
>>
>>
>> On Tue, Feb 25, 2014 at 2:39 PM, Aleksey Kasatkin <akasatkin@xxxxxxxxxxxx
>> > wrote:
>>
>>> >>> #1283805 In fuelmenu, if you set IP for master, static pool starts
>>> >>> from same IP -- merged,
>>> This particular problem is fixed, ticket can be closed.
>>> Andrey pointed another problem:
>>> https://bugs.launchpad.net/fuel/+bug/1283805/comments/11
>>> that can be discussed within separate ticket.
>>>
>>>
>>> Aleksey Kasatkin
>>>
>>> S. Software Developer | Mirantis, Inc. | http://www.mirantis.com
>>> cell: +380938330852 | skype: alexeyk_ru
>>>
>>>
>>> On Tue, Feb 25, 2014 at 8:44 AM, Andrew Woodward <awoodward@xxxxxxxxxxxx
>>> > wrote:
>>>
>>>> I agree kernel-lt-firmware and kernel-lt-headers conflict, headers can
>>>> only be installed by the package section because it has deps that it won't
>>>> resolve otherwise, but kernel-lt wont replace kernel in that section, hence
>>>> the hokey adding it removing the ones we don't want and double checking we
>>>> have the ones we do.
>>>>
>>>> Created https://bugs.launchpad.net/fuel/+bug/1284482 to track defect
>>>>
>>>>
>>>> On Mon, Feb 24, 2014 at 9:57 PM, Matthew Mosesohn <
>>>> mmosesohn@xxxxxxxxxxxx> wrote:
>>>>
>>>>> I'll test the updated CentOS kernel for you today and review.
>>>>>
>>>>> I see why you had to do the ugly hack for kernel vs kernel-ml, and
>>>>> normally this is handled via "conflicts" or "obsoletes" flags. I know
>>>>> we can't put both kernels in the same repo with obsoletes flag, but
>>>>> maybe we can make it blend with conflicts instead. If this code
>>>>> works, let's ship it for 4.1 since we're down to the wire, but I'd
>>>>> like to refactor it into something a little less hackish and doesn't
>>>>> make systems complain.
>>>>>
>>>>> On Tue, Feb 25, 2014 at 9:40 AM, Andrew Woodward <
>>>>> awoodward@xxxxxxxxxxxx> wrote:
>>>>> > https://review.openstack.org/#/c/76090/ for fuel-web to convert
>>>>> names from
>>>>> > kernel_ml to kernel_lt
>>>>> >
>>>>> > https://review.openstack.org/#/c/76089/ to fix the package names
>>>>> and crazy
>>>>> > amount of work that is required to effectively get anaconda to
>>>>> change the
>>>>> > kernel before it finishes.
>>>>> >
>>>>> > https://review.openstack.org/76092 to fix the rpm requires and
>>>>> should be
>>>>> > merged after OSCI has all packages.
>>>>> >
>>>>> > Andrew.
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Mon, Feb 24, 2014 at 8:41 PM, Dmitry Borodaenko
>>>>> > <dborodaenko@xxxxxxxxxxxx> wrote:
>>>>> >>
>>>>> >> Team,
>>>>> >>
>>>>> >> We are almost ready to announce code freeze for 4.1. Unfortunately,
>>>>> we
>>>>> >> couldn't merge everything that we need today, so we can't freeze
>>>>> just
>>>>> >> yet. The good news is that we didn't find any major regressions as
>>>>> of
>>>>> >> ISO #195, and there is only a handful of problems that we still need
>>>>> >> to address:
>>>>> >>
>>>>> >> 1) Bonding
>>>>> >> 2) Kernel 3.10 for CentOS
>>>>> >> 3) Post-deploy orchestration workaround
>>>>> >>
>>>>> >> I believe that other outstanding issues are not critical enough to
>>>>> be
>>>>> >> considered release blockers. If you know of any other bugs that must
>>>>> >> be fixed in 4.1, please speak up now. Otherwise, I propose a soft
>>>>> code
>>>>> >> freeze: lets not merge any other changes except fixes for the above
>>>>> >> three issues, and declare code freeze as soon as these are fixed.
>>>>> >>
>>>>> >> Bonding:
>>>>> >>
>>>>> >> There was a lot of confusion today about #1272842 (OpenVSwitch with
>>>>> >> bonding sometimes stops accepting ARPs). We thought we have a way to
>>>>> >> reliably reproduce this bug, but all we found was a lot of problems
>>>>> >> with our test methodology for NIC bonding, and a real and easily
>>>>> fixed
>>>>> >> bug #1284384 (Remove balance-tcp bond mode option). Our conclusion
>>>>> so
>>>>> >> far is that bonding isn't going to work in our devops/kvm based test
>>>>> >> environment, and we will need a real switch with LACP to have
>>>>> another
>>>>> >> go at trying to reproduce the bonding/ARP problem. If that is the
>>>>> case
>>>>> >> and we can't really reproduce #1272842 tomorrow, I propose that we
>>>>> fix
>>>>> >> #1284384 and leave #1272842 as a known limitation.
>>>>> >>
>>>>> >> Kernel 3.10 for CentOS
>>>>> >>
>>>>> >> Andrew's fuel-library patch was merged prematurely (before the
>>>>> >> required kernel rpm's where created and added to the package
>>>>> >> repositories). Andrew is close to getting his Kickstart script
>>>>> changes
>>>>> >> work with the new kernel-lt packages, but unfortunately the new
>>>>> >> packages still miss the matching firmware binary package, he had to
>>>>> >> download that package from the upstream site to manually test his
>>>>> >> changes. I think we need some close coordination between Andrew,
>>>>> Matt,
>>>>> >> and OSCI team tomorrow morning Pacific time to tie all loose ends
>>>>> >> here: we need the firmware package from OSCI, and it would be very
>>>>> >> nice if Matt could review Andrew's fixes before we merge an updated
>>>>> >> version of them.
>>>>> >>
>>>>> >> Post-deploy orchestration workaround
>>>>> >>
>>>>> >> There's a -1 from QA on https://review.openstack.org/#/c/75389/ ,
>>>>> it
>>>>> >> can't be merged until that is resolved. There's hope that this was a
>>>>> >> one-off test failure unrelated to the code change: Aleksandr Didenko
>>>>> >> commented that at least the /etc/hosts part worked fine, although he
>>>>> >> wasn't able to check the radosgw side of the fix. If that's the
>>>>> case,
>>>>> >> we should be able to merge this tomorrow.
>>>>> >>
>>>>> >> Other critical and high priority bugs:
>>>>> >>
>>>>> >> #1284002 Request for HA deployment -- the consensus this morning was
>>>>> >> this this bug report is invalid, I think we need a document on how
>>>>> to
>>>>> >> manually test Neutron, something similar to
>>>>> >> fuel-library/deployment/puppet/ceph/README.md, so that everyone can
>>>>> >> agree and what is and isn't supposed to work. having an OSTF test
>>>>> >> script helps, but is not enough, there should be a document explains
>>>>> >> the test steps, and may include checks that are not easily scripted
>>>>> >>
>>>>> >> #1263934 fuelmenu NTP settings prevent me from proceeding -- merged
>>>>> >>
>>>>> >> #1267431 Get rid of hardcoded "admin" tenant in puppet modules -- a
>>>>> >> short-term fix was merged, the rest should be postponed to 5.0
>>>>> >>
>>>>> >> #1283805 In fuelmenu, if you set IP for master, static pool starts
>>>>> >> from same IP -- merged, not sure if there's more work left for 5.0
>>>>> or
>>>>> >> this can be closed?
>>>>> >>
>>>>> >> #1283812 Stop deploy tasks fails if any node was inaccessible --
>>>>> >> doesn't look like this can be done in 4.1, unless a really safe and
>>>>> >> non-intrusive fix is proposed tomorrow
>>>>> >>
>>>>> >> #1284092 Instances can't get metadata and IP addresses -- didn't
>>>>> have
>>>>> >> time to triage, is this confirmed?
>>>>> >>
>>>>> >> #1284177 OS not erased from node after cluster is deleted -- a
>>>>> >> duplicate of #1283825?
>>>>> >>
>>>>> >> #1284236 Glance Error: Could not find filesystem_store_datadir in
>>>>> >> configuration options -- didn't have time to triage
>>>>> >>
>>>>> >> #1284261 Astute must compare a sets of UIDs when collect data from
>>>>> >> netprobe.py -- proposed fix is a simple one-liner, can this be done
>>>>> >> tomorrow?
>>>>> >>
>>>>> >> #1284270 Please, add notification for user of fuel-cli about custom
>>>>> >> settings -- I think this should be postpoed to 5.0
>>>>> >>
>>>>> >> #1284193 ImageNotFound: error opening image
>>>>> >> /var/lib/nova/instances/_base/ -- Nova bug (live migrations work but
>>>>> >> non-live migrations don't work with ephemeral RBD backend),
>>>>> postponed
>>>>> >> to 5.0
>>>>> >>
>>>>> >> --
>>>>> >> Dmitry Borodaenko
>>>>> >>
>>>>> >> --
>>>>> >> You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> >> "fuel-core-team" group.
>>>>> >> To unsubscribe from this group and stop receiving emails from it,
>>>>> send an
>>>>> >> email to fuel-core-team+unsubscribe@xxxxxxxxxxxx.
>>>>> >> For more options, visit
>>>>> >> https://groups.google.com/a/mirantis.com/groups/opt_out.
>>>>> >
>>>>> >
>>>>> > --
>>>>> > You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> > "fuel-core-team" group.
>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>> send an
>>>>> > email to fuel-core-team+unsubscribe@xxxxxxxxxxxx.
>>>>> > For more options, visit
>>>>> > https://groups.google.com/a/mirantis.com/groups/opt_out.
>>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "fuel-core-team" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to fuel-core-team+unsubscribe@xxxxxxxxxxxx.
>>>> For more options, visit
>>>> https://groups.google.com/a/mirantis.com/groups/opt_out.
>>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "fuel-core-team" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to fuel-core-team+unsubscribe@xxxxxxxxxxxx.
>>> For more options, visit
>>> https://groups.google.com/a/mirantis.com/groups/opt_out.
>>>
>>
>>
>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>
>
>
> --
> Mike Scherbakov
> #mihgen
>
> --
> You received this message because you are subscribed to the Google Groups
> "fuel-core-team" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fuel-core-team+unsubscribe@xxxxxxxxxxxx.
> For more options, visit
> https://groups.google.com/a/mirantis.com/groups/opt_out.
>
Follow ups
References