fuel-dev team mailing list archive

[Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx>]

There are 2 issues with glance:
1 - glance API needs filesystem_store_data setting added to
glance-api.conf (even though it's defined also in glance-cache.conf).
This is a non-fatal error and doesn't block normal usage. I proposed
https://review.openstack.org/76252 - a one line trivial fix

2 - /var/lib/glance/image-cache/{queue,invalid,incomplete} are set to
root:root ownership instead of glance:glance. I put an OSCI ticket in
to fix this. It is really the job of the package to set file ownership
and this one doesn't even make sense because
/var/lib/glance/image-cache (its parent dir) is glance:glance. OSCI
bug is https://mirantis.jira.com/browse/OSCI-1091 and I think it
should be marked a blocker, but it also is a one line fix for
glance-api post-install script.

On Tue, Feb 25, 2014 at 8:28 PM, Andrew Woodward <awoodward@xxxxxxxxxxxx> wrote:
> +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 - 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 - should be
>> already fixed by package update, waiting for someone to confirm
>> Murano has too open dirs (o+w) - security issue. Waiting for patches from
>> Murano team
>> Glance Error: Could not find filesystem_store_datadir in configuration
>> options. - 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.
>
>
> --
> 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.