[openstack-dev] [masakari] Change service-type from "ha" to "instance-ha"

[Bhor, Dinesh]

Hi Masakari team,


Below are the patches up for review to change the masakari service-type from 
“ha” to “instance-ha”:


openstack/python-masakariclient :

https://review.openstack.org/#/c/53/1


openstack/masakari-monitors :

https://review.openstack.org/#/c/536668/


openstack/masakari :

https://review.openstack.org/#/c/536653/1


openstack/service-types-authority :

https://review.openstack.org/#/c/534875/



We should go with below order to fix this issue:


  1.  Merge the python-masakariclient patch.
  2.  Release newer version of python-masakariclient library.
  3.  Bump the newer version of python-masakariclient to global-requirements.
 *   The requirements freeze is near (coming Friday at 23:59:59 UTC)
*   
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126475.html
  4.  Bot job will propose a patch in masakari-monitors to update the 
python-masakariclient version.
  5.  Merge the bot job proposed patch.
  6.  Merge the masakari-monitors service-type patch.
  7.  Merge the masakari service-type patch.
  8.  Merge openstack/service-types-authority patch with updated service-type 
“instance-ha”.


Please help to merge these patches asap.


Thank you,

Dinesh Bhor

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ALL][requirements] A freeze is coming and you should be prepared

[Matthew Thode]

Requirements is freezing Friday at 23:59:59 UTC so any last
global-requrements updates that need to get in need to get in now.

I'm afraid that my condition has left me cold to your pleas of mercy.

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Add scenario tests based on multiple cells environment

[中西 朋生]

Hello

This time we plan to post multiple patches. In order to put them together, we 
created BP
I posted a test verifying the operation of the existing Nova API in a 
multi-cell environment.
Please review.

  https://review.openstack.org/#/c/534116/


--
Tomotaka Nakanishi
E-Mail : nakanishi.tomot...@po.ntt-tx.co.jp


On 2017/11/23 3:58, Matt Riedemann wrote:

On 11/21/2017 2:37 AM, koshiya maho wrote:

Hi, all

Multiple cells (Nova-Cells-v2) is supported in Pike release.
It is necessary to confirm that existing APIs work appropriately in the 
multiple cells environment.
We will post multiple patches, so I created BluePrint[1] to make it easier to 
keep track of those patches.
Please check the contents and approve it.

[1] 
https://blueprints.launchpad.net/nova/+spec/add-multiple-cells-scenario-tests

Best regards,
--
Maho Koshiya
E-Mail : koshiya.m...@po.ntt-tx.co.jp



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



We don't really need a blueprint for this work. It would be good to know what 
gaps in existing testing you think exist. And where do you plan on implementing 
these tests? In the nova/tests/functional tree or somewhere else? We already 
have a lot of tests which are using a CellDatabase fixture which allow us to 
create multiple cell mappings for tests in the API.

If you're considering Tempest, tests there wouldn't really be appropriate 
because to the end user of the API, they should have no idea if they are 
talking to a cloud with multiple cells or not, since it's really a deployment 
issue.

What we don't have today in our CI testing, and that we need someone to work 
on, is running a devstack multi-node setup with at least two cells. This likely 
requires some work in the devstack-gate repo to configure devstack per node to 
tell it which cell it is.

I encourage you to bring this up in a weekly cells v2 meeting for further 
discussion:

http://eavesdrop.openstack.org/#Nova_Cellsv2_Meeting




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] FFE request for node rescue feature

[Shivanand Tendulker]

Hi

The rescue feature [1] is an high priority for ironic in Queens. The spec
for the same was merged in Newton. This feature is necessary for users that
lose regular access to their machine (e.g. lost passwords).

Landing node rescue feature late in the cycle will lead to less time being
available for testing, with a risk that the feature being released with
defects. The code changes are fairly isolated from existing code to ensure
it does not cause any regression. The Ironic side rescue code patches are
all in review [2], and are now are getting positive reviews or minor
negative feedback.

dtantsur and TheJulia have kindly agreed to review the same during the FFE
window.

[1]
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/implement-rescue-mode.html
[2]
https://review.openstack.org/#/q/topic:bug/1526449+(status:open+AND+project:openstack/ironic)

Thanks and Regards,
Shiv (stendulker)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Jeremy Stanley]

On 2018-01-22 15:04:31 + (+), Graham Hayes wrote:
> On 19/01/18 16:27, Andrea Frittoli wrote:
[...]
> > it is possible to mark tests so that team may require a +1 from
> > interop/qa when specific tests are modified.
> 
> Is there? AFAIK gerrit does not do per file path permissions, so
> unless we have a job that just checks the votes on a patch, and
> passes or fails if a test changes (which would be awful for the
> teams) we cannot do that.
[...]

I read that as implying that it's possible _culturally_ to add code
comments or similar to remind reviewers that they need to seek
additional feedback under certain conditions. Just because a rule
can't be blindly enforced with some technological solution like CI
jobs or review system ACLs doesn't mean it's impossible. It does
however almost certainly mean more work for (and an inevitable
increase in mistakes made by) already overburdened reviewers.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] PTL Election Season

[Ed Leafe]

On Jan 22, 2018, at 5:09 PM, Matt Riedemann  wrote:

> To anyone that cares, I don't plan on running for Nova PTL again for the 
> Rocky release. Queens was my fourth tour and it's definitely time for someone 
> else to get the opportunity to lead here. I don't plan on going anywhere and 
> I'll be here to help with any transition needed assuming someone else (or a 
> couple of people hopefully) will run in the election. It's been a great 
> experience and I thank everyone that has had to put up with me and my 
> obsessive paperwork and process disorder in the meantime.

I still don't understand how anyone could do what you have done over these past 
two years and not a) had a stress-induced heart attack or b) gotten divorced.

Thanks for the hard work!

-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][l3][flavors][floatingip]

[Takashi Yamamoto]

a floating-ip is associated to a router only if it's associated to a fixed-ip.
consider the case where there are two routers sharing a public network.

On Tue, Jan 23, 2018 at 11:09 AM, Bhatia, Manjeet S
 wrote:
> Hi Neutrinos,
>
>
>
> I am working on L3 flavors driver implementation for ODL backend, In l3
> Flavor’s driver there is need to fetch flavors id on floatingip operations,
>
> So that if floatingip is not for association with router of that flavor,
> driver can ignore the operation and return, but I noticed there’s router_id
>
> None In floatingip payload sent to driver in networking-odl by neutron.
>
>
>
> What I did was
>
>
>
> 1.   Create an router of xyz flavor.
>
> 2.   Added public-subnet interface to that router.
>
> 3.   Created floatingip on that public network.
>
>
>
> I see None router_id being sent in payload [a]. for floatingip operation. I
> am not sure if this is intended, I think it is a bug otherwise I don’t see
>
> Other way of discarding floating ip operation by l3 flavors driver if it is
> not gonna be associated with router of that flavor.
>
>
>
>
>
> [a]. http://paste.openstack.org/show/646543/
>
>
>
>
>
> Thanks and Regards !
>
> Manjeet Singh Bhatia
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [zaqar] Not run for PTL

[Fei Long Wang]

Hi team,

I have been working on Zaqar for more than 4 years and serving the PTL
for the past 5 cycles. I don't plan to run for Zaqar PTL again for the
Rocky release. I think it's time for somebody else to lead the team for
next milestone. It has been a great experience for me and thank you for
all the support from the team and the whole community. I will still be
around for sure. Thank you.

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Unstable API in cloudci

[Fei Long Wang]

Sorry, wrong mail list.


On 23/01/18 15:14, Fei Long Wang wrote:
> Hi team,
>
> I think it's important to highlight this issue because it's affecting
> the whole team now. Recently (basically after the holiday or after the
> meltdown patching), we're experiencing an unstable cloudci. When you
> deploy a new cloudci env, you will see some random 500 or 503 error from
> different services. And so far, based on our investigation, it's caused
> by Keystone, and Keystone is experiencing a weird IO error. Now it's
> basically blocking Magnum and Octavia testing. We need to put some
> effort on this.

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Unstable API in cloudci

[Fei Long Wang]

Hi team,

I think it's important to highlight this issue because it's affecting
the whole team now. Recently (basically after the holiday or after the
meltdown patching), we're experiencing an unstable cloudci. When you
deploy a new cloudci env, you will see some random 500 or 503 error from
different services. And so far, based on our investigation, it's caused
by Keystone, and Keystone is experiencing a weird IO error. Now it's
basically blocking Magnum and Octavia testing. We need to put some
effort on this.


-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][l3][flavors][floatingip]

[Bhatia, Manjeet S]

Hi Neutrinos,

I am working on L3 flavors driver implementation for ODL backend, In l3 
Flavor's driver there is need to fetch flavors id on floatingip operations,
So that if floatingip is not for association with router of that flavor, driver 
can ignore the operation and return, but I noticed there's router_id
None In floatingip payload sent to driver in networking-odl by neutron.

What I did was


1.   Create an router of xyz flavor.

2.   Added public-subnet interface to that router.

3.   Created floatingip on that public network.

I see None router_id being sent in payload [a]. for floatingip operation. I am 
not sure if this is intended, I think it is a bug otherwise I don't see
Other way of discarding floating ip operation by l3 flavors driver if it is not 
gonna be associated with router of that flavor.


[a]. http://paste.openstack.org/show/646543/


Thanks and Regards !
Manjeet Singh Bhatia


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] PTL Election Season

[Alex Xu]

Matt, thanks for your leading and help over the past years! Your obsessive
paperwork is really helpful and I appreciate for that.

2018-01-23 7:09 GMT+08:00 Matt Riedemann :

> On 1/15/2018 11:04 AM, Kendall Nelson wrote:
>
>> Election details: https://governance.openstack.org/election/
>>
>> Please read the stipulations and timelines for candidates and electorate
>> contained in this governance documentation.
>>
>> Be aware, in the PTL elections if the program only has one candidate,
>> that candidate is acclaimed and there will be no poll. There will only be a
>> poll if there is more than one candidate stepping forward for a program's
>> PTL position.
>>
>> There will be further announcements posted to the mailing list as action
>> is required from the electorate or candidates. This email is for
>> information purposes only.
>>
>> If you have any questions which you feel affect others please reply to
>> this email thread.
>>
>>
> To anyone that cares, I don't plan on running for Nova PTL again for the
> Rocky release. Queens was my fourth tour and it's definitely time for
> someone else to get the opportunity to lead here. I don't plan on going
> anywhere and I'll be here to help with any transition needed assuming
> someone else (or a couple of people hopefully) will run in the election.
> It's been a great experience and I thank everyone that has had to put up
> with me and my obsessive paperwork and process disorder in the meantime.
>
> --
>
> Thanks,
>
> Matt
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] PTL Election Season

[Ghanshyam Mann]

On Tue, Jan 23, 2018 at 4:39 AM, Matt Riedemann  wrote:
> On 1/15/2018 11:04 AM, Kendall Nelson wrote:
>>
>> Election details: https://governance.openstack.org/election/
>>
>> Please read the stipulations and timelines for candidates and electorate
>> contained in this governance documentation.
>>
>> Be aware, in the PTL elections if the program only has one candidate, that
>> candidate is acclaimed and there will be no poll. There will only be a poll
>> if there is more than one candidate stepping forward for a program's PTL
>> position.
>>
>> There will be further announcements posted to the mailing list as action
>> is required from the electorate or candidates. This email is for information
>> purposes only.
>>
>> If you have any questions which you feel affect others please reply to
>> this email thread.
>>
>
> To anyone that cares, I don't plan on running for Nova PTL again for the
> Rocky release. Queens was my fourth tour and it's definitely time for
> someone else to get the opportunity to lead here. I don't plan on going
> anywhere and I'll be here to help with any transition needed assuming
> someone else (or a couple of people hopefully) will run in the election.
> It's been a great experience and I thank everyone that has had to put up
> with me and my obsessive paperwork and process disorder in the meantime.

Thanks a lot Matt for all your hard work during day and night
(accommodating almost all the TZ ). One of the best leadership i have
experience and learnt a lot.  Your activeness and help always make
sure things are completed as planned.

-gmann

>
> --
>
> Thanks,
>
> Matt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] PTL Election Season

[Fei Long Wang]

Matt, thank you for all you have done for Nova. It's a good journey to
work with you in past 7 years. And I'm looking forward to meeting you in
next summit.


On 23/01/18 12:09, Matt Riedemann wrote:
> On 1/15/2018 11:04 AM, Kendall Nelson wrote:
>> Election details: https://governance.openstack.org/election/
>>
>> Please read the stipulations and timelines for candidates and
>> electorate contained in this governance documentation.
>>
>> Be aware, in the PTL elections if the program only has one candidate,
>> that candidate is acclaimed and there will be no poll. There will
>> only be a poll if there is more than one candidate stepping forward
>> for a program's PTL position.
>>
>> There will be further announcements posted to the mailing list as
>> action is required from the electorate or candidates. This email is
>> for information purposes only.
>>
>> If you have any questions which you feel affect others please reply
>> to this email thread.
>>
>
> To anyone that cares, I don't plan on running for Nova PTL again for
> the Rocky release. Queens was my fourth tour and it's definitely time
> for someone else to get the opportunity to lead here. I don't plan on
> going anywhere and I'll be here to help with any transition needed
> assuming someone else (or a couple of people hopefully) will run in
> the election. It's been a great experience and I thank everyone that
> has had to put up with me and my obsessive paperwork and process
> disorder in the meantime.
>

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] PTL Election Season

[Chen CH Ji]

Matt, really appreciate for your solid review and patience, learn a lot
from your help :)

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Matt Riedemann 
To: openstack-dev@lists.openstack.org
Date:   01/23/2018 07:10 AM
Subject:Re: [openstack-dev] [nova] PTL Election Season



On 1/15/2018 11:04 AM, Kendall Nelson wrote:
> Election details:
https://urldefense.proofpoint.com/v2/url?u=https-3A__governance.openstack.org_election_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=die3e3sesoQt82yq45Rfi5gtzP2xWKhKgCoJZ8ZLIu0=xfpbcenWsmihBXKpCuJ72FnE5x4TQYhNub_PukbF-gA=

>
> Please read the stipulations and timelines for candidates and electorate
> contained in this governance documentation.
>
> Be aware, in the PTL elections if the program only has one candidate,
> that candidate is acclaimed and there will be no poll. There will only
> be a poll if there is more than one candidate stepping forward for a
> program's PTL position.
>
> There will be further announcements posted to the mailing list as action
> is required from the electorate or candidates. This email is for
> information purposes only.
>
> If you have any questions which you feel affect others please reply to
> this email thread.
>

To anyone that cares, I don't plan on running for Nova PTL again for the
Rocky release. Queens was my fourth tour and it's definitely time for
someone else to get the opportunity to lead here. I don't plan on going
anywhere and I'll be here to help with any transition needed assuming
someone else (or a couple of people hopefully) will run in the election.
It's been a great experience and I thank everyone that has had to put up
with me and my obsessive paperwork and process disorder in the meantime.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=die3e3sesoQt82yq45Rfi5gtzP2xWKhKgCoJZ8ZLIu0=1UlkBaPmZzs054ut14Rv9UdruUis5BdYkcOjJ9bd4nc=




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] PTL Election Season

[Mohammed Naser]

> On Jan 22, 2018, at 6:46 PM, Jay S Bryant  wrote:
> 
> 
> 
>> On 1/22/2018 5:09 PM, Matt Riedemann wrote:
>>> On 1/15/2018 11:04 AM, Kendall Nelson wrote:
>>> Election details: https://governance.openstack.org/election/
>>> 
>>> Please read the stipulations and timelines for candidates and electorate 
>>> contained in this governance documentation.
>>> 
>>> Be aware, in the PTL elections if the program only has one candidate, that 
>>> candidate is acclaimed and there will be no poll. There will only be a poll 
>>> if there is more than one candidate stepping forward for a program's PTL 
>>> position.
>>> 
>>> There will be further announcements posted to the mailing list as action is 
>>> required from the electorate or candidates. This email is for information 
>>> purposes only.
>>> 
>>> If you have any questions which you feel affect others please reply to this 
>>> email thread.
>>> 
>> 
>> To anyone that cares, I don't plan on running for Nova PTL again for the 
>> Rocky release. Queens was my fourth tour and it's definitely time for 
>> someone else to get the opportunity to lead here. I don't plan on going 
>> anywhere and I'll be here to help with any transition needed assuming 
>> someone else (or a couple of people hopefully) will run in the election. 
>> It's been a great experience and I thank everyone that has had to put up 
>> with me and my obsessive paperwork and process disorder in the meantime.
>> 
> Matt,
> 
> Thanks for all you have done!  Many good things have been done during your 
> tour!
> 
> Jay
> 

+1

Matt, you’ve been an excellent PTL for the Nova project.  The work that you’ve 
helped lead with the the Nova team has improved our experience with operating 
Nova and made our lives easier.

Your constant reaching out with operators to make sure that the changes align 
with what we expect is great. 

You’ll still be around but I want to extend my personal thank you!

> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] py27 gate situation

[Brian Rosmaita]

Looks like something changed in a distro dependency over the weekend
and the glance py27 gate is failing.

I did a dist-upgrade in a new Ubuntu 16.04.3 vm, and was able to
reproduce the failures locally.  I'll continue looking, but it's EOD
where I am, so I wanted to make sure this info is available to the
people whose day is about to begin.  The failures are confined to the
py27 functional tests.  Unit tests pass, as do all the py35 tests.

The requirements team has merged a change making the cross-glance-py27
job non-voting:
https://review.openstack.org/#/c/536082/
Thus, this issue isn't holding up requirements changes, but it's still
pretty urgent for us to figure out because I don't like us running
around naked with respect to requirements changes that could affect
glance running under py27.

Here's what I think we should do:

(1) Sean has had a patch up for a while separating out the unit tests
from the functional tests.  I think it's a good idea.  If you are
aware of a reason why they should NOT be separated, please comment on
the patch:
https://review.openstack.org/#/c/474816/
I'd like to merge this soon so we can at least restore py27 unit tests
to the requirements gate.  We can always revert if it turns out that
there is a really good reason for not separating out the functional
tests.

(2) I've got a patch up that depends on Sean's patch and restores the
functional test gate jobs to the glance .zuul.yaml file (though it
makes the py27 functional tests non-voting):
https://review.openstack.org/#/c/536630/

(3) Continue to work on https://bugs.launchpad.net/glance/+bug/1744824
to figure out why the py27 functional tests are failing.  As far as I
can tell, it looks like a distro package issue.


thanks,
brian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] PTL Election Season

[Jay S Bryant]

On 1/22/2018 5:09 PM, Matt Riedemann wrote:

On 1/15/2018 11:04 AM, Kendall Nelson wrote:

Election details: https://governance.openstack.org/election/

Please read the stipulations and timelines for candidates and 
electorate contained in this governance documentation.


Be aware, in the PTL elections if the program only has one candidate, 
that candidate is acclaimed and there will be no poll. There will 
only be a poll if there is more than one candidate stepping forward 
for a program's PTL position.


There will be further announcements posted to the mailing list as 
action is required from the electorate or candidates. This email is 
for information purposes only.


If you have any questions which you feel affect others please reply 
to this email thread.




To anyone that cares, I don't plan on running for Nova PTL again for 
the Rocky release. Queens was my fourth tour and it's definitely time 
for someone else to get the opportunity to lead here. I don't plan on 
going anywhere and I'll be here to help with any transition needed 
assuming someone else (or a couple of people hopefully) will run in 
the election. It's been a great experience and I thank everyone that 
has had to put up with me and my obsessive paperwork and process 
disorder in the meantime.



Matt,

Thanks for all you have done!  Many good things have been done during 
your tour!


Jay


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] PTL Election Season

[Matt Riedemann]

On 1/15/2018 11:04 AM, Kendall Nelson wrote:

Election details: https://governance.openstack.org/election/

Please read the stipulations and timelines for candidates and electorate 
contained in this governance documentation.


Be aware, in the PTL elections if the program only has one candidate, 
that candidate is acclaimed and there will be no poll. There will only 
be a poll if there is more than one candidate stepping forward for a 
program's PTL position.


There will be further announcements posted to the mailing list as action 
is required from the electorate or candidates. This email is for 
information purposes only.


If you have any questions which you feel affect others please reply to 
this email thread.




To anyone that cares, I don't plan on running for Nova PTL again for the 
Rocky release. Queens was my fourth tour and it's definitely time for 
someone else to get the opportunity to lead here. I don't plan on going 
anywhere and I'll be here to help with any transition needed assuming 
someone else (or a couple of people hopefully) will run in the election. 
It's been a great experience and I thank everyone that has had to put up 
with me and my obsessive paperwork and process disorder in the meantime.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][oslo.log] JSON logs are missing the request ID

[Doug Hellmann]

Excerpts from Saverio Proto's message of 2018-01-22 18:45:15 +0100:
> Hello Doug,
> 
> in the extra session I see just {"project": "unknown", "version": "unknown"}
> 
> here a full line from nova-api:
> 
> {"thread_name": "MainThread", "extra": {"project": "unknown", "version":
> "unknown"}, "process": 31142, "relative_created": 3459415335.4091644,
> "module": "wsgi", "message":
> "2001:xxx::8100::80,2001:xxx::81ff::b0 \"GET
> /v2/64b5b50eb21d4efe9783eb1d81a9ec65/os-services HTTP/1.1\" status: 200
> len: 1812 time: 0.1813300", "hostname": "nova-0", "filename": "wsgi.py",
> "levelno": 20, "lineno": 555, "asctime": "2018-01-22 18:37:02,312",
> "msg": "2001:xxx::8100::80,2001:xxx::81ff::b0 \"GET
> /v2/64b5b50eb21d4efe9783eb1d81a9ec65/os-services HTTP/1.1\" status: 200
> len: 1812 time: 0.1813300", "args": [], "process_name": "MainProcess",
> "name": "nova.osapi_compute.wsgi.server", "thread": 140414249163824,
> "created": 1516642622.312235, "traceback": null, "msecs":
> 312.23511695861816, "funcname": "handle_one_response", "pathname":
> "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", "levelname": "INFO"}

It looks like you're running into a limitation of the older version of
the library where the context was only logged from openstack source
code. This particular log message is coming from the eventlet library.

Try running the script below and saving the output to a pastebin.

Under the newton version of oslo.log, I get
http://paste.openstack.org/show/650566/ and under the queens version I
get http://paste.openstack.org/show/650569/ which shows me that the
"extra" handling is working more or less the same way but the "context"
handling is improved in the newer version (lots of the values are null
because I don't fully set up the context, but the request_id field has a
valid value).

Doug


#!/usr/bin/env python

from __future__ import print_function

import logging

from oslo_context import context
from oslo_log import formatters, log


ch = logging.StreamHandler()
ch.setLevel(logging.DEBUG)

formatter = formatters.JSONFormatter()
ch.setFormatter(formatter)

LOG = logging.getLogger()
LOG.setLevel(logging.DEBUG)
LOG.addHandler(ch)

ctx = context.RequestContext(request_id='the-request-id')

LOG.debug('without extra')
print()

LOG.debug('with extra', extra={'context': ctx})
print()

log.getLogger().debug('via KeywordArgumentAdapter', context=ctx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] FFE request for node traits

[Mark Goddard]

The node traits feature [1] is an essential priority for ironic in Queens,
and is an important step in the continuing evolution of scheduling enabled
by the placement API. Traits will allow us to move away from
capability-based scheduling. Capabilities have several limitations for
scheduling including depending on filters in nova-scheduler rather than
allowing placement to select matching hosts. Several upcoming features
depend on traits [2].

Landing node traits late in the cycle will lead to less time being
available for testing, with a risk that the feature is release with
defects. There are changes at most major levels in the code except the
drivers, but these are for the most part fairly isolated from existing
code. The current issues with the grenade CI job mean that upgrade code
paths are not being exercised frequently, and could lead to additional
test/bug fix load on the team later in the cycle. The node traits code
patches are all in review [3], and are now generally getting positive
reviews or minor negative feedback.

rloo and TheJulia have kindly offered to review during the FFE window.

[1]
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/node-traits.html
[2]
https://review.openstack.org/#/c/504952/7/specs/approved/config-template-traits.rst
[3] https://review.openstack.org/#/q/topic:bug/1722194+(status:open)

Thanks,
Mark (mgoddard)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Keystone Team Update - Week of 15 January 2018

[William M Edmonds]

welcome, Gage! Congrats!

Boris, Steve, Brant, Brad... you are and will be missed.


W. Matthew Edmonds
Sr. Software Engineer, IBM Power Systems
Email: edmon...@us.ibm.com
Phone: (919) 543-7538 / Tie-Line: 441-7538



From:   Colleen Murphy 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   01/19/2018 12:55 PM
Subject:[openstack-dev] [keystone] Keystone Team Update - Week of 15
January 2018



# Keystone Team Update - Week of 15 January 2018

## News

### Core team changes

We added a new core reviewer! Thanks Gage Hugo for all your hard work
and for stepping up to take on more responsibility!

We also lost some core members: Boris Bobrov, Steve Martinelli, Brant
Knudson and Brad Topol have stepped down from core membership after
having made enormous contributions over the years. We're grateful to
them for everything they've done to make keystone better and welcome
them back any time.

### Proposed community goals for Rocky

There are five community goals[1][2][3][4][5] proposed for Rocky that
are under discussion. In the meeting this week we had some confusion
and conerns over whether the proposed goal about pagination links[3]
would apply to us. We don't paginate anything in keystone, so the goal
wouldn't apply to us. The one that would potentially apply to keystone
is about mutable configuration[5]. If you have thoughts on any of
these potential community goals, including whether the team has the
capacity to take on this work, make your voice heard on the reviews.

### PTG Planning

We still need to put some thought into our agenda for the PTG. Add
your ideas to the etherpad[6] and also add your name if you're going
to be attending so that we can organize a team dinner.

I noticed that no one requested a BM/VM room for the cross-project
days of the PTG[7]. If we want to organize discussions with those
teams we might want to start thinking about that now, but we will be
able to book rooms spontaneously if we want to.

[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_513875=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg=WZyK2gn2PyQ8sv1VSFd0wmEw1KZMyiZucOwFiQVLhy4=1DNtvlP9hEpIKo3pCN68D0H4y4F46EqgJGWo4yGs_x8=

[2]
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_532361=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg=WZyK2gn2PyQ8sv1VSFd0wmEw1KZMyiZucOwFiQVLhy4=JHB0pEqz9O1eVNcmGvRbRrbhuqEt8ZYG8DwwU59szN0=

[3]
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_532627=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg=WZyK2gn2PyQ8sv1VSFd0wmEw1KZMyiZucOwFiQVLhy4=J8PVKWbG2l-pwPXNV9WGgjmRpDYPIxkE7r-NsNCr6DA=

[4]
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_533544=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg=WZyK2gn2PyQ8sv1VSFd0wmEw1KZMyiZucOwFiQVLhy4=G76CnD1Jab84Ng4YY3YDClK5_tuxwL5SIAmq7ZOpess=

[5]
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_534605=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg=WZyK2gn2PyQ8sv1VSFd0wmEw1KZMyiZucOwFiQVLhy4=2sGC1vqKoMD5TPi6CepPxg_Px2gF0udR01_JRoze6IU=

[6]
https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_keystone-2Drocky-2Dptg=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg=WZyK2gn2PyQ8sv1VSFd0wmEw1KZMyiZucOwFiQVLhy4=AK0hgcNrTZn050SWudyNJMXhB3nq5Hvm1YK8EP_TIGU=

[7]
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_pipermail_openstack-2Ddev_2018-2DJanuary_126335.html=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg=WZyK2gn2PyQ8sv1VSFd0wmEw1KZMyiZucOwFiQVLhy4=ojAJr5Ffr8mZcDP98KavDm9eEI4WEKflLHDa6CTETbI=


## Recently Merged Changes

Search query:
https://urldefense.proofpoint.com/v2/url?u=https-3A__goo.gl_hdD9Kw=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg=WZyK2gn2PyQ8sv1VSFd0wmEw1KZMyiZucOwFiQVLhy4=46ojFnkizMRWuTYLT_r1aH2xUaWypLtFZWh08wDI2uM=


We merged 38 changes this week. Lots of these were major stepping
stones for our new features.

## Changes that need Attention

Search query:
https://urldefense.proofpoint.com/v2/url?u=https-3A__goo.gl_h9knRA=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=uPMq7DJxi29v-9CkM5RT0pxLlwteWvldJgmFhLURdvg=WZyK2gn2PyQ8sv1VSFd0wmEw1KZMyiZucOwFiQVLhy4=xeWa9B-DRwjQ781pFfjgfna8ogWhj3TYKU8NtF61HZA=


There are 55 changes that are passing CI, not in merge conflict, have
no negative reviews and aren't proposed by bots. Please prioritize
reviews for python-keystoneclient and our major feature initiatives
(see below).

## Milestone Outlook

Re: [openstack-dev] [ironic] Remove in-tree policy and config?

[Jim Rollenhagen]

Huge +1, I didn't realize this was in docs now. We can finally stop doing
it manually \o/


// jim

On Mon, Jan 22, 2018 at 7:45 AM, John Garbutt  wrote:

> Hi,
>
> While I was looking at the traits work, I noticed we still have policy and
> config in tree for ironic and ironic inspector:
>
> http://git.openstack.org/cgit/openstack/ironic/tree/etc/
> ironic/policy.json.sample
> http://git.openstack.org/cgit/openstack/ironic/tree/etc/
> ironic/ironic.conf.sample
> http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/policy.json
>
> And in a similar way:
> http://git.openstack.org/cgit/openstack/ironic-inspector/
> tree/policy.yaml.sample
> http://git.openstack.org/cgit/openstack/ironic-inspector/tree/example.conf
>
> There is an argument that says we shouldn't force operators to build a
> full environment to generate these, but this has been somewhat superseded
> by us having good docs:
>
> https://docs.openstack.org/ironic/latest/configuration/sample-config.html
> https://docs.openstack.org/ironic/latest/configuration/sample-policy.html
> https://docs.openstack.org/ironic-inspector/latest/
> configuration/sample-config.html
> https://docs.openstack.org/ironic-inspector/latest/
> configuration/sample-policy.html
>
> It could look something like this (but with the tests working...):
> https://review.openstack.org/#/c/536349
>
> What do you all think?
>
> Thanks,
> johnthetubaguy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Release-job-failures] Release of openstack/networking-ovn failed

[Sean McGinnis]

On Mon, Jan 22, 2018 at 08:42:05PM +, z...@openstack.org wrote:
> Build failed.
> 
> - release-openstack-python 
> http://logs.openstack.org/17/17fe24c0449ef2067ed7c7e0e51397711becef0d/release/release-openstack-python/1b3f482/
>  : POST_FAILURE in 7m 59s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
> 

This looks like a transient failure with an issue pulling packages from pypi.

http://logs.openstack.org/17/17fe24c0449ef2067ed7c7e0e51397711becef0d/release/release-openstack-python/1b3f482/job-output.txt.gz#_2018-01-22_20_41_09_050952

I will see if someone can reenqueue this to rerun the jobs, and it that is not
possible we can revert and recommit the release patch.

Sean

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Deadlines, feature freeze and exceptions

[Dmitry Tantsur]

Hi all!

We're near the end of the cycle. Here are some important dates to be mindful of:

Thu, Jan 25th - final Queens releases of python-ironicclient and 
python-ironic-inspector-client. Any features that land after that point will get 
to Rocky, no exceptions. Yes, even if the API itself lands in ironic in Queens.


Thu, Jan 25th - begin of the feature freeze for ironic and many other projects. 
No features should land after that date without getting a formal exception first 
- please pay attention when approving the patches. A procedure for a feature 
freeze exception is outlined below.


Fri, Feb 2nd - hard feature freeze. All features with an exception must land by 
this point. Starting with Monday and until the branching we only land bug fixes 
and documentation updates to master.


Thu, Feb 8th - final feature releases for all remaining projects and creation of 
stable/queens. At this point the feature freeze is lifted and master is opened 
for Rocky development.


Now, how to request a feature freeze exception. Please:

* Send a email to this mailing list, with [ironic] and FFE in its subject.
* Outline the reason why you think the feature should go to Queens, and what are 
the downsides. Keep in mind that no API additions will get client support after 
this Thursday.

* Evaluate and explain the risks of landing the feature so late in the cycle.
* Finally, please find at least two cores that agree to review your changes 
during the feature freeze window, and include their names. This is important, we 
don't need FFEs that won't get reviewed.


Happy hacking,
Dmitry

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] FFE - Requesting FFE for Routed Networks support.

[Dmitry Tantsur]

This FFE was approved on today's meeting. Please note that the deadline to 
merging it is Fri, Feb 2nd.


On 01/17/2018 10:54 AM, Harald Jensås wrote:

Requesting FFE for Routed Network support in networking-baremetal.
---


# Pros
--
With the patches up for review[7] we have a working ml2 agent;
__depends on neutron fix__; and mechanism driver combination that
enables support to bind ports on neutron routed networks.

Specifically we report the bridge_mappings data to neutron, which
enable the _find_candidate_subnets() method in neutron ipam[1] to
succeed in finding a candidate subnet available to the ironic node when
ports on routed segments are bound.

This functionality will allow users to take advantage of the
functionality added in DHCP Agent[2] which enables the DHCP agent to
service other subnets on the network via DHCP relay. For Ironic this
means we can support deploying nodes on a remote L3 network, e.g
different datacenter or different rack/rack-row.



# Cons
--
Integration with placement does not currently work.

Neutron uses Nova host-aggregates in combination with Placement.
Specifically hosts are added to a host-aggregate for segments based on
SEGMENT_HOST_MAPPING. Ironic nodes cannot currently be added to host-
aggregates in Nova. Because of this the following will appear in the
neutron logs when ironic-neutron agent is started:
RESP BODY: {"itemNotFound": {"message": "Compute host  could not be found.", "code": 404}}

Also the placement api cannot be used to find good candidate ironic
nodes with a baremetal port on the correct segment. This will have to be worked 
around by the operator via capabilities and flavor properties or manual 
additions to resource providers in placement.

Depending on the direction of other projects, neutron and nova, the way
placement will finally work is not certain.

Either the nova work [3] and [4], or a neutron change to use placement
only or a fallback to placement in neutron would be possible. In either
case there should be no need to change the networking-baremetal agent
or mechanism driver.


# Risks
---
Unless this bug[5] is fixed we might break the current baremetal
mechanism driver functionality. I have proposed a patch[6] to neutron
that fix the issue. In case no fix lands for this neutron bug soon we
should probably push these changes to Rocky.


# Core reviewers

Julia Kreger, Sam Betts




[1] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/ip
am_backend_mixin.py#n697
[2] https://review.openstack.org/#/c/468744/
[3] https://review.openstack.org/#/c/421009/
[4] https://review.openstack.org/#/c/421011/
[5] https://bugs.launchpad.net/neutron/+bug/1743579
[6] https://review.openstack.org/#/c/534449/
[7] https://review.openstack.org/#/q/project:openstack/networking-barem
etal





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][oslo.log] JSON logs are missing the request ID

[Saverio Proto]

Hello Doug,

in the extra session I see just {"project": "unknown", "version": "unknown"}

here a full line from nova-api:

{"thread_name": "MainThread", "extra": {"project": "unknown", "version":
"unknown"}, "process": 31142, "relative_created": 3459415335.4091644,
"module": "wsgi", "message":
"2001:xxx::8100::80,2001:xxx::81ff::b0 \"GET
/v2/64b5b50eb21d4efe9783eb1d81a9ec65/os-services HTTP/1.1\" status: 200
len: 1812 time: 0.1813300", "hostname": "nova-0", "filename": "wsgi.py",
"levelno": 20, "lineno": 555, "asctime": "2018-01-22 18:37:02,312",
"msg": "2001:xxx::8100::80,2001:xxx::81ff::b0 \"GET
/v2/64b5b50eb21d4efe9783eb1d81a9ec65/os-services HTTP/1.1\" status: 200
len: 1812 time: 0.1813300", "args": [], "process_name": "MainProcess",
"name": "nova.osapi_compute.wsgi.server", "thread": 140414249163824,
"created": 1516642622.312235, "traceback": null, "msecs":
312.23511695861816, "funcname": "handle_one_response", "pathname":
"/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", "levelname": "INFO"}

thank you

Saverio

On 22.01.18 15:33, Doug Hellmann wrote:
> Excerpts from Saverio Proto's message of 2018-01-21 18:09:03 +0100:
>> Hello,
>>
>> I figured out a bug is already open since a long time :(
>> https://bugs.launchpad.net/oslo.log/+bug/1564931
>>
>> And there is already a review:
>> https://review.openstack.org/#/c/367514/
>>
>> it looks like the review was not merged, and it went to abandoned
>> because of no progress on it for long time.
>>
>> I rebased that code on the current master:
>> https://review.openstack.org/536149
> 
> That patch is not needed on master.
> 
> We added the full context as a nested value under the "context" key when
> http://git.openstack.org/cgit/openstack/oslo.log/commit/oslo_log/formatters.py?id=1b012d0fc6811f00e032e52ed586fe37e157584d
> landed. That change was released as part of 3.35.0 and as the test in
> https://review.openstack.org/#/c/536164/ shows the request_id and
> global_request_id values are present in the output.
> 
> Before that change (and after, as part of our effort to maintain
> backwards compatibility) the values from the context were added to the
> "extra" section of the output message. That behavior is present in
> 
> master: 
> http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/formatters.py?h=master#n246
> pike: 
> http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/formatters.py?h=stable%2Fpike#n300
> ocata: 
> http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/formatters.py?h=stable%2Focata#n156
> 
> It also appears to be present for newton, the version you said you are
> using:
> 
> http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/formatters.py?h=newton-eol#n153
> 
> Have you looked at the "extras" section of the log output?
> 
> Could you provide some sample log output?
> 
> Doug
> 
>>
>> Saverio
>>
>> On 18.01.18 18:14, Doug Hellmann wrote:
>>> Excerpts from Doug Hellmann's message of 2018-01-18 11:45:28 -0500:
 Excerpts from Saverio Proto's message of 2018-01-18 14:49:21 +0100:
> Hello all,
>
> well this oslo.log library looks like a core thing that is used by
> multiple projects. I feel scared hearing that bugs opened on that
> project are probably just ignored.
>
> should I reach out to the current PTL of OSLO ?
> https://github.com/openstack/governance/blob/master/reference/projects.yaml#L2580
>
> ChangBo Guo are you reading this thread ? Do you think this is a bug or
> a missing feature ? And moreover is really nobody looking at these
> oslo.log bugs ?

 The Oslo team is small, but we do pay attention to bug reports. I
 don't think this issue is going to rise to the level of "drop what
 you're doing and help because the world is on fire", so I think
 Sean is just encouraging you to have a little patience.

 Please do go ahead and open a bug and attach (or paste into the
 description) an example of what the log output for your service looks
 like.

 Doug
>>>
>>> Earlier in the thread you mentioned running the newton versions of
>>> neutron and oslo.log. The newton release has been marked end-of-life
>>> and is not supported by the community any longer. You may find
>>> support from your vendor, but if you're deploying on your own we'll
>>> have to work something else out. If we determine that this is a bug
>>> in the newton version of the library I won't have any way to give
>>> you a new release because the branch is closed.
>>>
>>> It should be possible for you to update just oslo.log to a more
>>> recent (and supported), although to do so you would have to get the
>>> package separately or build your own and that may complicate your
>>> deployment.
>>>
>>> More recent versions of the JSON formatter change the structure of
>>> the data to include the entire context (including the request id)
>>> in a separate key.  Are you updating to newton as part of upgrading
>>> further 

Re: [openstack-dev] Many timeouts in zuul gates for TripleO

[Wesley Hayutin]

On Mon, Jan 22, 2018 at 6:55 AM, Or Idgar  wrote:

> Hi,
> Still having timeouts but now in tripleo-heat-templates experimental gates
> (tripleo-ci-centos-7-ovb-fakeha-caserver and tripleo-ci-centos-7-ovb-ha-
> tempest-oooq).
>
> see examples:
> http://logs.openstack.org/31/518331/23/experimental-
> tripleo/tripleo-ci-centos-7-ovb-fakeha-caserver/7502e82/
> http://logs.openstack.org/31/518331/23/experimental-
> tripleo/tripleo-ci-centos-7-ovb-ha-tempest-oooq/46e8e0d/
>
> Anyone have an idea what we can do to fix it?
>
> Thanks,
> Idgar
>
> On Sat, Jan 20, 2018 at 4:38 AM, Paul Belanger 
> wrote:
>
>> On Fri, Jan 19, 2018 at 11:23:45AM -0600, Ben Nemec wrote:
>> >
>> >
>> > On 01/18/2018 09:45 AM, Emilien Macchi wrote:
>> > > On Thu, Jan 18, 2018 at 6:34 AM, Or Idgar  wrote:
>> > > > Hi,
>> > > > we're encountering many timeouts for zuul gates in TripleO.
>> > > > For example, see
>> > > > http://logs.openstack.org/95/508195/28/check-tripleo/tripleo
>> -ci-centos-7-ovb-ha-oooq/c85fcb7/.
>> > > >
>> > > > rechecks won't help and sometimes specific gate is end successfully
>> and
>> > > > sometimes not.
>> > > > The problem is that after recheck it's not always the same gate
>> which is
>> > > > failed.
>> > > >
>> > > > Is there someone who have access to the servers load to see what
>> cause this?
>> > > > alternatively, is there something we can do in order to reduce the
>> running
>> > > > time for each gate?
>> > >
>> > > We're migrating to RDO Cloud for OVB jobs:
>> > > https://review.openstack.org/#/c/526481/
>> > > It's a work in progress but will help a lot for OVB timeouts on RH1.
>> > >
>> > > I'll let the CI folks comment on that topic.
>> > >
>> >
>> > I noticed that the timeouts on rh1 have been especially bad as of late
>> so I
>> > did a little testing and found that it did seem to be running more
>> slowly
>> > than it should.  After some investigation I found that 6 of our compute
>> > nodes have warning messages that the cpu was throttled due to high
>> > temperature.  I've disabled 4 of them that had a lot of warnings. The
>> other
>> > 2 only had a handful of warnings so I'm hopeful we can leave them active
>> > without affecting job performance too much.  It won't accomplish much
>> if we
>> > disable the overheating nodes only to overload the remaining ones.
>> >
>> > I'll follow up with our hardware people and see if we can determine why
>> > these specific nodes are overheating.  They seem to be running 20
>> degrees C
>> > hotter than the rest of the nodes.
>> >
>> Did tripleo-test-cloud-rh1 get new kernels applied for meltdown / spectre,
>> possible that is impacting performance too?
>>
>> -Paul
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Best regards,
> Or Idgar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
FYI.. we created a lp to track decommissioning the ovb jobs on rh1 and
moving them to third party ci.
Up for comments https://bugs.launchpad.net/tripleo/+bug/1744763
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] FFE nfs_ganesha integration

[Giulio Fidente]

hi,

I would like to request an FFE for the integration of nfs_ganesha, which 
will provide a better user experience to manila users


This work was slown down by a few factors:

- it depended on the migration of tripleo to the newer Ceph version 
(luminous), which happened during the queens cycle


- it depended on some additional functionalities to be implemented in 
ceph-ansible which were only recently been made available to tripleo/ci


- it proposes the addition of on an additional (and optional) network 
(storagenfs) so that guests don't need connectivity to the ceph frontend 
network to be able to use the cephfs shares


The submissions are on review and partially testable in CI [1]. If 
accepted, I'd like to reassign the blueprint [2] back to the queens 
cycle, as it was initially.


Thanks

1. https://review.openstack.org/#/q/status:open+topic:bp/nfs-ganesha
2. https://blueprints.launchpad.net/tripleo/+spec/nfs-ganesha
--
Giulio Fidente
GPG KEY: 08D733BA

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Andrea Frittoli]

On Mon, Jan 22, 2018 at 3:05 PM Graham Hayes  wrote:

>
>
> On 19/01/18 16:27, Andrea Frittoli wrote:
> >
> > Thanks for the summary!
> >
> > To be honest I don't see why this decision has to be difficult to take.
>
> I think the confusion comes from one thing being decided already, and
> now conflicting direction is being given to teams, without anyone
> updating the Governance repo.
>
> (It is not as if there was not plenty of warning, I have been raising it
> as an issue for over a year)
>
> > Nothing we decide today is written in stone and the main risk ahead of
> > us is to take
> > a decision that requires a lot of upfront work and that it ends up
> > providing no
> > significant benefit, or even making things worst in some aspect. So we
> > may try one way
> > today and if we hit some significant issue we can still change.
> >
> > TL;DR my preferred option would be number (2) - it's the least initial
> > effort, so the
> > least risk, and deciding for (2) now won't make it any difficult in the
> > future to switch
> > to option (1) or option (3). I'm not pushing back on (2), I just think
> > (1) is more convenient.
> > Details below each option.
> >
> >
> >
> > So far the patch proposes three options:
> >
> > 1) All trademark-related tests should go in the tempest repo, in
> > accordance
> >with the original resolution. This would mean that even projects
> > that have
> >never had tests in tempest would now have to add at least some of
> > their
> >black-box tests to tempest.
> >
> >
> > This option is a valid one, but I think it introduces too much extra
> > work and
> > testing complications for too little benefit.
>
> What it does do is *guarantee* that the InterOp suite will work, as it
> will be CI'd. I see these programs as important enough that we should CI
> the tooling used for them, but I seem to be in a minority.
>

Add-ons intreoperability tests will be CI'd for every change in Tempest as
long
as they are executed in a job that runs on every change in Tempest.

This can be achieve regardless of the location of the tests and having the
tests
in the Tempest tree is not by itself a guarantee that they will be executed
against
every change.



>
> >
> >
> > The value of this option is that centralizes tests used for the
> > Interop program
> > in a location where interop-minded folks from the QA team can
> > control them.
> >
> >
> > There are other ways this can be achieved - it is possible to mark tests
> > so that
> > team may require a +1 from interop/qa when specific tests are modified.
>
> Is there? AFAIK gerrit does not do per file path permissions, so unless
> we have a job that just checks the votes on a patch, and passes or fails
> if a test changes (which would be awful for the teams) we cannot do
> that.
>

If we really want to enforce having a vote from someone it may be tricky,
yes, but I don't think enforcement is what we need, rather awareness,
For governance and project-config patches reviewed always ask for a +1
from the project PTL where relevant, and add-on project reviewers could
do the same.

To help building awareness we could have automation in place to post a
comment to Gerrit, like we do for elastic recheck. We could do that
on every change to the plugin in the beginning and include  a link to the
interoperability recommendation to help reviewers in their job.


>
> >
> >
> > The
> > downside is that projects that so far have avoided having a
> > dependency on
> > tempest will now lose some control over the black-box tests that
> > they use for
> > functional and integration that would now also be used for trademark
> > certification.
> > There's also concern for the review bandwidth of the QA team - we
> > can't expect
> > the QA team to be continually responsible for an ever-growing list
> > of projects
> > and their trademark tests.
> >
> >
> > If we restrict to interop tests, the review bandwidth issue is probably
> > not so bad.
> > The QA team would have to request the domain knowledge required for
> proper
> > review from the respective teams anyways.
> >
> > There are other complications introduced though:
> >
> > - service clients and other common bits (config and so) would have to
> > move to
> >   Tempest since we cannot have tempest depend on plugins. But then
> modifying
> >   those common bits on Tempest side would risk to break non-interop
> tests.
> >   Solution for that is to make all those bits stable interfaces for
> plugins
>
> Is this not already the case? e.g. the neutron plugin uses the nova
> service client already.
>

What I was saying is that Tempest cannot depend on a Tempest plugin,
so service clients should be in Tempest. Which is absolutely fine, I'm was
just listing out the work that needs to be done if we move add-on
interoperability tests into Tempest.


>
> This would also help for the neutron plugin which is 

[openstack-dev] [masakari] Questions on masakari CLI for hosts and segments

[Waines, Greg]

masakari segment-create --name segment-1 --recovery-method auto --service-type 
xyz

For ‘service-type’,

· what are the semantics of this parameter ?

· what are the allowed values ?

· what is a typical or example value ?



masakari host-create --name devstack-masakari --type xyz --control-attributes 
xyz --segment-id segment-1

For ‘type’,

  *   what are the semantics of this parameter ?
  *   what are the allowed values ?
  *   what is a typical or example value ?

For ‘control-attributes,

  *   what are the semantics of this parameter ?
  *   what are the allowed values ?
  *   what is a typical or example value ?



And what are the semantics of Masakari Failover Segments ?
My guess is that

· hosts belong to one and only one masakari segment

· when a host fails,
the VMs formerly running on that host will ONLY be recovered to other hosts 
within the same segment
Correct ?
Anything else ?

Greg.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Graham Hayes]

On 19/01/18 16:27, Andrea Frittoli wrote:
> 
> Thanks for the summary!
> 
> To be honest I don't see why this decision has to be difficult to take.

I think the confusion comes from one thing being decided already, and
now conflicting direction is being given to teams, without anyone
updating the Governance repo.

(It is not as if there was not plenty of warning, I have been raising it
as an issue for over a year)

> Nothing we decide today is written in stone and the main risk ahead of
> us is to take
> a decision that requires a lot of upfront work and that it ends up
> providing no
> significant benefit, or even making things worst in some aspect. So we
> may try one way
> today and if we hit some significant issue we can still change.
> 
> TL;DR my preferred option would be number (2) - it's the least initial
> effort, so the
> least risk, and deciding for (2) now won't make it any difficult in the
> future to switch
> to option (1) or option (3). I'm not pushing back on (2), I just think
> (1) is more convenient.
> Details below each option.
>  
> 
> 
> So far the patch proposes three options:
> 
> 1) All trademark-related tests should go in the tempest repo, in
> accordance
>    with the original resolution. This would mean that even projects
> that have
>    never had tests in tempest would now have to add at least some of
> their
>    black-box tests to tempest.
> 
> 
> This option is a valid one, but I think it introduces too much extra
> work and
> testing complications for too little benefit.

What it does do is *guarantee* that the InterOp suite will work, as it
will be CI'd. I see these programs as important enough that we should CI
the tooling used for them, but I seem to be in a minority.

>  
> 
> The value of this option is that centralizes tests used for the
> Interop program
> in a location where interop-minded folks from the QA team can
> control them. 
> 
> 
> There are other ways this can be achieved - it is possible to mark tests
> so that
> team may require a +1 from interop/qa when specific tests are modified.

Is there? AFAIK gerrit does not do per file path permissions, so unless
we have a job that just checks the votes on a patch, and passes or fails
if a test changes (which would be awful for the teams) we cannot do
that.

>  
> 
> The
> downside is that projects that so far have avoided having a
> dependency on
> tempest will now lose some control over the black-box tests that
> they use for
> functional and integration that would now also be used for trademark
> certification.
> There's also concern for the review bandwidth of the QA team - we
> can't expect
> the QA team to be continually responsible for an ever-growing list
> of projects
> and their trademark tests.
> 
> 
> If we restrict to interop tests, the review bandwidth issue is probably
> not so bad.
> The QA team would have to request the domain knowledge required for proper
> review from the respective teams anyways.
> 
> There are other complications introduced though:
> 
> - service clients and other common bits (config and so) would have to
> move to
>   Tempest since we cannot have tempest depend on plugins. But then modifying
>   those common bits on Tempest side would risk to break non-interop tests.
>   Solution for that is to make all those bits stable interfaces for plugins

Is this not already the case? e.g. the neutron plugin uses the nova
service client already.

This would also help for the neutron plugin which is currently importing
DNS service clients from the designate-tempest-plugin repo - having them
in the tempest repo would allow them to to be more stable, and remove
the extra dependency.

>  
> - tempest would have to add new CI jobs to run the interop tests from add-on
>   program on every tempest change so that the new code is tested on a
> regular
>   basis.

That is a good thing, and we should probably do that for the other 2
options as well...

> 
> - heat tests are wrapped in a Tempest plugin but actually written in
> Gabbi so we
>   would need to add Gabbi as a dependency to Tempest
> 
> Nothing too terrible really, but I think it might not be worth the extra
> effort, especially
> now that teams available resources are getting thinner and thinner.
> 
> 
> 2) All trademark-related tests for *add-on projects* should be
> sourced from
>    plugins external to tempest.
> 
> I wouldn't go as far as saying they "should" be sourced. I think saying
> that they
> *may* be sourced from a plugin is enough. Apart from that this is my
> favourite
> option. The only thing required really is updating the resolution and we are
> ready to go.
> 
> With all the plugins no in own branchless repositories, the usability
> concern is
> not so strong anymore really.
>  
> 
> The value of this option is it allows project teams to retain
> control over
> these tests. 
> 
> 
> Other value 

Re: [openstack-dev] [ironic] FFE - Requesting FFE for Routed Networks support.

[Loo, Ruby]

/me +1 too.

--ruby

On 2018-01-17, 10:05 AM, "Dmitry Tantsur"  wrote:

Hi!

I'm essentially +1 on granting this FFE, as it's a low-risk work for a 
great 
feature. See one comment inline.

On 01/17/2018 10:54 AM, Harald Jensås wrote:
> Requesting FFE for Routed Network support in networking-baremetal.
> ---
> 
> 
> # Pros
> --
> With the patches up for review[7] we have a working ml2 agent;
> __depends on neutron fix__; and mechanism driver combination that
> enables support to bind ports on neutron routed networks.
> 
> Specifically we report the bridge_mappings data to neutron, which
> enable the _find_candidate_subnets() method in neutron ipam[1] to
> succeed in finding a candidate subnet available to the ironic node when
> ports on routed segments are bound.
> 
> This functionality will allow users to take advantage of the
> functionality added in DHCP Agent[2] which enables the DHCP agent to
> service other subnets on the network via DHCP relay. For Ironic this
> means we can support deploying nodes on a remote L3 network, e.g
> different datacenter or different rack/rack-row.
> 
> 
> 
> # Cons
> --
> Integration with placement does not currently work.
> 
> Neutron uses Nova host-aggregates in combination with Placement.
> Specifically hosts are added to a host-aggregate for segments based on
> SEGMENT_HOST_MAPPING. Ironic nodes cannot currently be added to host-
> aggregates in Nova. Because of this the following will appear in the
> neutron logs when ironic-neutron agent is started:
> RESP BODY: {"itemNotFound": {"message": "Compute host  id> could not be found.", "code": 404}}
> 
> Also the placement api cannot be used to find good candidate ironic
> nodes with a baremetal port on the correct segment. This will have to be 
worked around by the operator via capabilities and flavor properties or manual 
additions to resource providers in placement.
> 
> Depending on the direction of other projects, neutron and nova, the way
> placement will finally work is not certain.
> 
> Either the nova work [3] and [4], or a neutron change to use placement
> only or a fallback to placement in neutron would be possible. In either
> case there should be no need to change the networking-baremetal agent
> or mechanism driver.
> 
> 
> # Risks
> ---
> Unless this bug[5] is fixed we might break the current baremetal
> mechanism driver functionality. I have proposed a patch[6] to neutron
> that fix the issue. In case no fix lands for this neutron bug soon we
> should probably push these changes to Rocky.

Let's add Depends-On to the first patch in the chain to make sure your 
patches 
don't merge until the fix is merged.

> 
> 
> # Core reviewers
> 
> Julia Kreger, Sam Betts
> 
> 
> 
> 
> [1] https://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/ip
> am_backend_mixin.py#n697
> [2] https://review.openstack.org/#/c/468744/
> [3] https://review.openstack.org/#/c/421009/
> [4] https://review.openstack.org/#/c/421011/
> [5] https://bugs.launchpad.net/neutron/+bug/1743579
> [6] https://review.openstack.org/#/c/534449/
> [7] https://review.openstack.org/#/q/project:openstack/networking-barem
> etal
> 
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-helm] Rocky PTG planning

[MCEUEN, MATT]

I’ve created an etherpad [1] to capture/plan topics for the OpenStack-Helm team 
to discuss at the Rocky PTG.  Please add on more topics we should discuss in 
Dublin – it’s a non-prioritized list; we can prioritize if needed beforehand.

[1]: https://etherpad.openstack.org/p/openstack-helm-ptg-rocky

Thanks!
Matt McEuen

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kuryr][libnetwork] Release kuryr-libnetwork 1.x for Queens

[Daniel Mellado]

+1


El 21/1/18 a las 8:13, Irena Berezovsky escribió:
> +1
>
> On Fri, Jan 19, 2018 at 9:42 PM, Hongbin Lu  > wrote:
>
> Hi Kuryr team,
>
> I think Kuryr-libnetwork is ready to move out of beta status. I
> propose to make the first 1.x release of Kuryr-libnetwork for
> Queens and cut a stable branch on it. What do you think about this
> proposal?
>
> Best regards,
> Hongbin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][oslo.log] JSON logs are missing the request ID

[Doug Hellmann]

Excerpts from Saverio Proto's message of 2018-01-21 18:09:03 +0100:
> Hello,
> 
> I figured out a bug is already open since a long time :(
> https://bugs.launchpad.net/oslo.log/+bug/1564931
> 
> And there is already a review:
> https://review.openstack.org/#/c/367514/
> 
> it looks like the review was not merged, and it went to abandoned
> because of no progress on it for long time.
> 
> I rebased that code on the current master:
> https://review.openstack.org/536149

That patch is not needed on master.

We added the full context as a nested value under the "context" key when
http://git.openstack.org/cgit/openstack/oslo.log/commit/oslo_log/formatters.py?id=1b012d0fc6811f00e032e52ed586fe37e157584d
landed. That change was released as part of 3.35.0 and as the test in
https://review.openstack.org/#/c/536164/ shows the request_id and
global_request_id values are present in the output.

Before that change (and after, as part of our effort to maintain
backwards compatibility) the values from the context were added to the
"extra" section of the output message. That behavior is present in

master: 
http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/formatters.py?h=master#n246
pike: 
http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/formatters.py?h=stable%2Fpike#n300
ocata: 
http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/formatters.py?h=stable%2Focata#n156

It also appears to be present for newton, the version you said you are
using:

http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/formatters.py?h=newton-eol#n153

Have you looked at the "extras" section of the log output?

Could you provide some sample log output?

Doug

> 
> Saverio
> 
> On 18.01.18 18:14, Doug Hellmann wrote:
> > Excerpts from Doug Hellmann's message of 2018-01-18 11:45:28 -0500:
> >> Excerpts from Saverio Proto's message of 2018-01-18 14:49:21 +0100:
> >>> Hello all,
> >>>
> >>> well this oslo.log library looks like a core thing that is used by
> >>> multiple projects. I feel scared hearing that bugs opened on that
> >>> project are probably just ignored.
> >>>
> >>> should I reach out to the current PTL of OSLO ?
> >>> https://github.com/openstack/governance/blob/master/reference/projects.yaml#L2580
> >>>
> >>> ChangBo Guo are you reading this thread ? Do you think this is a bug or
> >>> a missing feature ? And moreover is really nobody looking at these
> >>> oslo.log bugs ?
> >>
> >> The Oslo team is small, but we do pay attention to bug reports. I
> >> don't think this issue is going to rise to the level of "drop what
> >> you're doing and help because the world is on fire", so I think
> >> Sean is just encouraging you to have a little patience.
> >>
> >> Please do go ahead and open a bug and attach (or paste into the
> >> description) an example of what the log output for your service looks
> >> like.
> >>
> >> Doug
> > 
> > Earlier in the thread you mentioned running the newton versions of
> > neutron and oslo.log. The newton release has been marked end-of-life
> > and is not supported by the community any longer. You may find
> > support from your vendor, but if you're deploying on your own we'll
> > have to work something else out. If we determine that this is a bug
> > in the newton version of the library I won't have any way to give
> > you a new release because the branch is closed.
> > 
> > It should be possible for you to update just oslo.log to a more
> > recent (and supported), although to do so you would have to get the
> > package separately or build your own and that may complicate your
> > deployment.
> > 
> > More recent versions of the JSON formatter change the structure of
> > the data to include the entire context (including the request id)
> > in a separate key.  Are you updating to newton as part of upgrading
> > further than that?  If so, we probably want to wait to debug this
> > until you hit the latest supported version you're planning to deploy,
> > in case the problem is already fixed there.
> > 
> > Doug
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Native QEMU LUKS decryption review overview ahead of FF

[Lee Yarwood]

Hello,

With M3 and FF rapidly approaching this week I wanted to post a brief
overview of the QEMU native LUKS series.

The full series is available on the following topic, I'll go into more
detail on each of the changes below:

https://review.openstack.org/#/q/topic:bp/libvirt-qemu-native-luks+status:open

libvirt: Collocate encryptor and volume driver calls
https://review.openstack.org/#/c/460243/ (Missing final +2 and +W)

This refactor of the Libvirt driver connect and disconnect volume code
has the added benefit of also correcting a number of bugs around the
attaching and detaching of os-brick encryptors. IMHO this would be
useful in Queens even if the rest of the series doesn't land.

libvirt: Introduce disk encryption config classes
https://review.openstack.org/#/c/464008/ (Missing final +2 and +W)

This is the most straight forward change of the series and simply
introduces the required config classes to wire up native LUKS decryption
within the domain XML of an instance. Hopefully nothing controversial.

libvirt: QEMU native LUKS decryption for encrypted volumes
https://review.openstack.org/#/c/523958/ (Missing both +2s and +W)

This change carries the bulk of the implementation, wiring up encrypted
volumes during their initial attachment. The commit message has a
detailed run down of the various upgrade and LM corner cases we attempt
to handle here, such as LM from a P to Q compute, detaching a P attached
encrypted volume after upgrading to Q etc.

Upgrade and LM testing is enabled by the following changes:

fixed_key: Use a single hardcoded key across devstack deployments
https://review.openstack.org/#/c/536343/

compute: Introduce an encrypted volume LM test
https://review.openstack.org/#/c/536177/

This is being tested by tempest-dsvm-multinode-live-migration and
grenade-dsvm-neutron-multinode-live-migration in the following DNM Nova
change, enabling volume backed LM tests:

DNM: Test LM with encrypted volumes
https://review.openstack.org/#/c/536350/

Hopefully that covers everything but please feel free to ping if you
would like more detail, background etc. Thanks in advance,

Lee
-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] tripleo-upgrade pike branch

[Marius Cornea]

On Fri, Jan 19, 2018 at 4:47 PM, John Trowbridge  wrote:
>
>
> On Fri, Jan 19, 2018 at 10:21 AM, Wesley Hayutin 
> wrote:
>>
>> Thanks Marius for sending this out and kicking off a conversation.
>>
>> On Tue, Jan 2, 2018 at 12:56 PM, Marius Cornea  wrote:
>>>
>>> Hi everyone and Happy New Year!
>>>
>>> As the migration of tripleo-upgrade repo to the openstack namespace is
>>> now complete I think it's the time to create a Pike branch to capture
>>> the current state so we can use it for Pike testing and keep the
>>> master branch for Queens changes. The update/upgrade steps are
>>> changing between versions and the aim of branching the repo is to keep
>>> the update/upgrade steps clean per branch to avoid using conditionals
>>> based on release. Also tripleo-upgrade should be compatible with
>>> different tools used for deployment(tripleo-quickstart, infrared,
>>> manual deployments) which use different vars for the version release
>>> so in case of using conditionals we would need extra steps to
>>> normalize these variables.
>>
>>
>> I understand the desire to create a branch to protect the work that has
>> been done previously.
>> The interesting thing is that you guys are proposing to use a branched
>> ansible role with
>> a branchless upstream project.  I want to make sure we have enough review
>> so that we don't hit issues
>> in the future.   Maybe that is OK, but I have at least one concern.
>>
>> My conern is about gating the tripleo-upgrade role and it's branches.
>> When tripleo-quickstart is changed
>> which is branchless we will be have to kick off a job for each
>> tripleo-upgrade branch?  That immediately doubles
>> the load on gates.
>
>
> I do not think CI repos should be branched. Even more than the concern Wes
> brought up about a larger gate matrix. Think
> about how much would need to get backported. To start you would just have
> the 2 branches, but eventually you will have 3.
> Likely all 3 will have slight differences in how different pieces of the
> upgrade are called (otherwise why branch), so when
> you need to fix something on all branches the backports have a high
> potential to be non-trivial too.

Once we release we expect the upgrade/update process to be stable and
no changes required to the process so I expect the backports to be
minimal, mostly for scenarios that we missed in testing at release
time.

> Release conditionals are not perfect, but I dont think compatibility is
> really a major issue. Just document how to set the
> release, and the different CI tools that use your role will just have to
> adapt to that.
>>
>>
>> It's extemely important to properly gate this role against the versions of
>> TripleO and OSP.  I see very limited
>> check jobs and gate jobs on tripleo-upgrades atm.  I have only found [1].
>> I think we need to see some external and internal
>> jobs checking and gating this role with comments posted to changes.
>>
>> [1]
>> https://review.rdoproject.org/jenkins/job/gate-tripleo-ci-centos-7-containers-multinode-upgrades-pike/
>>
>>
>>>
>>>
>>> I wanted to bring this topic up for discussion to see if branching is
>>> the proper thing to do here.
>>>
>>> Thanks,
>>> Marius
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Remove in-tree policy and config?

[Pavlo Shchelokovskyy]

John,

+1.

The sample file in etc/ironic/ in our repo is actually (almost) always out
of sync with the one in the docs - the docs one is re-generated on each
commit with new/changed stuff from third-party libs, the version in
etc/ironic is only updated manually when someone remembers it (as people
usually tend to limit the changes to this file in their commit to relevant
ones).

Cheers,

On Mon, Jan 22, 2018 at 2:45 PM, John Garbutt  wrote:

> Hi,
>
> While I was looking at the traits work, I noticed we still have policy and
> config in tree for ironic and ironic inspector:
>
> http://git.openstack.org/cgit/openstack/ironic/tree/etc/
> ironic/policy.json.sample
> http://git.openstack.org/cgit/openstack/ironic/tree/etc/
> ironic/ironic.conf.sample
> http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/policy.json
>
> And in a similar way:
> http://git.openstack.org/cgit/openstack/ironic-inspector/
> tree/policy.yaml.sample
> http://git.openstack.org/cgit/openstack/ironic-inspector/tree/example.conf
>
> There is an argument that says we shouldn't force operators to build a
> full environment to generate these, but this has been somewhat superseded
> by us having good docs:
>
> https://docs.openstack.org/ironic/latest/configuration/sample-config.html
> https://docs.openstack.org/ironic/latest/configuration/sample-policy.html
> https://docs.openstack.org/ironic-inspector/latest/
> configuration/sample-config.html
> https://docs.openstack.org/ironic-inspector/latest/
> configuration/sample-policy.html
>
> It could look something like this (but with the tests working...):
> https://review.openstack.org/#/c/536349
>
> What do you all think?
>
> Thanks,
> johnthetubaguy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] Remove in-tree policy and config?

[Dmitry Tantsur]

+1

I would really hate to not have a place to reference people to, but the 
documentation now provides such place. Keeping the examples up-to-date is quite 
annoying, I'm all for dropping them.


On 01/22/2018 01:45 PM, John Garbutt wrote:

Hi,

While I was looking at the traits work, I noticed we still have policy and 
config in tree for ironic and ironic inspector:


http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/policy.json.sample
http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/ironic.conf.sample
http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/policy.json

And in a similar way:
http://git.openstack.org/cgit/openstack/ironic-inspector/tree/policy.yaml.sample
http://git.openstack.org/cgit/openstack/ironic-inspector/tree/example.conf

There is an argument that says we shouldn't force operators to build a full 
environment to generate these, but this has been somewhat superseded by us 
having good docs:


https://docs.openstack.org/ironic/latest/configuration/sample-config.html
https://docs.openstack.org/ironic/latest/configuration/sample-policy.html
https://docs.openstack.org/ironic-inspector/latest/configuration/sample-config.html
https://docs.openstack.org/ironic-inspector/latest/configuration/sample-policy.html

It could look something like this (but with the tests working...):
https://review.openstack.org/#/c/536349

What do you all think?

Thanks,
johnthetubaguy


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] tripleo-upgrade pike branch

[Marius Cornea]

On Fri, Jan 19, 2018 at 4:21 PM, Wesley Hayutin  wrote:
> Thanks Marius for sending this out and kicking off a conversation.
>
> On Tue, Jan 2, 2018 at 12:56 PM, Marius Cornea  wrote:
>>
>> Hi everyone and Happy New Year!
>>
>> As the migration of tripleo-upgrade repo to the openstack namespace is
>> now complete I think it's the time to create a Pike branch to capture
>> the current state so we can use it for Pike testing and keep the
>> master branch for Queens changes. The update/upgrade steps are
>> changing between versions and the aim of branching the repo is to keep
>> the update/upgrade steps clean per branch to avoid using conditionals
>> based on release. Also tripleo-upgrade should be compatible with
>> different tools used for deployment(tripleo-quickstart, infrared,
>> manual deployments) which use different vars for the version release
>> so in case of using conditionals we would need extra steps to
>> normalize these variables.
>
>
> I understand the desire to create a branch to protect the work that has been
> done previously.
> The interesting thing is that you guys are proposing to use a branched
> ansible role with
> a branchless upstream project.  I want to make sure we have enough review so
> that we don't hit issues
> in the future.   Maybe that is OK, but I have at least one concern.
>
> My conern is about gating the tripleo-upgrade role and it's branches.  When
> tripleo-quickstart is changed
> which is branchless we will be have to kick off a job for each
> tripleo-upgrade branch?  That immediately doubles
> the load on gates.

I think it would probably be the same when using multiple release
conditionals, we'd still have to trigger one job/release if we wanted
full coverage.

> It's extemely important to properly gate this role against the versions of
> TripleO and OSP.  I see very limited
> check jobs and gate jobs on tripleo-upgrades atm.  I have only found [1].
> I think we need to see some external and internal
> jobs checking and gating this role with comments posted to changes.
>
> [1]
> https://review.rdoproject.org/jenkins/job/gate-tripleo-ci-centos-7-containers-multinode-upgrades-pike/
>
>
>>
>>
>> I wanted to bring this topic up for discussion to see if branching is
>> the proper thing to do here.
>>
>> Thanks,
>> Marius
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] Remove in-tree policy and config?

[John Garbutt]

Hi,

While I was looking at the traits work, I noticed we still have policy and
config in tree for ironic and ironic inspector:

http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/policy.json.sample
http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/ironic.conf.sample
http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/policy.json

And in a similar way:
http://git.openstack.org/cgit/openstack/ironic-inspector/tree/policy.yaml.sample
http://git.openstack.org/cgit/openstack/ironic-inspector/tree/example.conf

There is an argument that says we shouldn't force operators to build a full
environment to generate these, but this has been somewhat superseded by us
having good docs:

https://docs.openstack.org/ironic/latest/configuration/sample-config.html
https://docs.openstack.org/ironic/latest/configuration/sample-policy.html
https://docs.openstack.org/ironic-inspector/latest/configuration/sample-config.html
https://docs.openstack.org/ironic-inspector/latest/configuration/sample-policy.html

It could look something like this (but with the tests working...):
https://review.openstack.org/#/c/536349

What do you all think?

Thanks,
johnthetubaguy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Notification update week 4

[Balázs Gibizer]

Hi,

Here is the status update / focus settings mail for w4.

Bugs

[High] https://bugs.launchpad.net/nova/+bug/1742962 nova functional
test does not triggered on notification sample only changes
During the zuul v3 migration the project-config generated based on the
zuul v2 jobs. It contained a proper definition of when nova wants to
trigger the functional job. Unfortunately this job definition does not
override the openstack-tox-functional job definition from the
openstack-zuul-jobs repo. This caused that the openstack-tox-functional
(and functional-py35) jobs were not triggered for certain commits. The
fix is to create a nova specific tox-functional job in tree. Patches
has been proposed:
* https://review.openstack.org/#/c/533210/ Make sure that functional
test triggered on sample changes
* https://review.openstack.org/#/c/533608/ Moving nova functional test
def to in tree
In general we have to review all nova jobs in the project-config and
move those in-tree that try to override parameters of the job
definitions in openstack-zuul-jobs repo.

[High] https://bugs.launchpad.net/nova/+bug/1737201 TypeError when
sending notification during attach_interface
Fix merged to master. Backports have been proposed:
* Pike: https://review.openstack.org/#/c/531745/
* Queens: https://review.openstack.org/#/c/531746/

[High] https://bugs.launchpad.net/nova/+bug/1739325 Server operations
fail to complete with versioned notifications if payload contains unset
non-nullable fields
Patch has been proposed: https://review.openstack.org/#/c/529194/
Dan left feedback on it and I accept his comment that this is mostly
papering over a problem that we don't fully understand how can happen
in the first place. In the other hand I don't know how can we figure
out what happend. So if somebody has an idea then don't hesistate to
tell me. This bug is still stuck.

[Low] https://bugs.launchpad.net/nova/+bug/1487038
nova.exception._cleanse_dict should use
oslo_utils.strutils._SANITIZE_KEYS
Old abandoned patches exist but need somebody to pick them up:
* https://review.openstack.org/#/c/215308/
* https://review.openstack.org/#/c/388345/

Versioned notification transformation
-
Thanks for Takashi we have multiple patches needing only a second +2:
* https://review.openstack.org/#/c/482148 Transform instance-evacuate 
notification
* https://review.openstack.org/#/c/465081 Transform 
instance.resize_prep notification
* https://review.openstack.org/#/c/482557 Transform 
instance.resize_confirm notification


Also there are patches ready for cores to review:
* https://review.openstack.org/#/c/403660 Transform instance.exists
notification
* https://review.openstack.org/#/c/410297 Transform missing delete
notifications
* https://review.openstack.org/#/c/476459 Send soft_delete from context
manager

Introduce instance.lock and instance.unlock notifications
---
A specless bp has been proposed to the Rocky cycle
https://blueprints.launchpad.net/nova/+spec/trigger-notifications-when-lock-unlock-instances
Some preliminary discussion happened in an earlier patch
https://review.openstack.org/#/c/526251/

Add the user id and project id of the user initiated the instance
action to the notification

A new bp has been proposed
https://blueprints.launchpad.net/nova/+spec/add-action-initiator-to-instance-action-notifications
As the user who initiates the instance action (e.g. reboot) could be
different from the user owning the instance it would make sense to
include the user_id and project_id of the action initiatior to the
versioned instance action notifications as well.

Factor out duplicated notification sample
-
https://review.openstack.org/#/q/topic:refactor-notification-samples+status:open
We have to be carefull to approve these type of commits until the
solution for https://bugs.launchpad.net/nova/+bug/1742962 merged as
functional tests could be broken silently.

Weekly meeting
--
The next meeting will be held on 23th of January on #openstack-meeting-4
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180123T17

Cheers,
gibi


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] Lib branching for stable/queens

[Sean McGinnis]

On Mon, Jan 22, 2018 at 11:10:23AM +0100, Dmitry Tantsur wrote:
> Hi!
> 
> Unfortunately, it seems that we've discovered a critical issue in one of our
> libs (sushy) right after branching :( What's the procedure for emergency
> fixes to stable/queens right now?
> 

We can do another release. Just propose the new release with the new hash in
the deliverables/queens/sushy.yaml file.

The one trickier part you have to keep in mind is that it will need to be on
the stable/queens branch. So you should be merging your fix into master, then
backporting to stable/queens like you would do for any normal stable branch
fixes.

Sean

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Many timeouts in zuul gates for TripleO

[Or Idgar]

Hi,
Still having timeouts but now in tripleo-heat-templates experimental gates
(tripleo-ci-centos-7-ovb-fakeha-caserver and
tripleo-ci-centos-7-ovb-ha-tempest-oooq).

see examples:
http://logs.openstack.org/31/518331/23/experimental-tripleo/tripleo-ci-centos-7-ovb-fakeha-caserver/7502e82/
http://logs.openstack.org/31/518331/23/experimental-tripleo/tripleo-ci-centos-7-ovb-ha-tempest-oooq/46e8e0d/

Anyone have an idea what we can do to fix it?

Thanks,
Idgar

On Sat, Jan 20, 2018 at 4:38 AM, Paul Belanger 
wrote:

> On Fri, Jan 19, 2018 at 11:23:45AM -0600, Ben Nemec wrote:
> >
> >
> > On 01/18/2018 09:45 AM, Emilien Macchi wrote:
> > > On Thu, Jan 18, 2018 at 6:34 AM, Or Idgar  wrote:
> > > > Hi,
> > > > we're encountering many timeouts for zuul gates in TripleO.
> > > > For example, see
> > > > http://logs.openstack.org/95/508195/28/check-tripleo/
> tripleo-ci-centos-7-ovb-ha-oooq/c85fcb7/.
> > > >
> > > > rechecks won't help and sometimes specific gate is end successfully
> and
> > > > sometimes not.
> > > > The problem is that after recheck it's not always the same gate
> which is
> > > > failed.
> > > >
> > > > Is there someone who have access to the servers load to see what
> cause this?
> > > > alternatively, is there something we can do in order to reduce the
> running
> > > > time for each gate?
> > >
> > > We're migrating to RDO Cloud for OVB jobs:
> > > https://review.openstack.org/#/c/526481/
> > > It's a work in progress but will help a lot for OVB timeouts on RH1.
> > >
> > > I'll let the CI folks comment on that topic.
> > >
> >
> > I noticed that the timeouts on rh1 have been especially bad as of late
> so I
> > did a little testing and found that it did seem to be running more slowly
> > than it should.  After some investigation I found that 6 of our compute
> > nodes have warning messages that the cpu was throttled due to high
> > temperature.  I've disabled 4 of them that had a lot of warnings. The
> other
> > 2 only had a handful of warnings so I'm hopeful we can leave them active
> > without affecting job performance too much.  It won't accomplish much if
> we
> > disable the overheating nodes only to overload the remaining ones.
> >
> > I'll follow up with our hardware people and see if we can determine why
> > these specific nodes are overheating.  They seem to be running 20
> degrees C
> > hotter than the rest of the nodes.
> >
> Did tripleo-test-cloud-rh1 get new kernels applied for meltdown / spectre,
> possible that is impacting performance too?
>
> -Paul
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best regards,
Or Idgar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][packaging] django-openstack-auth retirement

[Jeremy Stanley]

On 2018-01-22 14:40:49 +0900 (+0900), Akihiro Motoki wrote:
[...]
> If you install horizon and django-openstack-auth by using pip (instead
> of distribution packages), please uninstall django-openstack-auth
> python package before upgrading horizon.
> Otherwise, "openstack_auth" module is maintained by both horizon and
> django-openstack-auth after upgrading horizon and it confuses the pip
> file management, while horizon works.
[...]

If we were already publishing Horizon to PyPI, we could have a new
(and final) major version of DOA as a transitional package to stop
providing any module itself and depend on the new version of Horizon
which provides that module instead. I suppose without Horizon on
PyPI, documentation of the issue is the most we can do for this
situation.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release] Lib branching for stable/queens

[Dmitry Tantsur]

Hi!

Unfortunately, it seems that we've discovered a critical issue in one of our 
libs (sushy) right after branching :( What's the procedure for emergency fixes 
to stable/queens right now?


On 01/19/2018 10:15 PM, Sean McGinnis wrote:

Happy Friday all.

Now that we are past the non-client lib freeze, we will need to have
stable/queens branches for those libs. For all libraries that did not miss the
freeze, I will be proposing the patches to get those stable branches created.

This should have been enforced as part of the last deliverable request, but I
don't think we had quite everything in place for branch creation. Going forward
as we do the client library releases and then the service releases, please make
sure your patch requesting the release includes creating the stable/queens
branching.

If there is any reason for me to hold off on this for a library your team
manages, please let me know ASAP.


Upcoming service project branching
==

I mentioned this in the countdown email, but to increase the odds that someone
actually sees it - if your project follows the cycle-with-milestones release
model, please check membership of your $project-release group. The members of
the group can be found by filtering for the group here:

https://review.openstack.org/#/admin/groups/

This group should be limited to those aware of the restrictions as we wrap up
the end of the cycle to make sure only release critical things are allowed to
be merged into stable/queens as we finalize things for the final release.

As always, just let me know if there are any questions.

--
Sean McGinnis (smcginnis)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo][ui] Dependency management

[Julie Pichon]

On 19 January 2018 at 18:43, Honza Pokorny  wrote:
> We've recently discovered an issue with the way we handle dependencies for
> tripleo-ui.  This is an explanation of the problem, and a proposed solution.
> I'm looking for feedback.
>
> Before the upgrade to zuul v3 in TripleO CI, we had two types of jobs for
> tripleo-ui:
>
> * Native npm jobs
> * Undercloud integration jobs
>
> After the upgrade, the integration jobs went away.  Our goal is to add them
> back.
>
> There is a difference in how these two types of jobs handle dependencies.
> Native npm jobs use the "npm install" command to acquire packages, and
> undercloud jobs use RPMs.  The tripleo-ui project uses a separate RPM for
> dependencies called openstack-tripleo-ui-deps.
>
> Because of the requirement to use a separate RPM for dependencies, there is 
> some
> extra work needed when a new dependency is introduced, or an existing one is
> upgraded.  Once the patch that introduces the dependency is merged, we have to
> increment the version of the -deps package, and rebuild it.  It then shows up 
> in
> the yum repos used by the undercloud.
>
> To make matters worse, we recently upgraded our infrastructure to nodejs 8.9.4
> and npm 5.6.0 (latest stable).  This makes it so we can't write "purist" 
> patches
> that simply introduce a new dependency to package.json, and nothing more.  The
> code that uses the new dependency must be included.  I tend to think that each
> commit should work on its own so this can be seen as a plus.
>
> This presents a problem: you can't get a patch that introduces a new 
> dependency
> merged because it's not included in the RPM needed by the undercloud ci job.
>
> So, here is a proposal on how that might work:
>
> 1. Submit a patch for review that introduces the dependency, along with code
>changes to support it and validate its inclusion
> 2. Native npm jobs will pass
> 3. Undercloud gate job will fail because the dependency isn't in -deps RPM
> 4. We ask RDO to review for licensing
> 5. Once reviewed, new -deps package is built
> 6. Recheck
> 7. All jobs pass

Perhaps there should be a step after 3 or 4 to have the patch normally
reviewed, and wait for it to have two +2s before building the new
package? Otherwise we may end up with wasted work to get a new package
ready for dependencies that were eventually dismissed.

Julie

> There is the obvious issue with building an RPM based on an unmerged patch.
>
> What do you think?  Is that possible?  Any other solutions?
>
> Honza Pokorny

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev