Re: [openstack-dev] [oslo] proposing Ken Giusti for oslo-core

[Flavio Percoco]

On 26/03/18 11:52 -0400, Doug Hellmann wrote:

Ken has been managing oslo.messaging for ages now but his participation
in the team has gone far beyond that single library. He regularly
attends meetings, including the PTG, and has provided input into several
of our team decisions recently.

I think it's time we make him a full member of the oslo-core group.

Please respond here with a +1 or -1 to indicate your opinion.


YAY! +1

--
@flaper87
Flavio Percoco


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] [octavia] Proposing Jacky Hu (dayou) as an Octavia core reviewer

[Adam Harwell]

+1, definitely a good contributor! Thanks especially for your work on the
dashboard!

On Tue, Mar 27, 2018 at 2:09 PM German Eichberger <
german.eichber...@rackspace.com> wrote:

> +1
>
> Really excited to work with Jacky --
>
> German
>
> On 3/26/18, 8:33 PM, "Michael Johnson"  wrote:
>
> Hello Octavia community,
>
> I would like to propose Jacky Hu (dayou) as a core reviewer on the
> Octavia project.
>
> Jacky has done amazing work on Octavia dashboard, specifically
> updating the look and feel of our details pages to be more user
> friendly.  Recently he has contributed support for L7 policies in the
> dashboard and caught us up with the wider Horizon framework advances.
>
> Jacky has also contributed thoughtful reviews on the main Octavia
> project as well as contributed to the L3 Active/Active work in
> progress.
>
> Jacky's review statistics are in line with the other core reviewers
> [1] and I feel Jacky would make a great addition to the Octavia core
> reviewer team.
>
> Existing Octavia core reviewers, please reply to this email with your
> support or concerns with adding Jacky to the core team.
>
> Michael
>
> [1] http://stackalytics.com/report/contribution/octavia-group/90
>
>
> __
> 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] [octavia] Proposing Jacky Hu (dayou) as an Octavia core reviewer

[German Eichberger]

+1

Really excited to work with Jacky --

German

On 3/26/18, 8:33 PM, "Michael Johnson"  wrote:

Hello Octavia community,

I would like to propose Jacky Hu (dayou) as a core reviewer on the
Octavia project.

Jacky has done amazing work on Octavia dashboard, specifically
updating the look and feel of our details pages to be more user
friendly.  Recently he has contributed support for L7 policies in the
dashboard and caught us up with the wider Horizon framework advances.

Jacky has also contributed thoughtful reviews on the main Octavia
project as well as contributed to the L3 Active/Active work in
progress.

Jacky's review statistics are in line with the other core reviewers
[1] and I feel Jacky would make a great addition to the Octavia core
reviewer team.

Existing Octavia core reviewers, please reply to this email with your
support or concerns with adding Jacky to the core team.

Michael

[1] http://stackalytics.com/report/contribution/octavia-group/90

__
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] Proposing Eric Fried for nova-core

[Jay Pipes]

+1

On 03/26/2018 10:00 PM, melanie witt wrote:

Howdy everyone,

I'd like to propose that we add Eric Fried to the nova-core team.

Eric has been instrumental to the placement effort with his work on 
nested resource providers and has been actively contributing to many 
other areas of openstack [0] like project-config, gerritbot, 
keystoneauth, devstack, os-loganalyze, and so on.


He's an active reviewer in nova [1] and elsewhere in openstack and 
reviews in-depth, asking questions and catching issues in patches and 
working with authors to help get code into merge-ready state. These are 
qualities I look for in a potential core reviewer.


In addition to all that, Eric is an active participant in the project in 
general, helping people with questions in the #openstack-nova IRC 
channel, contributing to design discussions, helping to write up 
outcomes of discussions, reporting bugs, fixing bugs, and writing tests. 
His contributions help to maintain and increase the health of our project.


To the existing core team members, please respond with your comments, 
+1s, or objections within one week.


Cheers,
-melanie

[0] https://review.openstack.org/#/q/owner:efried
[1] http://stackalytics.com/report/contribution/nova/90

__
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] [octavia] Proposing Jacky Hu (dayou) as an Octavia core reviewer

[Michael Johnson]

Hello Octavia community,

I would like to propose Jacky Hu (dayou) as a core reviewer on the
Octavia project.

Jacky has done amazing work on Octavia dashboard, specifically
updating the look and feel of our details pages to be more user
friendly.  Recently he has contributed support for L7 policies in the
dashboard and caught us up with the wider Horizon framework advances.

Jacky has also contributed thoughtful reviews on the main Octavia
project as well as contributed to the L3 Active/Active work in
progress.

Jacky's review statistics are in line with the other core reviewers
[1] and I feel Jacky would make a great addition to the Octavia core
reviewer team.

Existing Octavia core reviewers, please reply to this email with your
support or concerns with adding Jacky to the core team.

Michael

[1] http://stackalytics.com/report/contribution/octavia-group/90

__
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] Proposing Eric Fried for nova-core

[Chen CH Ji]

+1, Eric is very active and thorough reviewer  ~

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:   melanie witt 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   03/27/2018 10:00 AM
Subject:[openstack-dev] [nova] Proposing Eric Fried for nova-core



Howdy everyone,

I'd like to propose that we add Eric Fried to the nova-core team.

Eric has been instrumental to the placement effort with his work on
nested resource providers and has been actively contributing to many
other areas of openstack [0] like project-config, gerritbot,
keystoneauth, devstack, os-loganalyze, and so on.

He's an active reviewer in nova [1] and elsewhere in openstack and
reviews in-depth, asking questions and catching issues in patches and
working with authors to help get code into merge-ready state. These are
qualities I look for in a potential core reviewer.

In addition to all that, Eric is an active participant in the project in
general, helping people with questions in the #openstack-nova IRC
channel, contributing to design discussions, helping to write up
outcomes of discussions, reporting bugs, fixing bugs, and writing tests.
His contributions help to maintain and increase the health of our project.

To the existing core team members, please respond with your comments,
+1s, or objections within one week.

Cheers,
-melanie

[0]
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_q_owner-3Aefried=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=rVAEN3iJ6T8bfl-T2cr0r2V9b3Y77SNCG-f-5mRS14M=w_QMVh424GtoPTNns-WQXjrX6VTVPNAQBw__J_Sxiiw=

[1]
https://urldefense.proofpoint.com/v2/url?u=http-3A__stackalytics.com_report_contribution_nova_90=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0=rVAEN3iJ6T8bfl-T2cr0r2V9b3Y77SNCG-f-5mRS14M=AE65CYdFeQnyWsUN20WoNI-VujdaNjfn2RiAmFz9BWc=


__
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=rVAEN3iJ6T8bfl-T2cr0r2V9b3Y77SNCG-f-5mRS14M=QRzghstztOBBcjk4bouT3z0yudqvu_2Su9Vmmree3SM=




__
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] proposing Ken Giusti for oslo-core

[ChangBo Guo]

+1

2018-03-27 0:58 GMT+08:00 Joshua Harlow :

> +1
>
>
> Ben Nemec wrote:
>
>> +1!
>>
>> On 03/26/2018 10:52 AM, Doug Hellmann wrote:
>>
>>> Ken has been managing oslo.messaging for ages now but his participation
>>> in the team has gone far beyond that single library. He regularly
>>> attends meetings, including the PTG, and has provided input into several
>>> of our team decisions recently.
>>>
>>> I think it's time we make him a full member of the oslo-core group.
>>>
>>> Please respond here with a +1 or -1 to indicate your opinion.
>>>
>>> Thanks,
>>> 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:unsubscrib
>> e
>> 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
>



-- 
ChangBo Guo(gcb)
Community Director @EasyStack
__
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] Proposing Eric Fried for nova-core

[Alex Xu]

+1

2018-03-27 10:00 GMT+08:00 melanie witt :

> Howdy everyone,
>
> I'd like to propose that we add Eric Fried to the nova-core team.
>
> Eric has been instrumental to the placement effort with his work on nested
> resource providers and has been actively contributing to many other areas
> of openstack [0] like project-config, gerritbot, keystoneauth, devstack,
> os-loganalyze, and so on.
>
> He's an active reviewer in nova [1] and elsewhere in openstack and reviews
> in-depth, asking questions and catching issues in patches and working with
> authors to help get code into merge-ready state. These are qualities I look
> for in a potential core reviewer.
>
> In addition to all that, Eric is an active participant in the project in
> general, helping people with questions in the #openstack-nova IRC channel,
> contributing to design discussions, helping to write up outcomes of
> discussions, reporting bugs, fixing bugs, and writing tests. His
> contributions help to maintain and increase the health of our project.
>
> To the existing core team members, please respond with your comments, +1s,
> or objections within one week.
>
> Cheers,
> -melanie
>
> [0] https://review.openstack.org/#/q/owner:efried
> [1] http://stackalytics.com/report/contribution/nova/90
>
> __
> 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] Proposing Eric Fried for nova-core

[melanie witt]

Howdy everyone,

I'd like to propose that we add Eric Fried to the nova-core team.

Eric has been instrumental to the placement effort with his work on 
nested resource providers and has been actively contributing to many 
other areas of openstack [0] like project-config, gerritbot, 
keystoneauth, devstack, os-loganalyze, and so on.


He's an active reviewer in nova [1] and elsewhere in openstack and 
reviews in-depth, asking questions and catching issues in patches and 
working with authors to help get code into merge-ready state. These are 
qualities I look for in a potential core reviewer.


In addition to all that, Eric is an active participant in the project in 
general, helping people with questions in the #openstack-nova IRC 
channel, contributing to design discussions, helping to write up 
outcomes of discussions, reporting bugs, fixing bugs, and writing tests. 
His contributions help to maintain and increase the health of our project.


To the existing core team members, please respond with your comments, 
+1s, or objections within one week.


Cheers,
-melanie

[0] https://review.openstack.org/#/q/owner:efried
[1] http://stackalytics.com/report/contribution/nova/90

__
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] Thank you TryStack!!

[Jimmy Mcarthur]

Hi everyone,

We recently made the tough decision, in conjunction with the dedicated 
volunteers that run TryStack, to end the service as of March 29, 2018.  
For those of you that used it, thank you for being part of the TryStack 
community.


The good news is that you can find more resources to try OpenStack at 
http://www.openstack.org/start, including the Passport Program 
, where you can test on any 
participating public cloud. If you are looking to test different tools 
or application stacks with OpenStack clouds, you should check out Open 
Lab .


Thank you very much to Will Foster, Kambiz Aghaiepour, Rich Bowen, and 
the many other volunteers who have managed this valuable service for the 
last several years!  Your contribution to OpenStack was noticed and 
appreciated by many in the community.


Cheers,
Jimmy
__
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] Rocky community goal: remove the use of mox/mox3 for testing

[melanie witt]

Hey everyone,

This cycle there is a community goal to remove the use of mox/mox3 for 
testing [0]. In nova, we're tracking our work at this blueprint:


  https://blueprints.launchpad.net/nova/+spec/mox-removal

If you propose patches contributing to this goal, please be sure to add 
something like "Part of blueprint mox-removal" in the commit message of 
your patch so it will be tracked as part of the blueprint for Rocky.


NOTE: Please avoid converting any tests related to cells v1 or 
nova-network as these two legacy features are either in-progress of 
being removed or on the road map to being removed within the next two 
cycles. Tests to *avoid* converting are located:


  nova/tests/unit/cells/
  nova/nova/tests/unit/compute/test_compute_cells.py
  nova/tests/unit/network/test_manager.py

Please reply with other cells v1 or nova-network test locations to avoid 
if I've missed any.


Thanks,
-melanie

[0] https://storyboard.openstack.org/#!/story/2001546

__
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] Bug Day April 6th poll

[Michael Turek]

Hey everyone,

I set up a doodle to vote on when we should hold the bug day on April 
6th https://doodle.com/poll/xa999rx653pb58t6


I'm not sure how long we want the session to be so I provided 24 1 hour 
windows. Please vote with what blocks of time would work best for you.


Thanks!
Mike Turek 


__
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] Tag of openstack/instack-undercloud failed

[Alex Schultz]

On Mon, Mar 26, 2018 at 2:33 PM, Doug Hellmann  wrote:
> Excerpts from zuul's message of 2018-03-26 18:11:49 +:
>> Build failed.
>>
>> - publish-openstack-releasenotes 
>> http://logs.openstack.org/94/94bb28ae46bd263314c9d846069ca913d225e625/tag/publish-openstack-releasenotes/9440894/
>>  : POST_FAILURE in 3m 29s
>>
>
> This release notes build failure is probably not a problem, but I
> don't recognize the cause of the error so I wanted to bring it up
> in case someone else did.
>
> Is the ".pike.html.AEKeun" a lock file of some sort? Or a temporary
> file created for some other purpose?
>

I think that's part of the rsync process.  From
https://rsync.samba.org/how-rsync-works.html

> The receiver will read from the sender data for each file identified by the 
> file index number. It will open the local file (called the basis) and will 
> create a temporary file.
>
>  The receiver will expect to read non-matched data and/or to match records 
> all in sequence for the final file contents. When non-matched data is read it 
> will be written to the temp-file. When a block match record is received the
>  receiver will seek to the block offset in the basis file and copy the block 
> to the temp-file. In this way the temp-file is built from beginning to end.
>
> The file's checksum is generated as the temp-file is built. At the end of the 
> file, this checksum is compared with the file checksum from the sender. If 
> the file checksums do not match the temp-file is deleted. If the file fails 
> once it will > be reprocessed in a second phase, and if it fails twice an 
> error is reported.
>
> After the temp-file has been completed, its ownership and permissions and 
> modification time are set. It is then renamed to replace the basis file.


Thanks,
-Alex

> Doug
>
> rsync: failed to set permissions on 
> "/afs/.openstack.org/docs/releasenotes/instack-undercloud/.pike.html.AEKeun": 
> No such file or directory (2)
> rsync: rename 
> "/afs/.openstack.org/docs/releasenotes/instack-undercloud/.pike.html.AEKeun" 
> -> "pike.html": No such file or directory (2)
> rsync error: some files/attrs were not transferred (see previous errors) 
> (code 23) at main.c(1183) [sender=3.1.1]
> Traceback (most recent call last):
>   File "/tmp/ansible_b5fr54k3/ansible_module_zuul_afs.py", line 115, in 
> 
> main()
>   File "/tmp/ansible_b5fr54k3/ansible_module_zuul_afs.py", line 110, in main
> output = afs_sync(p['source'], p['target'])
>   File "/tmp/ansible_b5fr54k3/ansible_module_zuul_afs.py", line 95, in 
> afs_sync
> output['output'] = subprocess.check_output(shell_cmd, shell=True)
>   File "/usr/lib/python3.5/subprocess.py", line 626, in check_output
> **kwargs).stdout
>   File "/usr/lib/python3.5/subprocess.py", line 708, in run
> output=stdout, stderr=stderr)
> subprocess.CalledProcessError: Command '/bin/bash -c "mkdir -p 
> /afs/.openstack.org/docs/releasenotes/instack-undercloud/ && /usr/bin/rsync 
> -rtp --safe-links --delete-after --out-format='<>%i %n%L' 
> --filter='merge /tmp/tmpcoywd87i' 
> /var/lib/zuul/builds/9440894ee812414bb2ae813da1bbdfdd/work/artifacts/ 
> /afs/.openstack.org/docs/releasenotes/instack-undercloud/"' returned non-zero 
> exit status 23
>
> __
> 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] Fwd: [nova][placement] Upgrade placement first!

[Matt Riedemann]

FYI


 Forwarded Message 
Subject: [openstack-dev] [nova][placement] Upgrade placement first!
Date: Mon, 26 Mar 2018 15:02:23 -0500
From: Eric Fried 
Reply-To: OpenStack Development Mailing List (not for usage questions) 


Organization: IBM
To: OpenStack Development Mailing List (not for usage questions) 



Since forever [0], nova has gently recommended [1] that the placement
service be upgraded first.

However, we've not made any serious effort to test scenarios where this
isn't done.  For example, we don't have grenade tests running placement
at earlier levels.

After a(nother) discussion [2] which touched on the impacts - real and
imagined - of running new nova against old placement, we finally decided
to turn the recommendation into a hard requirement [3].

This gives admins a crystal clear guideline, this lets us simplify our
support statement, and also means we don't have to do 406 fallback code
anymore.  So we can do stuff like [4], and also avoid having to write
(and subsequently remove) code like that in the future.

Please direct any questions to #openstack-nova

Your Faithful Scribe,
efried

[0] Like, since upgrading placement was a thing.
[1]
https://docs.openstack.org/nova/latest/user/upgrade.html#rolling-upgrade-process
(#2, first bullet)
[2]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-03-26.log.html#t2018-03-26T17:35:11
[3] https://review.openstack.org/556631
[4] https://review.openstack.org/556633

__
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] Tag of openstack/instack-undercloud failed

[Doug Hellmann]

Excerpts from zuul's message of 2018-03-26 18:11:49 +:
> Build failed.
> 
> - publish-openstack-releasenotes 
> http://logs.openstack.org/94/94bb28ae46bd263314c9d846069ca913d225e625/tag/publish-openstack-releasenotes/9440894/
>  : POST_FAILURE in 3m 29s
> 

This release notes build failure is probably not a problem, but I
don't recognize the cause of the error so I wanted to bring it up
in case someone else did.

Is the ".pike.html.AEKeun" a lock file of some sort? Or a temporary
file created for some other purpose?

Doug

rsync: failed to set permissions on 
"/afs/.openstack.org/docs/releasenotes/instack-undercloud/.pike.html.AEKeun": 
No such file or directory (2)
rsync: rename 
"/afs/.openstack.org/docs/releasenotes/instack-undercloud/.pike.html.AEKeun" -> 
"pike.html": No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 
23) at main.c(1183) [sender=3.1.1]
Traceback (most recent call last):
  File "/tmp/ansible_b5fr54k3/ansible_module_zuul_afs.py", line 115, in 
main()
  File "/tmp/ansible_b5fr54k3/ansible_module_zuul_afs.py", line 110, in main
output = afs_sync(p['source'], p['target'])
  File "/tmp/ansible_b5fr54k3/ansible_module_zuul_afs.py", line 95, in afs_sync
output['output'] = subprocess.check_output(shell_cmd, shell=True)
  File "/usr/lib/python3.5/subprocess.py", line 626, in check_output
**kwargs).stdout
  File "/usr/lib/python3.5/subprocess.py", line 708, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '/bin/bash -c "mkdir -p 
/afs/.openstack.org/docs/releasenotes/instack-undercloud/ && /usr/bin/rsync 
-rtp --safe-links --delete-after --out-format='<>%i %n%L' 
--filter='merge /tmp/tmpcoywd87i' 
/var/lib/zuul/builds/9440894ee812414bb2ae813da1bbdfdd/work/artifacts/ 
/afs/.openstack.org/docs/releasenotes/instack-undercloud/"' returned non-zero 
exit status 23

__
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] Any reason why not have 'choices' parameter for ListOpt()?

[Doug Hellmann]

Excerpts from melanie witt's message of 2018-03-26 12:28:02 -0700:
> On Mon, 26 Mar 2018 14:12:52 -0500, Matt Riedemann wrote:
> > On 3/26/2018 6:24 AM, ChangBo Guo wrote:
> >> What's your use case for ListOpt, just make sure the value(a list) is
> >> part of  'choices' ?   Maybe we need another parameter to distinguish
> > 
> > It came up because of this change in nova:
> > 
> > https://review.openstack.org/#/c/534384/
> > 
> > We want to backport that as a bug fix which is a mitigation for
> > performance degradation issues with QEMU patches for Spectre and Meltdown.
> > 
> > However, in the backport we wanted to restrict the ListOpt to a single
> > value, "pcid". The idea is to restrict the new option to a single value
> > in stable branches.
> > 
> > Then in master, we could remove the 'choices' kwarg so operators can
> > define their list as they wish.
> > 
> > If we were do implement this generically in ListOpt, I suppose 'choices'
> > would mean that the specified list must be a subset of the defined
> > choices list. So in the backport patch, we'd just have choices=[None,
> > 'pcid'] and you can either specify None or 'pcied' for that option
> > (default to None).
> > 
> > Right now the code that's relying on this option just has a hard-coded
> > check for the value which is OK.
> 
> I'm not sure if this helps, but we do already have some example of a 
> ListOpt with 'choices' for the VNC auth_schemes:
> 
> https://github.com/openstack/nova/blob/cd15c3d/nova/conf/vnc.py#L229
> 
> Could we do something similar for the backport of the CPU flags patch?
> 
> -melanie
> 

Oh, look, another feature that's already in the library. :-)

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

Re: [openstack-dev] [oslo] Any reason why not have 'choices' parameter for ListOpt()?

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2018-03-26 14:12:52 -0500:
> On 3/26/2018 6:24 AM, ChangBo Guo wrote:
> > What's your use case for ListOpt, just make sure the value(a list) is 
> > part of  'choices' ?   Maybe we need another parameter to distinguish
> 
> It came up because of this change in nova:
> 
> https://review.openstack.org/#/c/534384/
> 
> We want to backport that as a bug fix which is a mitigation for 
> performance degradation issues with QEMU patches for Spectre and Meltdown.
> 
> However, in the backport we wanted to restrict the ListOpt to a single 
> value, "pcid". The idea is to restrict the new option to a single value 
> in stable branches.
> 
> Then in master, we could remove the 'choices' kwarg so operators can 
> define their list as they wish.

So we would have to backport a feature to oslo.config to allow a list to
have choices?

> 
> If we were do implement this generically in ListOpt, I suppose 'choices' 
> would mean that the specified list must be a subset of the defined 
> choices list. So in the backport patch, we'd just have choices=[None, 
> 'pcid'] and you can either specify None or 'pcied' for that option 
> (default to None).

What does it mean if they set the option to a list containing both
values?

> 
> Right now the code that's relying on this option just has a hard-coded 
> check for the value which is OK.
> 

__
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][placement] Upgrade placement first!

[Eric Fried]

Since forever [0], nova has gently recommended [1] that the placement
service be upgraded first.

However, we've not made any serious effort to test scenarios where this
isn't done.  For example, we don't have grenade tests running placement
at earlier levels.

After a(nother) discussion [2] which touched on the impacts - real and
imagined - of running new nova against old placement, we finally decided
to turn the recommendation into a hard requirement [3].

This gives admins a crystal clear guideline, this lets us simplify our
support statement, and also means we don't have to do 406 fallback code
anymore.  So we can do stuff like [4], and also avoid having to write
(and subsequently remove) code like that in the future.

Please direct any questions to #openstack-nova

Your Faithful Scribe,
efried

[0] Like, since upgrading placement was a thing.
[1]
https://docs.openstack.org/nova/latest/user/upgrade.html#rolling-upgrade-process
(#2, first bullet)
[2]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-03-26.log.html#t2018-03-26T17:35:11
[3] https://review.openstack.org/556631
[4] https://review.openstack.org/556633

__
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] Any reason why not have 'choices' parameter for ListOpt()?

[melanie witt]

On Mon, 26 Mar 2018 14:12:52 -0500, Matt Riedemann wrote:

On 3/26/2018 6:24 AM, ChangBo Guo wrote:

What's your use case for ListOpt, just make sure the value(a list) is
part of  'choices' ?   Maybe we need another parameter to distinguish


It came up because of this change in nova:

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

We want to backport that as a bug fix which is a mitigation for
performance degradation issues with QEMU patches for Spectre and Meltdown.

However, in the backport we wanted to restrict the ListOpt to a single
value, "pcid". The idea is to restrict the new option to a single value
in stable branches.

Then in master, we could remove the 'choices' kwarg so operators can
define their list as they wish.

If we were do implement this generically in ListOpt, I suppose 'choices'
would mean that the specified list must be a subset of the defined
choices list. So in the backport patch, we'd just have choices=[None,
'pcid'] and you can either specify None or 'pcied' for that option
(default to None).

Right now the code that's relying on this option just has a hard-coded
check for the value which is OK.


I'm not sure if this helps, but we do already have some example of a 
ListOpt with 'choices' for the VNC auth_schemes:


https://github.com/openstack/nova/blob/cd15c3d/nova/conf/vnc.py#L229

Could we do something similar for the backport of the CPU flags patch?

-melanie


__
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] Any reason why not have 'choices' parameter for ListOpt()?

[Matt Riedemann]

On 3/26/2018 6:24 AM, ChangBo Guo wrote:
What's your use case for ListOpt, just make sure the value(a list) is 
part of  'choices' ?   Maybe we need another parameter to distinguish


It came up because of this change in nova:

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

We want to backport that as a bug fix which is a mitigation for 
performance degradation issues with QEMU patches for Spectre and Meltdown.


However, in the backport we wanted to restrict the ListOpt to a single 
value, "pcid". The idea is to restrict the new option to a single value 
in stable branches.


Then in master, we could remove the 'choices' kwarg so operators can 
define their list as they wish.


If we were do implement this generically in ListOpt, I suppose 'choices' 
would mean that the specified list must be a subset of the defined 
choices list. So in the backport patch, we'd just have choices=[None, 
'pcid'] and you can either specify None or 'pcied' for that option 
(default to None).


Right now the code that's relying on this option just has a hard-coded 
check for the value which is OK.


--

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-dev] [tripleo][oslo] messaging services update

[Andy Smith]

Hi,

I wanted to provide an update on the work that has been ongoing to
enhance the deployment of messaging system backends for RPC and
Notify communications.

https://blueprints.launchpad.net/tripleo/+spec/tripleo-messaging

The basis of the change is to introduce oslo messaging RPC and
Notify services in place of the rabbitmq server settings. This will
enable tripleo to continue to deploy a single messaging backend (e.g.
clustered rabbitmq server) but will also provide the ability to
configure separate messaging backends for each oslo messaging
service. The ability to separate the messaging services has been
supported since the newton release and can result in increased
performance, scalability and reliability of an OpenStack deployment.
In addition, it facilitates the use of alternative messaging
backend systems supported by oslo messaging.

Summary of the changes:

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

tripleo-common changes to introduce separate RPC and Notify users
and passwords for distinct messaging transports

2. https://review.openstack.org/#/c/522406/

This first puppet-tripleo patch supports both current master and
tripleo-heat-templates update below. Patch only works with a single
messaging backend and is needed to transition through CI properly.

3. https://review.openstack.org/#/c/507963/

tripleo-heat-templates update to introduce oslo messaging services
in place of rabbitmq server settings. The patch supports separate
RPC and Notify communications via the full set of parameters needed
to define independent transports.

4. https://review.openstack.org/#/c/510684/

This second puppet-tripleo patch supports separate RPC and Notify
oslo messaging services.

In addition to CI, we have performed numerous local test
deployments across the combination of patch sets and messaging
backends. The deployments include single rabbitmq backends as well as
hybrid deployments that use qdrouterd for RPC and rabbitmq for
Notifications.

We seek as much comments and feedback as possible to ensure that the
changes introduced are transparent to the core services and that there
is no impact on the universal deployment and operation of the rabbitmq
backend server.

The goal is to land these changes in Rocky-1 so that we can maximize
the amout of testing during the release cycle.

Thanks,
Andy
__
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] EC2 cleanup ?

[Artom Lifshitz]

> That is easier said than done. There have been a couple of related attempts
> in the past:
>
> https://review.openstack.org/#/c/266425/
>
> https://review.openstack.org/#/c/282872/
>
> I don't remember exactly where those fell down, but it's worth looking at
> this first before trying to do this again.

Interesting. [1] exists, and I'm pretty sure that we ship it as part
of Red Hat OpenStack (but I'm not a PM and this is not an official Red
Hat stance, just me and my memory), so it works well enough. If we
have things that depend on our in-tree ec2 api, maybe we need to get
them moved over to [1]?

[1] https://github.com/openstack/ec2-api

__
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] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)


Weekly priorities
-
- Deploy Steps
- https://review.openstack.org/#/c/549493/ 1x+2 and 1x-1
- Remaining Rescue patches
- https://review.openstack.org/#/c/546919/ - Fix a bug for unrescuiing with 
whole disk image
- better fix: https://review.openstack.org/#/c/499050/  - Fix ``agent`` 
deploy interface to call ``boot.prepare_instance`` Updated 19-Mar-2018.
- https://review.openstack.org/#/c/538119/ - Rescue mode standalone tests
- https://review.openstack.org/#/c/528699/ - Tempest tests with nova (This 
can land after nova work is done. But, it should be ready to get the nova patch 
reviewed.)
- Management interface boot_mode change
- https://review.openstack.org/#/c/526773/
- Bios interface support
- https://review.openstack.org/#/c/511162/
- https://review.openstack.org/#/c/528609/

Vendor priorities
-
cisco-ucs:
Patches in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:
RFE and first several patches for adding UEFI support will be posted by 
Tuesday, 1/9
ilo:
https://review.openstack.org/#/c/530838/ - OOB Raid spec for iLO5
irmc:
None - a few works are work in progress
oneview:
None at this time - No subteam at present.
xclarity:

Subproject priorities
-
bifrost:

ironic-inspector (or its client):

networking-baremetal:

networking-generic-switch:

sushy and the redfish driver:


Bugs (dtantsur, vdrok, TheJulia)

- (TheJulia) Ironic has moved to Storyboard. Dtantsur has indicated he will 
update the tool that generates these stats.
- Stats (diff between  12 Mar 2018 and 19 Mar 2018)
- Ironic: 225 bugs (+14) + 250 wishlist items (+2). 15 new (+10), 152 in 
progress, 1 critical, 36 high (+3) and 26 incomplete (+2)
- Inspector: 15 bugs (+1) + 26 wishlist items. 1 new (+1), 14 in progress, 0 
critical, 3 high and 4 incomplete
- Nova bugs with Ironic tag: 14 (-1). 1 new, 0 critical, 0 high
- critical:
- sushy: https://bugs.launchpad.net/sushy/+bug/1754514 (basic auth broken 
when SessionService is not present)
- note: the increase in bug count is probably because now the dashboard tracks 
virtualbmc and networking-baremetal
- the dashboard was abruptly deleted and needs a new home :(
- use it locally with `tox -erun` if you need to
- HIGH bugs with patches to review:
- Clean steps are not tested in gate 
https://bugs.launchpad.net/ironic/+bug/1523640: Add manual clean step ironic 
standalone test https://review.openstack.org/#/c/429770/15
- Needs to be reproposed to the ironic tempest plugin repository.
- prepare_instance() is not called for whole disk images with 'agent' deploy 
interface https://bugs.launchpad.net/ironic/+bug/1713916:
- Fix ``agent`` deploy interface to call ``boot.prepare_instance`` 
https://review.openstack.org/#/c/499050/
- (TheJulia) Currently WF-1, as revision is required for deprecation.

Priorities
==

Deploy Steps (rloo, mgoddard)
-
- status as of 26 March 2018:
- spec for deployment steps framework: 
https://review.openstack.org/#/c/549493/
- ready for reviews, 1 +2 already (but might need another update)

BIOS config framework(zshi, yolanda, mgoddard, hshiina)
---
- status as of 26 March 2018:
- Spec has merged: https://review.openstack.org/#/c/496481/
- List of ordered patches:
- BIOS Settings: Add DB model: https://review.openstack.org/511162
- Add bios_interface db field https://review.openstack.org/528609
- BIOS Settings: Add DB API: https://review.openstack.org/511402
- BIOS Settings: Add RPC object https://review.openstack.org/511714
- Add BIOSInterface to base driver class 
https://review.openstack.org/507793
- BIOS Settings: Add BIOS caching: https://review.openstack.org/512200
- Add Node BIOS support - REST API: https://review.openstack.org/512579

Conductor Location Awareness (jroll, dtantsur)
--
- no update, will write spec soonish

Reference architecture guide (dtantsur, jroll)
--
- status as of 26 Mar 2018:
- Dublin PTG consensus was to start with small architectural building 
blocks.
- basic architecture explanation: https://review.openstack.org/554284 
MERGED
- list of cases from the Denver PTG
- Admin-only provisioner
- small and/or rare: TODO
- non-HA acceptable, noop/flat network acceptable
- large and/or frequent: TODO
- HA required, neutron 

[openstack-dev] [Blazar] skip weekly meeting

[Masahito MUROI]

Hi Blazar folks,

As we talked in last meeting, this weekly meeting is skipped because 
most of the team members are out of office.


best regards,
Masahito


__
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] proposing Ken Giusti for oslo-core

[Joshua Harlow]

+1

Ben Nemec wrote:

+1!

On 03/26/2018 10:52 AM, Doug Hellmann wrote:

Ken has been managing oslo.messaging for ages now but his participation
in the team has gone far beyond that single library. He regularly
attends meetings, including the PTG, and has provided input into several
of our team decisions recently.

I think it's time we make him a full member of the oslo-core group.

Please respond here with a +1 or -1 to indicate your opinion.

Thanks,
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 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] New PBR release coming soon

[Ben Nemec]

Hi,

Since this will potentially affect the majority of OpenStack projects, I 
wanted to give everyone some advance notice.  PBR[1] hasn't been 
released since last summer, and as a result none of the bug fixes or new 
features that have gone in since then are available to users.  Because 
of some feature removals that have happened, this will be a major 
release and due to the number of changes since the last release there's 
a higher probability of issues.


We want to get this potentially painful release out of the way early in 
the cycle and then resume regular releases going forward.  If you know 
of any reason we shouldn't do this right now please respond ASAP.


Thanks.

-Ben

1: https://docs.openstack.org/pbr/latest/

__
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] proposing Ken Giusti for oslo-core

[Ben Nemec]

+1!

On 03/26/2018 10:52 AM, Doug Hellmann wrote:

Ken has been managing oslo.messaging for ages now but his participation
in the team has gone far beyond that single library. He regularly
attends meetings, including the PTG, and has provided input into several
of our team decisions recently.

I think it's time we make him a full member of the oslo-core group.

Please respond here with a +1 or -1 to indicate your opinion.

Thanks,
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] [glance] Priorities for WC 26th of March

[Erno Kuvaja]

Hi all,

Time for the priority update:

The python-glanceclient release was postponed til this week due to
some bugs Brian found and is in process of fixing. Lets review these
and see what we need for the release, so we can get it out this week.

The R-1 Milestone is approaching quickly so I would like everyone to
look at our roadmap etherpad and have our R-1 targets fresh in mind:
https://etherpad.openstack.org/p/glance-rocky-priorities

Give your feedback to the rest open specs we have in flight, specially
the OSSN-0075 one https://review.openstack.org/#/c/468179

Remember that Easter is at the coming weekend for those of us who are
affected by it, meaning that this and next week may be short for many.

Have a amazing and effective week!

- Erno jokke Kuvaja

__
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] proposing Ken Giusti for oslo-core

[Davanum Srinivas]

w00t! yes please +1

On Mon, Mar 26, 2018 at 11:53 AM, Jay Pipes  wrote:
> Big +1.
>
>
> On 03/26/2018 11:52 AM, Doug Hellmann wrote:
>>
>> Ken has been managing oslo.messaging for ages now but his participation
>> in the team has gone far beyond that single library. He regularly
>> attends meetings, including the PTG, and has provided input into several
>> of our team decisions recently.
>>
>> I think it's time we make him a full member of the oslo-core group.
>>
>> Please respond here with a +1 or -1 to indicate your opinion.
>>
>> Thanks,
>> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo] proposing Ken Giusti for oslo-core

[Doug Hellmann]

Ken has been managing oslo.messaging for ages now but his participation
in the team has gone far beyond that single library. He regularly
attends meetings, including the PTG, and has provided input into several
of our team decisions recently.

I think it's time we make him a full member of the oslo-core group.

Please respond here with a +1 or -1 to indicate your opinion.

Thanks,
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

Re: [openstack-dev] [oslo] proposing Ken Giusti for oslo-core

[Jay Pipes]

Big +1.

On 03/26/2018 11:52 AM, Doug Hellmann wrote:

Ken has been managing oslo.messaging for ages now but his participation
in the team has gone far beyond that single library. He regularly
attends meetings, including the PTG, and has provided input into several
of our team decisions recently.

I think it's time we make him a full member of the oslo-core group.

Please respond here with a +1 or -1 to indicate your opinion.

Thanks,
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] [all][oslo] Notice to users of the ZeroMQ transport in oslo.messaging

[Ken Giusti]

Folks,

It's been over a year since the last commit was made to the ZeroMQ
driver in oslo.messaging.  It is at the point where some of the
related unit tests are beginning to fail due to bit rot.  None of the
current oslo.messaging contributors have a good enough understanding
of the codebase to effectively fix it.

Personally I'm not sure the driver will work in production at all.

Given this it was decided in Dublin that the ZeroMQ driver no longer
meets the official policy for in tree driver support [0] and will be
deprecated in Rocky.  However it would be insincere for the team to
give the impression that the driver is maintained for the normal 2
cycle deprecation process.  Therefore the driver code will be removed
in 'S'.

The ZeroMQ driver is the largest body of code of any driver in the
oslo.messaging repo, weighing in at over 5k lines of code.  For
comparison, the rabbitmq kombu driver consists of only about 2K lines
of code.  If any individuals are willing to commit to ownership of
this codebase and keep the driver compliant with policy (see [0]),
please follow up with bnemec or myself (kgiusti) on #openstack-oslo.

Thanks,


[0] 
https://docs.openstack.org/oslo.messaging/latest/contributor/supported-messaging-drivers.html


-- 
Ken Giusti  (kgiu...@gmail.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] [kolla] Kolla-Ansible pip packages vulnerable to CVE-2018-1000115

[Jeffrey Zhang]

Hi Mathieu,

Thanks for raising this issue.

The patch is merged on all branches but not released[0].We will release the
next release ASAP.

But on the other hand, if you build an OpenStack cloud through kolla and be
accessible through
the internet, you'd better use an external network(interface) for internet
access. There are lots of port
enabled on the internal network. like MariaDB, Memcached.

[0]
https://review.openstack.org/#/q/I30acb41f1209c0d07eb58f4feec91bc53146dcea

On Mon, Mar 26, 2018 at 10:36 PM, Mathieu Goessens <
mathieu.goess...@imt-atlantique.fr> wrote:

> Hi folks,
>
> I initially sent this mail privately, resending it to the list on request :
>
> Kolla-Ansible https://docs.openstack.org/kolla-ansible/ pip packages
> (recommended in the doc) are vulnerable to CVE-2018-1000115.
>
> The patch have been commit, merged in stable/queens, stable/pike,
> stable/ocata https://review.openstack.org/#/c/550686/. However, the pip
> stable packages are still based on 5.0.1 which do not contain the fix
> (6.0.0.0rc2 which contains the fix is available in pip, but won't be
> installed by default because its a prerelease).
>
> While I understand that good security practices would recommend to
> firewall etc, and that the fixes are available, I believe having
> vulnerable packages in the default, recommend install, is an important
> issue.
>
> Moreover, I would like to suggest issuing a Security Advisory when
> updated packages would be available, because :
> - pip/system won't propose upgrades by default, users may not be aware
> they are vulnerable.
> - users can actually being hit by CVE-2018-1000115 and participate to DDOS.
> - DDOS traffic pattern observed in my cloud are not big burst ones, but
> follow some classic daily pattern that could looks legitimate and so
> could stay unnoticeable for a long time (see graph,
> http://pix.toile-libre.org/?img=1522070903.png, mostly if not only DDOS
> traffic in)
>
> -
> How to verify :
>
> git clone https://github.com/openstack/kolla-ansible ; cd kolla-ansible
>
> git checkout tags/6.0.0.0rc2 ; git log | grep "Security memcached"
>
> git checkout tags/5.0.1 ; git log | grep "Security memcached"
>
>
> wget
> https://pypi.python.org/packages/cc/f2/27d9e75f2fe142b2a73c57023b055a
> a9a50e49ba69d7da9c7808c4f25ac1/kolla-ansible-5.0.1.tar.gz#md5=
> 6456618318b58d844ae57b47e34ee569
>
> tar xvzf kolla-ansible-5.0.1.tar.gz
>
> cat kolla-ansible-5.0.1/ansible/roles/memcached/templates/
> memcached.json.j2
>
> (compare with https://review.openstack.org/#/c/550686/ if needed)
>
>
> Cheers,
> --
> Mathieu Goessens
> Research Engineer
> IMT Atlantique
>
>
> __
> 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
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [kolla] Kolla-Ansible pip packages vulnerable to CVE-2018-1000115

[Mathieu Goessens]

Hi folks,

I initially sent this mail privately, resending it to the list on request :

Kolla-Ansible https://docs.openstack.org/kolla-ansible/ pip packages
(recommended in the doc) are vulnerable to CVE-2018-1000115.

The patch have been commit, merged in stable/queens, stable/pike,
stable/ocata https://review.openstack.org/#/c/550686/. However, the pip
stable packages are still based on 5.0.1 which do not contain the fix
(6.0.0.0rc2 which contains the fix is available in pip, but won't be
installed by default because its a prerelease).

While I understand that good security practices would recommend to
firewall etc, and that the fixes are available, I believe having
vulnerable packages in the default, recommend install, is an important
issue.

Moreover, I would like to suggest issuing a Security Advisory when
updated packages would be available, because :
- pip/system won't propose upgrades by default, users may not be aware
they are vulnerable.
- users can actually being hit by CVE-2018-1000115 and participate to DDOS.
- DDOS traffic pattern observed in my cloud are not big burst ones, but
follow some classic daily pattern that could looks legitimate and so
could stay unnoticeable for a long time (see graph,
http://pix.toile-libre.org/?img=1522070903.png, mostly if not only DDOS
traffic in)

-
How to verify :

git clone https://github.com/openstack/kolla-ansible ; cd kolla-ansible

git checkout tags/6.0.0.0rc2 ; git log | grep "Security memcached"

git checkout tags/5.0.1 ; git log | grep "Security memcached"


wget
https://pypi.python.org/packages/cc/f2/27d9e75f2fe142b2a73c57023b055aa9a50e49ba69d7da9c7808c4f25ac1/kolla-ansible-5.0.1.tar.gz#md5=6456618318b58d844ae57b47e34ee569

tar xvzf kolla-ansible-5.0.1.tar.gz

cat kolla-ansible-5.0.1/ansible/roles/memcached/templates/memcached.json.j2

(compare with https://review.openstack.org/#/c/550686/ if needed)


Cheers,
-- 
Mathieu Goessens
Research Engineer
IMT Atlantique



signature.asc
Description: OpenPGP digital 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

[openstack-dev] [all] Vancouver Forum - Topic submission tool is now open!

[Thierry Carrez]

Hi everyone,

The Forum in Vancouver is getting closer! As a reminder, the Forum is
where we take advantage of having a large community presence at the
Summit to discuss and get wide feedback on a variety of topics around
the future of OpenStack and adjacent projects.

Starting today, our submission tool is open for you to submit abstracts
for the most popular sessions that came out of your brainstorming.

All teams, work groups and SIGs should now submit their abstracts at:

http://forumtopics.openstack.org/

before 11:59PM UTC on Sunday April 15th!

We are looking for a good mix of project-specific, cross-project or
strategic/whole-of-community discussions, and sessions that emphasis
collaboration between our various types of contributors are most welcome!

We assume that anything submitted to the system has achieved a good
amount of discussion and consensus that it's a worthwhile topic. After
submissions close, a team of representatives from the User Committee,
the Technical Committee and Foundation staff will take the sessions
proposed by the community and fill out the schedule.

You can expect the draft schedule to be released around April 22nd.

Further details about the Forum can be found at:
https://wiki.openstack.org/wiki/Forum

Regards,

-- 
Thierry Carrez (ttx)

__
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] [stable][release] Remove complex ACL changes around releases

[Thierry Carrez]

Hi!

TL;DR:
We used to do complex things with ACLs for stable/* branches around
releases. Let's stop doing that as it's not really useful anyway, and
just trust the $project-stable-maint teams to do the right thing.


Current situation:

As we get close to the end of a release cycle, we start creating
stable/$series branches to refine what is likely to become a part of the
coordinated release at the end of the cycle. After release, that same
stable/$series branch is used to backport fixes and issue further point
releases.

The rules to apply for approving changes to stable/$series differ
slightly depending on whether you are pre-release or post-release. To
reflect that, we use two different groups. Pre-release the branch is
controlled by the $project-release group (and Release Managers) and
post-release the branch is controlled by the $project-stable-maint group
(and stable-maint-core).

To switch between the two without blocking on an infra ACL change, the
release team enters a complex dance where we initially create an ACL for
stable/$series, giving control of it to a $project-release-branch group,
whose membership is reset at every cycle to contain $project-release. At
release time, we update $project-release-branch Gerrit group membership
to contain $project-stable-maint instead. Then we get rid of the
stable/$series ACL altogether.

This process is a bit complex and error-prone (and we tend to have to
re-learn it every cycle). It's also designed for a time when we expected
completely-different people to be in -release and -stable-maint groups,
while those are actually, most of the time, the same people.
Furthermore, with more and more deliverables being released under the
cycle-with-intermediary model, pre-release and post-release approval
rules are actually more and more of the same.

Proposal:

By default, let's just have $project-stable-maint control stable/*. We
no longer create new ACLs for stable/$series every cycle, we no longer
switch from $project-release control to $project-stable-maint control.
The release team no longer does anything around stable branch ACLs or
groups during the release cycle.

That way, the same group ends up being used to control stable/*
pre-release and post-release. They were mostly the same people already:
Release managers are a part of stable-maint-core, which is included in
every $project-stable-maint anyway, so they retain control.

What that changes for you:

If you are part of $project-release but not part of
$project-stable-maint, you'll probably want to join that team. If you
review pre-release changes on a stable branch for a
cycle-with-milestones deliverable, you will have to remember that the
rules there are slightly different from stable branch approval rules. In
doubt, do not approve, and ask.

But I don't like that! I prefer tight ACLs!

While we do not recommend it, every team can still specify more complex
ACLs to control their stable branches. As long as the "Release Managers"
group retains ability to approve changes pre-release (and
stable-maint-core retains ability to approve changes post-release), more
specific ACLs are fine.

Let me know if you have any comment, otherwise we'll start using that
new process for the Rocky cycle (stable/rocky branch).

Thanks !

-- 
Thierry Carrez (ttx)

__
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-ansible] Stepping down from OpenStack-Ansible core

[Major Hayden]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey there,

As promised, I am stepping down from being an OpenStack-Ansible core reviewer 
since I am unable to meet the obligations of the role with my new job. :(

Thanks to everyone who has mentored me along the way and put up with my gate 
job breakages. I have learned an incredible amount about OpenStack, Ansible, 
complex software deployments, and open source communities. I appreciate 
everyone's support as I worked through the creation of the ansible-hardening 
role as well as adding CentOS support for OpenStack-Ansible.

- --
Major Hayden
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEG/mSZJWWADNpjCUrc3BR4MEBH7EFAlq4774ACgkQc3BR4MEB
H7E+gA/9HJEDibsQhdy191NbxbhF75wUup3gRDHhGPI6eFqHo/Iz8Q5Kv9Z9CXbo
rkBGMebbGzoKwiLnKbFWr448azMJkj5/bTRLHb1eDQg2S2xaywP2L4e0CU+Gouto
DucmGT6uLg+LKdQByYTB8VAHelub4DoxV2LhwsH+uYgWp6rZ2tB2nEIDTYQihhGx
/WukfG+3zA99RZQjWRHmfnb6djB8sONzGIM8qY4qDUw9Xjp5xguHOU4+lzn4Fq6B
cEpsJnztuEYnEpeTjynu4Dc8g+PX8y8fcObhcj+1D0NkZ1qW7sdX6CA64wuYOqec
S552ej/fR5FPRKLHF3y8rbtNIlK5qfpNPE4UFKuVLjGSTSBz4Kp9cGn2jNCzyw5c
aDQs/wQHIiUECzY+oqU1RHZJf9/Yq1VVw3vio+Dye1IMgkoaNpmX9lTcNw9wb1i7
lac+fm0e438D+c+YZAttmHBCCaVWgKdGxH7BY84FoQaXRcaJ9y3ZoDEx6Rr8poBQ
pK4YjUzVP9La2f/7S1QemX2ficisCbX+MVmAX9G4Yr9U2n98aXVWFMaF4As1H+OS
zm9r9saoAZr6Z8BxjROjoClrg97RN1zkPseUDwMQwlJwF3V33ye3ib1dYWRr7BSm
zAht+Jih/JE6Xtp+5UEF+6TBCYFVtXO8OHzCcac14w9dy1ur900=
=fx64
-END 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] [ALL][PTLs] [Community goal] Toggle the debug option at runtime

[Sławomir Kapłoński]

Hi,


> Wiadomość napisana przez ChangBo Guo  w dniu 26.03.2018, 
> o godz. 14:15:
> 
> 
> 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński :
> Hi,
> 
> I took care of implementation of [1] in Neutron and I have couple questions 
> to about this goal.
> 
> 1. Should we only change "restart_method" to mutate as is described in [2] ? 
> I did already something like that in [3] - is it what is expected?
> 
>  Yes , let's the only  thing.  we need test if that if it works .

Ok, so please take a look at my patch for neutron if that is what we should do 
:)

> 
> 2. How I can check if this change is fine and config option are mutable 
> exactly? For now when I change any config option for any of neutron agents 
> and send SIGHUP to it it is in fact "restarted" and config is reloaded even 
> with this old restart method.
>  
> good question, we indeed thought this question when we proposal  the 
> goal.  But It seems difficult to test  that consuming projects like Neutron 
> automatically. 

I was asking rather about some manual test instead of automatic one.

> 
> 3. Should we add any automatic tests for such change also? Any examples of 
> such tests in other projects maybe?
>  There is no example for tests now, we only have some unit tests  in 
> oslo.service .
> 
> [1] 
> https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
> [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
> [3] https://review.openstack.org/#/c/554259/
> 
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
> 
> 
> __
> 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
> 
> 
> 
> -- 
> ChangBo Guo(gcb)
> Community Director @EasyStack
> __
> 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
Slawek Kaplonski
sla...@kaplonski.pl


__
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][PTLs] [Community goal] Toggle the debug option at runtime

[ChangBo Guo]

2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński :

> Hi,
>
> I took care of implementation of [1] in Neutron and I have couple
> questions to about this goal.
>
> 1. Should we only change "restart_method" to mutate as is described in [2]
> ? I did already something like that in [3] - is it what is expected?
>

 Yes , let's the only  thing.  we need test if that if it works .

>
> 2. How I can check if this change is fine and config option are mutable
> exactly? For now when I change any config option for any of neutron agents
> and send SIGHUP to it it is in fact "restarted" and config is reloaded even
> with this old restart method.
>

good question, we indeed thought this question when we proposal  the
goal.  But It seems difficult to test  that consuming projects like Neutron
automatically.

>
> 3. Should we add any automatic tests for such change also? Any examples of
> such tests in other projects maybe?
>
 There is no example for tests now, we only have some unit tests  in
oslo.service .

>
> [1] https://governance.openstack.org/tc/goals/rocky/enable-
> mutable-configuration.html
> [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
> [3] https://review.openstack.org/#/c/554259/
>
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
>
>
> __
> 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
>



-- 
ChangBo Guo(gcb)
Community Director @EasyStack
__
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] Any reason why not have 'choices' parameter for ListOpt()?

[ChangBo Guo]

There is no special reasons that ListOpt  doesn't  allow parameter,
PortOpt also uses parameter 'choices'.   PortOpt and StrOpt  only accept
one value  and use this parameter to double check value is valid which is
in the 'choices'.
What's your use case for ListOpt, just make sure the value(a list) is part
of  'choices' ?   Maybe we need another parameter to distinguish

2018-03-26 17:49 GMT+08:00 Kashyap Chamarthy :

> Hi there,
>
> I was looking at oslo_config/cfg.py[*], and the StrOpt() class has
> 'choices' parameter, to allow a sequence of valid values / tuples of
> valid values for descriptions.
>
> However, I don't see the same 'choices' parameter for the ListOpt()
> class.  Out of curiosity, is there a reason to not add it for ListOpt()
> too?
>
> [*] https://git.openstack.org/cgit/openstack/oslo.config/
> tree/oslo_config/cfg.py#n1271
>
> --
> /kashyap
>
> __
> 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
>



-- 
ChangBo Guo(gcb)
Community Director @EasyStack
__
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] [oslo] Any reason why not have 'choices' parameter for ListOpt()?

[Kashyap Chamarthy]

Hi there,

I was looking at oslo_config/cfg.py[*], and the StrOpt() class has
'choices' parameter, to allow a sequence of valid values / tuples of
valid values for descriptions.

However, I don't see the same 'choices' parameter for the ListOpt()
class.  Out of curiosity, is there a reason to not add it for ListOpt()
too?

[*] 
https://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/cfg.py#n1271

-- 
/kashyap

__
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][ThirdParty-CI] Nova s390x CI back online

[Andreas Scheuring]

Hi,
with the latest release of pyroute2 I could bring the s390x CI is back online 
again. I now start rechecking all the missed patches…

There introduction of pyroute2 in Neutron broke Neutron DHCP and L3 agent on 
s390x. pyroute2 was simply missing s390x enablement. It got added with patch 
[1].

[1] 
https://github.com/svinota/pyroute2/commit/02328faf0de10073bc9e71d593b1656db62f6f6b

---
Andreas Scheuring (andreas_s)



On 14. Mar 2018, at 17:29, Andreas Scheuring  
wrote:

A brief update: The root cause is that Neutron patch [1] broke Neutron DHCP and 
L3 agent on s390x (both use pyroute2 for network namespace management now). The 
issue needs to get fixed in pyroute2 itself. I opened a PR [2]. Ideally a new 
version gets released soon.


[1] https://github.com/openstack/neutron/commit/c4d4336 

[2] https://github.com/svinota/pyroute2/pull/469 


---
Andreas Scheuring (andreas_s)



On 13. Mar 2018, at 17:14, Andreas Scheuring > wrote:

Hello, the s390x CI for nova is currently broken again. The reason seems to be 
a recent change that merged in neutron. I’m looking into it...

---
Andreas Scheuring (andreas_s)



__
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] [OpenStack-Ansible] Vancouver forum etherpad

[Jean-Philippe Evrard]

Dear OpenStack-Ansiblers,

We've got an etherpad here [1], to track all the things we want to
discuss at the forum.

if you're an OpenStack-Ansible user, don't hesitate to add your
session ideas, list what you liked or disliked in the last release,
and share your experience!

Thank you in advance.

[1]: https://etherpad.openstack.org/p/YVR-openstack-ansible-brainstorming

Best regards,
Jean-Philippe.

__
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] [telemetry][aodh][panko][oslo][performance] OSprofiler in Aodh & Panko

[vin...@vn.fujitsu.com]

Hello folks,

Just a reminder.

I have some patches related to OSProfiler that ready to review in Panko and 
Aodh.
Hope that you guys can leave a comment.

These patches are:
1. Aodh: https://review.openstack.org/#/c/483268/
2. Aodh client: https://review.openstack.org/#/c/484295/
3. Panko: https://review.openstack.org/#/c/483848/
4. Panko client: https://review.openstack.org/#/c/484294/

Thank you!

Best regards,

Vinh Nguyen Trong
PODC – Fujitsu Vietnam Ltd. 


> -Original Message-
> From: Nguyen, Trong Vinh
> Sent: Monday, 14 August, 2017 08:24
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>; Trong Vinh Nguyen (vin...@vn.fujitsu.com)
> 
> Subject: [openstack-dev][telemetry][aodh][panko][oslo][performance] 
> OSprofiler in
> Aodh & Panko
> 
> Hello,
> 
> I’m sending this email for asking about the work in integrating OSprofiler 
> into Aodh &
> Panko.
> Currently, there are some patches related to this work, and they are waiting 
> for review:
> 1. Aodh: https://review.openstack.org/#/c/483268/
> 2. Aodh client: https://review.openstack.org/#/c/484295/
> 3. Panko: https://review.openstack.org/#/c/483848/
> 4. Panko client: https://review.openstack.org/#/c/484294/
> 
> FYI, OSprofiler provides functionality to generate a trace per request, that 
> goes
> through all involve services.
> This trace can visualize flow of a request [1] [2].
> A trace from OSprofiler can help us know these things:
> - Performance bottle-neck of a service
> - Trouble-shooting issue in a service
> - Understanding flow of a request (from cli client or other client)
> - Trace can be store in persistent storage
> - Visualization trace flow in many OpenTracing compatible tracer [2] 
> (will be done
> soon)
> - Head, tail-based sampling for reducing overhead [3]
> - Asynchronous tracing [4]
> 
> OSprofiler has already been in most of main OpenStack services such as: Nova,
> Neutron, Keystone, Glance, and Cinder...
> 
> Hope that it will receive reviews from you all.
> 
> Thanks!
> 
> [1] Demo with current OSprofiler patch set in Swift:
> https://tovin07.github.io/swift/swift-object-create.html
> [2] A demo with OpenTracing compatible (using Uber Jaeger):
> https://tovin07.github.io/opentracing/jaeger-openstack-image-list.png
> [3] Tail-based coherent sampling: 
> https://blueprints.launchpad.net/osprofiler/+spec/tail-
> based-coherent-sampling
> [4] Asynchronous tracing:
> https://blueprints.launchpad.net/osprofiler/+spec/asynchronous-trace-collection
> [5] OSprofiler documentation: https://docs.openstack.org/osprofiler/latest/
> 
> Best regards,
> 
> Vinh Nguyen Trong
> PODC – Fujitsu Vietnam Ltd.
> 

__
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