[openstack-dev] [Searchlight] Searchlight was moved to Storyboard

[Trinh Nguyen]

Dear team,

Our bug tracker and blueprints were moved to Storyboard. So from now on,
please check them out here:
https://storyboard.openstack.org/#!/project_group/93

Enjoy the whole new world :)


*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *
__
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] [networking-odl][networking-bgpvpn][ceilometer] all requirement updates are currently blocked

[Matthew Thode]

The requirements project has a co-installability test for the various
projects, networking-odl being included.

Because of the way the dependancy on ceilometer is done it is blocking
all reviews and updates to the requirements project.

http://logs.openstack.org/96/594496/2/check/requirements-integration/8378cd8/job-output.txt.gz#_2018-08-31_22_54_49_357505

If networking-odl is not meant to be used as a library I'd recommend
it's removal from networking-bgpvpn (it's test-requirements.txt file).
Once that is done networking-odl can be removed from global-requirements
and we won't be blocked anymore.

As a side note, fungi noticed that when you branched you are still
installing ceilometer from master.  Also, the ceilometer team
doesnt wish it to be used as a library either (like networking-odl
doesn't wish to be used as a library).

-- 
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] [octavia] Proposing Carlos Goncalves (cgoncalves) as an Octavia core reviewer

[Slawomir Kaplonski]

Congratulation Carlos :)

> Wiadomość napisana przez Carlos Goncalves  w dniu 
> 31.08.2018, o godz. 20:36:
> 
> Thanks for the trust and opportunity, folks!
> 
> On Fri, Aug 31, 2018 at 7:59 PM, Michael Johnson  wrote:
> With a unanimous vote I would like to welcome Carlos to the Octavia Core team!
> 
> Michael
> 
> 
> On Fri, Aug 31, 2018 at 10:42 AM Adam Harwell  wrote:
> >
> > +1 for sure!
> >
> > On Sat, Sep 1, 2018, 01:41 Carlos Goncalves  wrote:
> >>
> >> Ha! Gracias for the kind words, Miguel! :-)
> >>
> >> On Fri, Aug 31, 2018 at 5:55 PM, Miguel Lavalle  
> >> wrote:
> >>>
> >>> Well, I don't vote here but I stiil want to express my +1. I knew this 
> >>> was going to happen sooner rather than later
> >>>
> >>> On Thu, Aug 30, 2018 at 10:24 PM, Michael Johnson  
> >>> wrote:
> 
>  Hello Octavia community,
> 
>  I would like to propose Carlos Goncalves as a core reviewer on the
>  Octavia project.
> 
>  Carlos has provided numerous enhancements to the Octavia project,
>  including setting up the grenade gate for Octavia upgrade testing.
> 
>  Over the last few releases he has also been providing quality reviews,
>  in line with the other core reviewers [1]. I feel that Carlos would
>  make an excellent 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
> >
> > __
> > 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] ?==?utf-8?q? [openstack-ansible] Stepping down from OpenStack-Ansible core

[jean-philippe]

On Thursday, August 30, 2018 19:40 CEST, Andy McCrae  
wrote: 
 
> Now that Rocky is all but ready it seems like a good time! Since changing
> roles I've not been able to keep up enough focus on reviews and other
> obligations - so I think it's time to step aside as a core reviewer.
> 
> I want to say thanks to everybody in the community, I'm really proud to see
> the work we've done and how the OSA team has grown. I've learned a tonne
> from all of you - it's definitely been a great experience.

Andy,

You've been there for the reshaping of OSA (splitting of repos, change of 
testing!), and always there when we needed you.
I'd like to thank you for your work.

I wish you all the best for your new role, and hope our paths will cross again 
soon!

Best regards,
Jean-Philippe Evrard (evrardjp)


__
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] Nominating Chris Dent for placement-core

[melanie witt]

On Fri, 31 Aug 2018 10:45:14 -0500, Eric Fried wrote:

The openstack/placement project [1] and its core team [2] have been
established in gerrit.

I hereby nominate Chris Dent for membership in the placement-core team.
He has been instrumental in the design, implementation, and stewardship
of the placement API since its inception and has shown clear and
consistent leadership.

As we are effectively bootstrapping placement-core at this time, it
would seem appropriate to consider +1/-1 responses from heavy placement
contributors as well as existing cores (currently nova-core).

[1]https://review.openstack.org/#/admin/projects/openstack/placement
[2]https://review.openstack.org/#/admin/groups/1936,members


+1




__
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] [keystone] Keystone Team Update - Week of 27 August 2018

[Lance Bragstad]

# Keystone Team Update - Week of 27 August 2018

## News

Welcome to Stein development!

## Release Status

Well, Rocky went out the door. A friendly reminder to keep an eye out for
bugs and things we should backport.

## PTG Planning

The topics in the PTG etherpad have been worked into a schedule [0].

The TL;DR is that Monday is going to be a mainly focused on large,
cross-project initiatives (just like what we did in Dublin). Tuesday we are
going to be discussing ways we can improve multi-region support
(edge-related discussions) and federation. Wednesday is relatively free of
topics, but we have a lot of hackathon ideas. This is a good time to
iterate quickly on things we need to get done, clean things up, or share
how something works with respect to keystone (e.g. Flask). Have an idea you
want to propose for Wednesday's hackathon? Just add it to the schedule [0].
Thursday is going to be for keystone-specific topics. Friday we plan to
cover any remaining topics and try and formalize everything into the
roadmap or specifications repo *before* we leave Denver.

If you have comments, questions, or concerns regarding the schedule, please
let someone know and we'll get it addressed.

[0] https://etherpad.openstack.org/p/keystone-stein-ptg

## Stein Roadmap Planning

Harry and I are working through the Rocky roadmap [0] and preparing a new
board for Stein. Most of this prep work should be done prior to the PTG so
that we can finalize and make adjustments in person. If you want to be
involved in this process just ask. Additionally, the Stein series has been
created in launchpad, along with the usual blueprints [1][2]. Feel free to
use accordingly for other blueprints and bugs.

[0] https://trello.com/b/wmyzbFq5/keystone-rocky-roadmap
[1] https://blueprints.launchpad.net/keystone/+spec/deprecated-as-of-stein
[2] https://blueprints.launchpad.net/keystone/+spec/removed-as-of-stein

## Open Specs

Search query: https://bit.ly/2Pi6dGj

We landed a couple cleanup patches that re-propose the MFA receipts [0] and
capability lists [1] specifications to Stein. Just a note to make sure we
treat those as living documents by updating them regularly if details
change as we work through the implementations.

The JWT specification [2] also received a facelift and is much more
specific than it was in the past. Please have a gander if you're
interested, or just curious. If the details are still unclear, just let us
know and we can get them proposed prior to PTG discussions in a couple
weeks.

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/stein/mfa-auth-receipt.html
[1]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/stein/capabilities-app-creds.html
[2] https://review.openstack.org/#/c/541903/

## Recently Merged Changes

Search query: https://bit.ly/2IACk3F

We merged 27 changes this week. We also got a good start on the python 3
community goal [0].

Note that there were some patches proposed for the community goal last
week, but the author wasn't listed as a champion for the goal and the
patches contained errors. We weren't able to reach the author and neither
were the goal champions. That said, those patches have been abandoned and
Doug reran the tooling to migrate our jobs. Just something to keep in mind
if you're reviewing those patches.

[0] https://governance.openstack.org/tc/goals/stein/python3-first.html

## Changes that need Attention

Search query: https://bit.ly/2wv7QLK

There are 61 changes that are passing CI, not in merge conflict, have no
negative reviews and aren't proposed by bots. We're making good progress on
the Flask reviews [0], but more reviews are always welcome.

[0]
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bug/1776504

## Bugs

This week we opened 4 new bugs and closed 1.

Bugs opened (4)

   - Bug #1789450 (keystone:Undecided) opened by Steven Relf
   https://bugs.launchpad.net/keystone/+bug/1789450


   - Bug #1789849 (keystone:Undecided) opened by Jean-
   https://bugs.launchpad.net/keystone/+bug/1789849


   - Bug #1790148 (keystone:Undecided) opened by FreudianSlip
   https://bugs.launchpad.net/keystone/+bug/1790148


   - Bug #1789351 (keystonemiddleware:Undecided) opened by yatin
   https://bugs.launchpad.net/keystonemiddleware/+bug/1789351


Bugs fixed (1)

   - Bug #1787874 (keystone:Medium) fixed by wangxiyuan
   https://bugs.launchpad.net/keystone/+bug/1787874


## Milestone Outlook

We have a lot of work to do to shape the release between now and milestone
1, which will be October 26th. Otherwise we'll be meeting in Denver in a
couple weeks.

https://releases.openstack.org/stein/schedule.html

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad:
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

Re: [openstack-dev] Nominating Chris Dent for placement-core

[Jay Pipes]

On 08/31/2018 11:45 AM, Eric Fried wrote:

The openstack/placement project [1] and its core team [2] have been
established in gerrit.

I hereby nominate Chris Dent for membership in the placement-core team.
He has been instrumental in the design, implementation, and stewardship
of the placement API since its inception and has shown clear and
consistent leadership.

As we are effectively bootstrapping placement-core at this time, it
would seem appropriate to consider +1/-1 responses from heavy placement
contributors as well as existing cores (currently nova-core).

[1] https://review.openstack.org/#/admin/projects/openstack/placement
[2] https://review.openstack.org/#/admin/groups/1936,members


+1

__
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] Nominating Chris Dent for placement-core

[Matt Riedemann]

On 8/31/2018 10:45 AM, Eric Fried wrote:

The openstack/placement project [1] and its core team [2] have been
established in gerrit.

I hereby nominate Chris Dent for membership in the placement-core team.
He has been instrumental in the design, implementation, and stewardship
of the placement API since its inception and has shown clear and
consistent leadership.

As we are effectively bootstrapping placement-core at this time, it
would seem appropriate to consider +1/-1 responses from heavy placement
contributors as well as existing cores (currently nova-core).

[1]https://review.openstack.org/#/admin/projects/openstack/placement
[2]https://review.openstack.org/#/admin/groups/1936,members


+1

--

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] [octavia] Proposing Carlos Goncalves (cgoncalves) as an Octavia core reviewer

[Carlos Goncalves]

Thanks for the trust and opportunity, folks!

On Fri, Aug 31, 2018 at 7:59 PM, Michael Johnson 
wrote:

> With a unanimous vote I would like to welcome Carlos to the Octavia Core
> team!
>
> Michael
>
>
> On Fri, Aug 31, 2018 at 10:42 AM Adam Harwell  wrote:
> >
> > +1 for sure!
> >
> > On Sat, Sep 1, 2018, 01:41 Carlos Goncalves 
> wrote:
> >>
> >> Ha! Gracias for the kind words, Miguel! :-)
> >>
> >> On Fri, Aug 31, 2018 at 5:55 PM, Miguel Lavalle 
> wrote:
> >>>
> >>> Well, I don't vote here but I stiil want to express my +1. I knew this
> was going to happen sooner rather than later
> >>>
> >>> On Thu, Aug 30, 2018 at 10:24 PM, Michael Johnson 
> wrote:
> 
>  Hello Octavia community,
> 
>  I would like to propose Carlos Goncalves as a core reviewer on the
>  Octavia project.
> 
>  Carlos has provided numerous enhancements to the Octavia project,
>  including setting up the grenade gate for Octavia upgrade testing.
> 
>  Over the last few releases he has also been providing quality reviews,
>  in line with the other core reviewers [1]. I feel that Carlos would
>  make an excellent 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
> >
> > 
> __
> > 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 Carlos Goncalves (cgoncalves) as an Octavia core reviewer

[Michael Johnson]

With a unanimous vote I would like to welcome Carlos to the Octavia Core team!

Michael


On Fri, Aug 31, 2018 at 10:42 AM Adam Harwell  wrote:
>
> +1 for sure!
>
> On Sat, Sep 1, 2018, 01:41 Carlos Goncalves  wrote:
>>
>> Ha! Gracias for the kind words, Miguel! :-)
>>
>> On Fri, Aug 31, 2018 at 5:55 PM, Miguel Lavalle  wrote:
>>>
>>> Well, I don't vote here but I stiil want to express my +1. I knew this was 
>>> going to happen sooner rather than later
>>>
>>> On Thu, Aug 30, 2018 at 10:24 PM, Michael Johnson  
>>> wrote:

 Hello Octavia community,

 I would like to propose Carlos Goncalves as a core reviewer on the
 Octavia project.

 Carlos has provided numerous enhancements to the Octavia project,
 including setting up the grenade gate for Octavia upgrade testing.

 Over the last few releases he has also been providing quality reviews,
 in line with the other core reviewers [1]. I feel that Carlos would
 make an excellent 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
>
> __
> 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 Carlos Goncalves (cgoncalves) as an Octavia core reviewer

[Adam Harwell]

+1 for sure!

On Sat, Sep 1, 2018, 01:41 Carlos Goncalves  wrote:

> Ha! Gracias for the kind words, Miguel! :-)
>
> On Fri, Aug 31, 2018 at 5:55 PM, Miguel Lavalle 
> wrote:
>
>> Well, I don't vote here but I stiil want to express my +1. I knew this
>> was going to happen sooner rather than later
>>
>> On Thu, Aug 30, 2018 at 10:24 PM, Michael Johnson 
>> wrote:
>>
>>> Hello Octavia community,
>>>
>>> I would like to propose Carlos Goncalves as a core reviewer on the
>>> Octavia project.
>>>
>>> Carlos has provided numerous enhancements to the Octavia project,
>>> including setting up the grenade gate for Octavia upgrade testing.
>>>
>>> Over the last few releases he has also been providing quality reviews,
>>> in line with the other core reviewers [1]. I feel that Carlos would
>>> make an excellent 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
>
__
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] Bumping eventlet to 0.24.1

[Ben Nemec]

Just a heads up that for oslo.service we're going to need 
https://review.openstack.org/#/c/598384 and 
https://review.openstack.org/#/c/599032/1 for eventlet 0.24.1 
compatibility. There aren't any functional issues as far as I can tell, 
but some unit tests were broken by new behavior.


On 08/23/2018 09:50 AM, Matthew Thode wrote:

This is your warning, if you have concerns please comment in
https://review.openstack.org/589382 .  cross tests pass, so that's a
good sign... atm this is only for stein.



__
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] [all] Bringing the community together (combine the lists!)

[Jeremy Stanley]

On 2018-08-31 14:02:23 +0200 (+0200), Thomas Goirand wrote:
[...]
> I'm coming from the time when OpenStack had a list on launchpad
> where everything was mixed. We did the split because it was really
> annoying to have everything mixed.
[...]

These days (just running stats for this calendar year) we've been
averaging 4 messages a day on the general openstack@lists.o.o ML, so
if it's volume you're worried about most of it would be the current
-operators and -dev ML discussions anyway (many of which are general
questions from users already, because as you also pointed out we
don't usually tell them to take their questions elsewhere any more).
-- 
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] [octavia] Proposing Carlos Goncalves (cgoncalves) as an Octavia core reviewer

[Carlos Goncalves]

Ha! Gracias for the kind words, Miguel! :-)

On Fri, Aug 31, 2018 at 5:55 PM, Miguel Lavalle  wrote:

> Well, I don't vote here but I stiil want to express my +1. I knew this was
> going to happen sooner rather than later
>
> On Thu, Aug 30, 2018 at 10:24 PM, Michael Johnson 
> wrote:
>
>> Hello Octavia community,
>>
>> I would like to propose Carlos Goncalves as a core reviewer on the
>> Octavia project.
>>
>> Carlos has provided numerous enhancements to the Octavia project,
>> including setting up the grenade gate for Octavia upgrade testing.
>>
>> Over the last few releases he has also been providing quality reviews,
>> in line with the other core reviewers [1]. I feel that Carlos would
>> make an excellent 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: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
>
>
__
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] Stepping down from Neutron core team

[Miguel Lavalle]

Kuba,

I made a last ditch awkward effort to convince you to stay a little longer
unsuccessfully. I understand, though, that now you have other commitments.
I know you will be successful in your new adventures, because you are
really smart and hard working. And please remember that we will take you
back with open arms at any moment in the future.

Finally, I wish you good luck, because we all need a little bit of it

Best regards

Miguel

On Fri, Aug 31, 2018 at 3:49 AM, Slawomir Kaplonski 
wrote:

> It’s sad news. Thanks Kuba for all Your help You gave me when I was
> newcomer in Neutron community.
> Good luck in Your next projects :)
>
> > Wiadomość napisana przez Jakub Libosvar  w dniu
> 31.08.2018, o godz. 10:24:
> >
> > Hi all,
> >
> > as you have might already heard, I'm no longer involved in Neutron
> > development due to some changes. Therefore I'm officially stepping down
> > from the core team because I can't provide same quality reviews as I
> > tried to do before.
> >
> > I'd like to thank you all for the opportunity I was given in the Neutron
> > team, thank you for all I have learned over the years professionally,
> > technically and personally. Tomorrow it's gonna be exactly 5 years since
> > I started hacking Neutron and I must say I really enjoyed working with
> > all Neutrinos here and I had privilege to meet most of you in person and
> > that has an extreme value for me. Keep on being a great community!
> >
> > Thank you again!
> > Kuba
> >
> > 
> __
> > 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
>
> —
> Slawek Kaplonski
> Senior software engineer
> Red Hat
>
>
> __
> 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] Mailman topic filtering (was: Bringing the community together...)

[Jeremy Stanley]

On 2018-08-31 09:35:55 +0100 (+0100), Stephen Finucane wrote:
[...]
> I've tinked with mailman 3 before so I could probably take a shot at
> this over the next few week(end)s; however, I've no idea how this
> feature is supposed to work. Any chance an admin of the current list
> could send me a couple of screenshots of the feature in mailman 2 along
> with a brief description of the feature? Alternatively, maybe we could
> upload them to the wiki page Tony linked above or, better yet, to the
> technical details page for same:
> 
>   https://wiki.mailman.psf.io/DEV/Brief%20Technical%20Details

Looks like this should be
https://wiki.list.org/DEV/Brief%20Technical%20Details instead,
however reading through it doesn't really sound like the topic
filtering feature from MM2.

The List Member Manual has a very brief description of the feature
from the subscriber standpoint:

http://www.list.org/mailman-member/node29.html

The List Administration Manual unfortunately doesn't have any
content for the feature, just a stubbed-out section heading:

http://www.list.org/mailman-admin/node30.html

Sending screenshots to the ML is a bit tough, but luckily MIT's
listadmins have posted some so we don't need to:

http://web.mit.edu/lists/mailman/topics.html

-- 
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] [neutron][nova] Small bandwidth demo on the PTG

[Miguel Lavalle]

Nova room is fine. See you'all there

On Fri, Aug 31, 2018 at 3:29 AM, Balázs Gibizer  wrote:

>
>
> On Thu, Aug 30, 2018 at 8:13 PM, melanie witt  wrote:
>
>> On Thu, 30 Aug 2018 12:43:06 -0500, Miguel Lavalle wrote:
>>
>>> Gibi, Bence,
>>>
>>> In fact, I added the demo explicitly to the Neutron PTG agenda from
>>> 1:30  to 2, to give it visiblilty
>>>
>>
>> I'm interested in seeing the demo too. Will the demo be shown at the
>> Neutron room or the Nova room? Historically, lunch has ended at 1:30, so
>> this will be during the same time as the Neutron/Nova cross project time.
>> Should we just co-locate together for the demo and the session? I expect
>> anyone watching the demo will want to participate in the Neutron/Nova
>> session as well. Either room is fine by me.
>>
>>
> I assume that the nova - neturon cross project session will be in the nova
> room, so I propose to have the demo there as well to avoid unnecessarily
> moving people around. For us it is totally OK to start the demo at 1:30.
>
> Cheers,
> gibi
>
>
>
> -melanie
>>
>> On Thu, Aug 30, 2018 at 3:55 AM, Balázs Gibizer  <
>>> balazs.gibi...@ericsson.com > wrote:
>>>
>>> Hi,
>>>
>>> Based on the Nova PTG planning etherpad [1] there is a need to talk
>>> about the current state of the bandwidth work [2][3]. Bence
>>> (rubasov) has already planned to show a small demo to Neutron folks
>>> about the current state of the implementation. So Bence and I are
>>> wondering about bringing that demo close to the nova - neutron cross
>>> project session. That session is currently planned to happen
>>> Thursday after lunch. So we are think about showing the demo right
>>> before that session starts. It would start 30 minutes before the
>>> nova - neutron cross project session.
>>>
>>> Are Nova folks also interested in seeing such a demo?
>>>
>>> If you are interested in seeing the demo please drop us a line or
>>> ping us in IRC so we know who should we wait for.
>>>
>>> Cheers,
>>> gibi
>>>
>>> [1] https://etherpad.openstack.org/p/nova-ptg-stein
>>> 
>>> [2]
>>> https://specs.openstack.org/openstack/neutron-specs/specs/ro
>>> cky/minimum-bandwidth-allocation-placement-api.html
>>> >> ocky/minimum-bandwidth-allocation-placement-api.html>
>>> [3]
>>> https://specs.openstack.org/openstack/nova-specs/specs/rocky
>>> /approved/bandwidth-resource-provider.html
>>> >> y/approved/bandwidth-resource-provider.html>
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> >> subscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>>
>>>
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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
>
__
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] [chef] fog-openstack 0.2.0 breakage

[Jay Pipes]

Thanks for notifying about this, Samuel. Our most modern deployment is 
actually currently blocked on this and I'm glad to see a resolution.


Best,
-jay

On 08/31/2018 11:59 AM, Samuel Cassiba wrote:

Ohai!

fog-openstack 0.2.0 was recently released, which had less than optimal
effects on Chef OpenStack due to the client cookbook's lack of version
pinning on the gem.

The crucial change is that fog-openstack itself now determines
Identity API versions internally, in preparation for a versionless
Keystone endpoint. Chef OpenStack has carried code for Identity API
determination for years, to facilitate migrating from Identity v2.0 to
Identity v3. Unfortunately, those two methods became at odds with the
release of fog-openstack 0.2.

At the time of this writing, PR #421
(https://github.com/fog/fog-openstack/pull/421) has been merged, but
there is no new release on rubygems.org as of yet. That is likely to
happen Very Soon(tm).

On the home front, with the help of Roger Luethi and Christoph Albers,
we've introduced version constraints to the client cookbook to pin the
gem to 0.1.x. At present, we've merged constraints for master,
stable/queens and stable/pike.

The new release was primed to go into ChefDK 3.2 had it not been
brought up sooner. Thank you to everyone who gave a heads-up!

Best,

scas

__
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] quickstart for humans

[Raoul Scarazzini]

On 8/31/18 12:07 PM, Jiří Stránský wrote:
[...]
> * "for humans" definition differs significantly based on who you ask.
> E.g. my intention with [2] was to readily expose *more* knobs and tweaks
> and be more transparent with the underlying workings of Ansible, because
> i felt like quickstart.sh hides too much from me. In my opinion [2] is
> sufficiently "for humans", yet it does pretty much the opposite of what
> you're looking for.

Hey Jiri,
I think that "for humans" means simply that you launch the command with
just one parameter (i.e. the virthost), and then you have something.
And because of this I think here is just a matter of concentrate the
efforts to turn back quickstart.sh to its original scope: making you
launch it with just one parameter and have an available environment
after a while (OK, sometimes more than a while).
Since part of the recent discussions were around the hypotheses of
removing it, maybe we can think about make it useful again. Mostly
because it is right that the needs of everyone are different, but on the
other side with a solid starting point (the default) you can think about
customizing depending on your needs.
I'm for recycling what we have, planet (and me) will enjoy it!

My 0,002 cents.

-- 
Raoul Scarazzini
ra...@redhat.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] [nova][placement] Freezing placement for extraction

[Dan Smith]

> If we're going to do the extraction in Stien, which we said we'd do in
> Dublin, we need to start that as early as possible to iron out any
> deployment bugs in the switch. We can't wait until the 2nd or 3rd
> milestone, it would be too risky.

I agree that the current extraction plan is highly risky and that if
it's going to happen, we need plenty of time to clean up the mess. I
imagine what Sylvain is getting at here is that if we followed the
process of other splits like nova-volume, we'd be doing this
differently.

In that case, we'd freeze late in the cycle when freezing is appropriate
anyway. We'd split out placement such that the nova-integrated one and
the separate one are equivalent, and do the work to get it working on
its own. In the next cycle new changes go to the split placement
only. Operators are able to upgrade to stein without deploying a new
stein service first, and can switch to the split placement at their
leisure, separate from the release upgrade process.

To be honest, I'm not sure how we got to the point of considering it
acceptable to be splitting out a piece of nova in a single cycle such
that operators have to deploy a new thing in order to upgrade. But alas,
as has been said, this is politically more important than ... everything
else.

--Dan

__
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] [chef] fog-openstack 0.2.0 breakage

[Samuel Cassiba]

Ohai!

fog-openstack 0.2.0 was recently released, which had less than optimal
effects on Chef OpenStack due to the client cookbook's lack of version
pinning on the gem.

The crucial change is that fog-openstack itself now determines
Identity API versions internally, in preparation for a versionless
Keystone endpoint. Chef OpenStack has carried code for Identity API
determination for years, to facilitate migrating from Identity v2.0 to
Identity v3. Unfortunately, those two methods became at odds with the
release of fog-openstack 0.2.

At the time of this writing, PR #421
(https://github.com/fog/fog-openstack/pull/421) has been merged, but
there is no new release on rubygems.org as of yet. That is likely to
happen Very Soon(tm).

On the home front, with the help of Roger Luethi and Christoph Albers,
we've introduced version constraints to the client cookbook to pin the
gem to 0.1.x. At present, we've merged constraints for master,
stable/queens and stable/pike.

The new release was primed to go into ChefDK 3.2 had it not been
brought up sooner. Thank you to everyone who gave a heads-up!

Best,

scas

__
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] Nominating Chris Dent for placement-core

[Miguel Lavalle]

I don't get to vote here either, but I was one of the first users of the
Placement API (Neutron Routed Networks) and I always got great support and
guidance from cdent. So +1 and well deserved

On Fri, Aug 31, 2018 at 10:45 AM, Eric Fried  wrote:

> The openstack/placement project [1] and its core team [2] have been
> established in gerrit.
>
> I hereby nominate Chris Dent for membership in the placement-core team.
> He has been instrumental in the design, implementation, and stewardship
> of the placement API since its inception and has shown clear and
> consistent leadership.
>
> As we are effectively bootstrapping placement-core at this time, it
> would seem appropriate to consider +1/-1 responses from heavy placement
> contributors as well as existing cores (currently nova-core).
>
> [1] https://review.openstack.org/#/admin/projects/openstack/placement
> [2] https://review.openstack.org/#/admin/groups/1936,members
>
> __
> 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 Carlos Goncalves (cgoncalves) as an Octavia core reviewer

[Miguel Lavalle]

Well, I don't vote here but I stiil want to express my +1. I knew this was
going to happen sooner rather than later

On Thu, Aug 30, 2018 at 10:24 PM, Michael Johnson 
wrote:

> Hello Octavia community,
>
> I would like to propose Carlos Goncalves as a core reviewer on the
> Octavia project.
>
> Carlos has provided numerous enhancements to the Octavia project,
> including setting up the grenade gate for Octavia upgrade testing.
>
> Over the last few releases he has also been providing quality reviews,
> in line with the other core reviewers [1]. I feel that Carlos would
> make an excellent 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] [octavia] Proposing Carlos Goncalves (cgoncalves) as an Octavia core reviewer

[German Eichberger]

Concur. Carlos has been a great contributor!

+1

From: Nir Magnezi 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, August 31, 2018 at 5:02 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [octavia] Proposing Carlos Goncalves (cgoncalves) 
as an Octavia core reviewer

Carlos made a significant impact with quality reviews and code contributions.
I think he would make a great addition to the core team.

+1 From me.

/Nir

On Fri, Aug 31, 2018 at 6:29 AM Jacky Hu 
mailto:huda...@hotmail.com>> wrote:
+1
Definitely a good contributor for the octavia community.

发自我的 iPhone

> 在 2018年8月31日，上午11:24，Michael Johnson 
> mailto:johnso...@gmail.com>> 写道：
>
> Hello Octavia community,
>
> I would like to propose Carlos Goncalves as a core reviewer on the
> Octavia project.
>
> Carlos has provided numerous enhancements to the Octavia project,
> including setting up the grenade gate for Octavia upgrade testing.
>
> Over the last few releases he has also been providing quality reviews,
> in line with the other core reviewers [1]. I feel that Carlos would
> make an excellent 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] [Rally] Deployment check fails

[Sai Sindhur Malleni]

Hey Andrey,

Here is the output of what you asked for
(overcloud) (.rally-venv) [stack@undercloud browbeat]$ rally env show
--only-spec
{
  "existing@openstack": {
"endpoint": null,
"region_name": "",
"https_insecure": false,
"profiler_hmac_key": null,
"admin": {
  "username": "admin",
  "project_name": "admin",
  "user_domain_name": "Default",
  "password": "kYbMNEdPwGfCBUrwDH4rdxZyJ",
  "project_domain_name": "Default"
},
"https_cacert": "",
"endpoint_type": null,
"auth_url": "https://10.0.0.5:13000//v3;,
"profiler_conn_str": null
  }
}
(overcloud) (.rally-venv) [stack@undercloud browbeat]$ rally env info
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr [-] Plugin
exist...@openstack.info() method is broken: AuthenticationFailed: Failed to
authenticate to https://10.0.0.5:13000//v3 for user 'admin' in project
'admin': SSLError: SSL exception connecting to https://10.0.0.5:13000//v3:
HTTPSConnectionPool(host='10.0.0.5', port=13000): Max retries exceeded with
url: //v3 (Caused by SSLError(SSLError("bad handshake: Error([('SSL
routines', 'tls_process_server_certificate', 'certificate verify
failed')],)",),))
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr Traceback (most
recent call last):
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr   File
"/home/stack/browbeat/.rally-venv/lib/python2.7/site-packages/rally/env/env_mgr.py",
line 523, in get_info
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr info = p.info()
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr   File
"/home/stack/browbeat/.rally-venv/lib/python2.7/site-packages/rally_openstack/platforms/existing.py",
line 183, in info
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr for stype, name
in osclients.Clients(active_user).services().items():
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr   File
"/home/stack/browbeat/.rally-venv/lib/python2.7/site-packages/rally_openstack/osclients.py",
line 860, in services
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr
 available_services = self.keystone.service_catalog.get_endpoints()
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr   File
"/home/stack/browbeat/.rally-venv/lib/python2.7/site-packages/rally_openstack/osclients.py",
line 225, in service_catalog
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr return
self.auth_ref.service_catalog
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr   File
"/home/stack/browbeat/.rally-venv/lib/python2.7/site-packages/rally_openstack/osclients.py",
line 245, in auth_ref
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr error=str(e))
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr
AuthenticationFailed: Failed to authenticate to https://10.0.0.5:13000//v3
for user 'admin' in project 'admin': SSLError: SSL exception connecting to
https://10.0.0.5:13000//v3: HTTPSConnectionPool(host='10.0.0.5',
port=13000): Max retries exceeded with url: //v3 (Caused by
SSLError(SSLError("bad handshake: Error([('SSL routines',
'tls_process_server_certificate', 'certificate verify failed')],)",),))
2018-08-31 15:46:25.993 440110 ERROR rally.env.env_mgr
Env `overcloud (87e6bdec-45c3-4194-9d7c-0451c0c030b5)'
++--+---+
| platform   | info | error
 |
++--+---+
| existing@openstack | null | Plugin exist...@openstack.info() method is
broken |
++--+---+

On Fri, Aug 31, 2018 at 10:13 AM Andrey Kurilin 
wrote:

> Hi!
>
> Sorry for such a not user-friendly error message. Several days ago, we
> merged a fix[*] for it and I'm planning to release a new version of
> rally-openstack package soon.
> While the fix is not released, please share the result of the 2 commands:
>
> - rally env show --only-spec # replace password and etc
> - rally env info
>
> [*] -
> https://github.com/openstack/rally-openstack/commit/5821f8b8714c532778f2eef142a5fdeb3a1e6f05
>
> пт, 31 авг. 2018 г. в 17:02, Sai Sindhur Malleni :
>
>> Hey all,
>>
>> rally deployment check fails saying, bad admin credentials but I'm able
>> to use the admin tenant to performance openstack operations like creating
>> VMs extra. rally deployment check fails without giving much information.
>> (.rally-venv) [stack@undercloud browbeat]$ rally deployment check
>>
>> 
>> Platform openstack:
>>
>> 
>>
>> Error while checking admin credentials:
>> AuthenticationFailed: Bad admin creds:
>> {
>>   "auth_url": "https://10.0.0.5:13000//v3;,
>>   "domain_name": null,
>>   "endpoint_type": null,
>>   "https_cacert": "",
>>   "https_insecure": false,
>>   "password": "***",
>>   "profiler_conn_str": null,
>>   

[openstack-dev] Nominating Chris Dent for placement-core

[Eric Fried]

The openstack/placement project [1] and its core team [2] have been
established in gerrit.

I hereby nominate Chris Dent for membership in the placement-core team.
He has been instrumental in the design, implementation, and stewardship
of the placement API since its inception and has shown clear and
consistent leadership.

As we are effectively bootstrapping placement-core at this time, it
would seem appropriate to consider +1/-1 responses from heavy placement
contributors as well as existing cores (currently nova-core).

[1] https://review.openstack.org/#/admin/projects/openstack/placement
[2] https://review.openstack.org/#/admin/groups/1936,members

__
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][placement] Freezing placement for extraction

[Matt Riedemann]

On 8/31/2018 9:41 AM, Sylvain Bauza wrote:
Apologies for having missed the large and wide discussions about 
placement future in the past weeks. I was off so I just saw the 
consensus yesterday evening my time.
Now that disclaimer is done, can I know the reasoning why we call the 
freeze as of now and not waiting for either Stein-2 or Stein-3 ?


If we're going to do the extraction in Stien, which we said we'd do in 
Dublin, we need to start that as early as possible to iron out any 
deployment bugs in the switch. We can't wait until the 2nd or 3rd 
milestone, it would be too risky.




My main concern is that the reshaper series is still being reviewed for 
Nova. Some other changes using Placement (like drivers using nested 
Resource Providers and the likes) are also not yet implemented (or even 
be uploaded) and I'm a bit afraid of us discovering yet another 
cross-services problem (say with having two distinct computes having 
different versions) that would make the fix more harder than just fixing 
directly.


The Placement-side changes for the reshaper changes are merged. The 
framework code for compute is either merged or on it's way. The 
outstanding changes for reshaper are:


1. libvirt and xenapi driver changes to use it - remember me emailing 
you and the xen team about this last week? We couldn't hold up the 
existing patches forever.


2. The offline migration stuff for FFU (I believe Dan was signed up for 
that).


3. Docs and whatever other polishing is needed.

So there is nothing related to reshaper that should block Placement 
extraction happening at this point. Sure we could hit some very weird 
bug once the driver implementation happens - that's a risk we talked 
about last week when we removed the -2 from the Placement API change, 
but again, without people around to work on the driver changes, we can't 
just sit and hold forever because that pushes out the extraction which 
makes delivering a smooth upgrade for the extraction during stein 
riskier, so pick your poison.


--

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] [nova][placement] Freezing placement for extraction

[Sylvain Bauza]

On Thu, Aug 30, 2018 at 6:34 PM, Eric Fried  wrote:

> Greetings.
>
> The captains of placement extraction have declared readiness to begin
> the process of seeding the new repository (once [1] has finished
> merging). As such, we are freezing development in the affected portions
> of the openstack/nova repository until this process is completed. We're
> relying on our active placement reviewers noticing any patches that
> touch these "affected portions" and, if that reviewer is not a nova
> core, bringing them to the attention of one, so we can put a -2 on it.
>
>
Apologies for having missed the large and wide discussions about placement
future in the past weeks. I was off so I just saw the consensus yesterday
evening my time.
Now that disclaimer is done, can I know the reasoning why we call the
freeze as of now and not waiting for either Stein-2 or Stein-3 ?

My main concern is that the reshaper series is still being reviewed for
Nova. Some other changes using Placement (like drivers using nested
Resource Providers and the likes) are also not yet implemented (or even be
uploaded) and I'm a bit afraid of us discovering yet another cross-services
problem (say with having two distinct computes having different versions)
that would make the fix more harder than just fixing directly.



> Once the extraction is complete [2], any such frozen patches should be
> abandoned and reproposed to the openstack/placement repository.
>
> Since there will be an interval during which placement code will exist
> in both repositories, but before $world has cut over to using
> openstack/placement, it is possible that some crucial fix will still
> need to be merged into the openstack/nova side. In this case, the fix
> must be proposed to *both* repositories, and the justification for its
> existence in openstack/nova made clear.
>
>
We surely can do such things for small fixes that don't impact a lot of
files. What I'm a bit afraid of is any large change that would get some
merge conflicts. Sure, we can find ways to fix it too, but again, why
shouldn't we just wait for Stein-2 ?

-Sylvain (yet again apologies for the late opinion).


For more details on the technical aspects of the extraction process,
> refer to this thread [3].
>
> For information on the procedural/governance process we will be
> following, see [4].
>
> Please let us know if you have any questions or concerns, either via
> this thread or in #openstack-placement.
>
> [1] https://review.openstack.org/#/c/597220/
> [2] meaning that we've merged the initial glut of patches necessary to
> repath everything and get tests passing
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2018-August/133781.html
> [4] https://docs.openstack.org/infra/manual/creators.html
>
> __
> 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] [kolla][tripleo][oslo][all] Bumping eventlet to 0.24.1

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2018-08-31 09:13:00 -0500:
> On 18-08-31 07:44:44, Jim Rollenhagen wrote:

> > 
> > Tempest plugins, like tempest, are not meant to be branched:
> > http://lists.openstack.org/pipermail/openstack-dev/2018-August/133211.html
> > 
> 
> Yep, it's only on the list because the command used to generate it can't
> handle projects that should not branch.

https://review.openstack.org/598981 should fix that

__
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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

[Doug Hellmann]

Excerpts from Dirk Müller's message of 2018-08-31 15:26:10 +0200:
> Am Fr., 31. Aug. 2018 um 01:28 Uhr schrieb Doug Hellmann
> :
> 
> Hi Doug,
> 
> > | Packaging-rpm   | 4 repos   |
> 
> We're ready - please send the patches.
> 
> Greetings,
> Dirk
> 

Here you go:

+++-++
| Subject| Repo 
  | URL | Branch |
+++-++
| remove job settings for Packaging-rpm repositories | 
openstack-infra/project-config | https://review.openstack.org/598974 | master |
| import zuul job settings from project-config   | openstack/pymod2pkg  
  | https://review.openstack.org/598967 | master |
| switch documentation job to new PTI| openstack/pymod2pkg  
  | https://review.openstack.org/598968 | master |
| add python 3.6 unit test job   | openstack/pymod2pkg  
  | https://review.openstack.org/598969 | master |
| import zuul job settings from project-config   | openstack/renderspec 
  | https://review.openstack.org/598970 | master |
| switch documentation job to new PTI| openstack/renderspec 
  | https://review.openstack.org/598971 | master |
| add python 3.6 unit test job   | openstack/renderspec 
  | https://review.openstack.org/598972 | master |
| import zuul job settings from project-config   | 
openstack/rpm-packaging-tools  | https://review.openstack.org/598973 | master |
+++-++

__
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] [Rally] Deployment check fails

[Andrey Kurilin]

Hi!

Sorry for such a not user-friendly error message. Several days ago, we
merged a fix[*] for it and I'm planning to release a new version of
rally-openstack package soon.
While the fix is not released, please share the result of the 2 commands:

- rally env show --only-spec # replace password and etc
- rally env info

[*] -
https://github.com/openstack/rally-openstack/commit/5821f8b8714c532778f2eef142a5fdeb3a1e6f05

пт, 31 авг. 2018 г. в 17:02, Sai Sindhur Malleni :

> Hey all,
>
> rally deployment check fails saying, bad admin credentials but I'm able to
> use the admin tenant to performance openstack operations like creating VMs
> extra. rally deployment check fails without giving much information.
> (.rally-venv) [stack@undercloud browbeat]$ rally deployment check
>
> 
> Platform openstack:
>
> 
>
> Error while checking admin credentials:
> AuthenticationFailed: Bad admin creds:
> {
>   "auth_url": "https://10.0.0.5:13000//v3;,
>   "domain_name": null,
>   "endpoint_type": null,
>   "https_cacert": "",
>   "https_insecure": false,
>   "password": "***",
>   "profiler_conn_str": null,
>   "profiler_hmac_key": null,
>   "project_domain_name": "Default",
>   "region_name": "",
>   "tenant_name": "admin",
>   "user_domain_name": "Default",
>   "username": "admin"
> }
>
> I'm not sure that the reason is give I can source the adminrc and run
> openstack commands normally.
>
> Here are the contents of the rc file:
> for key in $( set | awk '{FS="="}  /^OS_/ {print $1}' ); do unset $key ;
> done
> export OS_NO_CACHE=True
> export COMPUTE_API_VERSION=1.1
> export OS_USERNAME=admin
> export no_proxy=,10.0.0.5,192.168.24.7
> export OS_USER_DOMAIN_NAME=Default
> export OS_VOLUME_API_VERSION=3
> export OS_CLOUDNAME=overcloud
> export OS_AUTH_URL=https://10.0.0.5:13000//v3
> export NOVA_VERSION=1.1
> export OS_IMAGE_API_VERSION=2
> export OS_PASSWORD=kYbMNEdPwGfCBUrwDH4rdxZyJ
> export OS_PROJECT_DOMAIN_NAME=Default
> export OS_IDENTITY_API_VERSION=3
> export OS_PROJECT_NAME=admin
> export OS_AUTH_TYPE=password
> export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true SSLContext
> object is not available"
>
> # Add OS_CLOUDNAME to PS1
> if [ -z "${CLOUDPROMPT_ENABLED:-}" ]; then
> export PS1=${PS1:-""}
> export PS1=\${OS_CLOUDNAME:+"(\$OS_CLOUDNAME)"}\ $PS1
> export CLOUDPROMPT_ENABLED=1
> fi
>
>
> Please let me know if there is a way to know more about what the issue is.
> --
> Sai Sindhur Malleni
>
> Software Engineer
> Red Hat Inc.
> 314 Littleton Road
> Westford MA, USA
>
>

-- 
Best regards,
Andrey Kurilin.
__
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][tripleo][oslo][all] Bumping eventlet to 0.24.1

[Matthew Thode]

On 18-08-31 07:44:44, Jim Rollenhagen wrote:
> On Thu, Aug 30, 2018 at 11:10 PM, Matthew Thode 
> wrote:
> 
> > On 18-08-30 20:52:46, Matthew Thode wrote:
> > > On 18-08-23 09:50:13, Matthew Thode wrote:
> > > > This is your warning, if you have concerns please comment in
> > > > https://review.openstack.org/589382 .  cross tests pass, so that's a
> > > > good sign... atm this is only for stein.
> > > >
> > >
> > > Consider yourself on notice, https://review.openstack.org/589382 is
> > > planned to be merged on monday.
> > >
> >
> > A bit more of follow up since that was so dry.  There are some projects
> > that have not branched (mainly cycle-trailing and plugins).
> >
> > There has historically been some breakage with each eventlet update,
> > this one is not expected to be much different unfortunately.  Currently
> > there are known issues with oslo.service but they look solvable.  A list
> > of all projects using eventlet is attached.
> >
> > The full list of non-branched projects will be at the bottom of this
> > message, but the projects that I think should be more careful are the
> > following.
> >
> > kolla kolla-ansible heat-agents heat-dashboard tripleo-ipsec
> >
> > the rest of the repos seem to be plugins, which I'm personally less
> > concerned about, but should still be branched (preferably sooner rather
> > than later).
> >
> 
> Tempest plugins, like tempest, are not meant to be branched:
> http://lists.openstack.org/pipermail/openstack-dev/2018-August/133211.html
> 

Yep, it's only on the list because the command used to generate it can't
handle projects that should not branch.

> 
> 
> >
> > ansible-role-container-registry
> > ansible-role-redhat-subscription
> > ansible-role-tripleo-modify-image
> > barbican-tempest-plugin
> > blazar-tempest-plugin
> > cinder-tempest-plugin
> > cloudkitty-tempest-plugin
> > congress-tempest-plugin
> > designate-tempest-plugin
> > devstack-plugin-amqp1
> > devstack-plugin-kafka
> > ec2api-tempest-plugin
> > heat-agents
> > heat-dashboard
> > heat-tempest-plugin
> > ironic-tempest-plugin
> > keystone-tempest-plugin
> > kolla-ansible
> > kolla
> > kuryr-tempest-plugin
> > magnum-tempest-plugin
> > manila-tempest-plugin
> > mistral-tempest-plugin
> > monasca-kibana-plugin
> > monasca-tempest-plugin
> > murano-tempest-plugin
> > networking-generic-switch-tempest-plugin
> > neutron-tempest-plugin
> > octavia-tempest-plugin
> > oswin-tempest-plugin
> > patrole
> > release-test
> > sahara-tests
> > senlin-tempest-plugin
> > solum-tempest-plugin
> > telemetry-tempest-plugin
> > tempest-tripleo-ui
> > tempest
> > tripleo-ipsec
> > trove-tempest-plugin
> > vitrage-tempest-plugin
> > watcher-tempest-plugin
> > zaqar-tempest-plugin
> > zun-tempest-plugin
> >
> > --
> > Matthew Thode (prometheanfire)
> >
> > __
> > 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


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

[openstack-dev] [Rally] Deployment check fails

[Sai Sindhur Malleni]

Hey all,

rally deployment check fails saying, bad admin credentials but I'm able to
use the admin tenant to performance openstack operations like creating VMs
extra. rally deployment check fails without giving much information.
(.rally-venv) [stack@undercloud browbeat]$ rally deployment check

Platform openstack:


Error while checking admin credentials:
AuthenticationFailed: Bad admin creds:
{
  "auth_url": "https://10.0.0.5:13000//v3;,
  "domain_name": null,
  "endpoint_type": null,
  "https_cacert": "",
  "https_insecure": false,
  "password": "***",
  "profiler_conn_str": null,
  "profiler_hmac_key": null,
  "project_domain_name": "Default",
  "region_name": "",
  "tenant_name": "admin",
  "user_domain_name": "Default",
  "username": "admin"
}

I'm not sure that the reason is give I can source the adminrc and run
openstack commands normally.

Here are the contents of the rc file:
for key in $( set | awk '{FS="="}  /^OS_/ {print $1}' ); do unset $key ;
done
export OS_NO_CACHE=True
export COMPUTE_API_VERSION=1.1
export OS_USERNAME=admin
export no_proxy=,10.0.0.5,192.168.24.7
export OS_USER_DOMAIN_NAME=Default
export OS_VOLUME_API_VERSION=3
export OS_CLOUDNAME=overcloud
export OS_AUTH_URL=https://10.0.0.5:13000//v3
export NOVA_VERSION=1.1
export OS_IMAGE_API_VERSION=2
export OS_PASSWORD=kYbMNEdPwGfCBUrwDH4rdxZyJ
export OS_PROJECT_DOMAIN_NAME=Default
export OS_IDENTITY_API_VERSION=3
export OS_PROJECT_NAME=admin
export OS_AUTH_TYPE=password
export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true SSLContext
object is not available"

# Add OS_CLOUDNAME to PS1
if [ -z "${CLOUDPROMPT_ENABLED:-}" ]; then
export PS1=${PS1:-""}
export PS1=\${OS_CLOUDNAME:+"(\$OS_CLOUDNAME)"}\ $PS1
export CLOUDPROMPT_ENABLED=1
fi


Please let me know if there is a way to know more about what the issue is.
-- 
Sai Sindhur Malleni

Software Engineer
Red Hat Inc.
314 Littleton Road
Westford MA, USA
__
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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

[Dirk Müller]

Am Fr., 31. Aug. 2018 um 01:28 Uhr schrieb Doug Hellmann
:

Hi Doug,

> | Packaging-rpm   | 4 repos   |

We're ready - please send the patches.

Greetings,
Dirk

__
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 Rocky is officially released

[Sean McGinnis]

The following was sent out yesterday to the openstack-announce mailing list.

Thank you to everyone involved in the Rocky development cycle. Truly a lot has
happened since the snowpocalypse. On to Stein (and hopefully a less chaotic
PTG)!

--

Hello OpenStack community,

I'm excited to announce the final releases for the components of OpenStack
Rocky, which conclude the Rocky development cycle.

You will find a complete list of all components, their latest versions, and
links to individual project release notes documents listed on the new release
site.

  https://releases.openstack.org/rocky/

Congratulations to all of the teams who have contributed to this release!

Our next production cycle, Stein, has already started. We will meet in Denver,
Colorado, USA September 10-14 at the Project Team Gathering to plan the work
for the upcoming cycle. I hope to see you there!

Thanks,
Sean McGinnis and the whole Release Management team

__
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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

[Luka Peschke]

Thank you for this!

For small projects like cloudkitty it is really helpful when matters 
like this one are handled by persons who are external to the project.


Regards,

Luka Peschke

Le 2018-08-31 15:04, Doug Hellmann a écrit :
Excerpts from Christophe Sauthier's message of 2018-08-31 11:20:33 
+0200:



We are ready to start on the cloudkitty's team !

Christophe


Here are the patches:

+-+-+-+---+
| Subject | Repo
 | URL | Branch
|
+-+-+-+---+
| remove job settings for cloudkitty repositories |
openstack-infra/project-config  |
https://review.openstack.org/598929 | master|
| import zuul job settings from project-config|
openstack/cloudkitty|
https://review.openstack.org/598884 | master|
| switch documentation job to new PTI |
openstack/cloudkitty|
https://review.openstack.org/598885 | master|
| add python 3.6 unit test job|
openstack/cloudkitty|
https://review.openstack.org/598886 | master|
| import zuul job settings from project-config|
openstack/cloudkitty|
https://review.openstack.org/598900 | stable/ocata  |
| import zuul job settings from project-config|
openstack/cloudkitty|
https://review.openstack.org/598906 | stable/pike   |
| import zuul job settings from project-config|
openstack/cloudkitty|
https://review.openstack.org/598912 | stable/queens |
| import zuul job settings from project-config|
openstack/cloudkitty|
https://review.openstack.org/598918 | stable/rocky  |
| import zuul job settings from project-config|
openstack/cloudkitty-dashboard  |
https://review.openstack.org/59 | master|
| switch documentation job to new PTI |
openstack/cloudkitty-dashboard  |
https://review.openstack.org/598889 | master|
| add python 3.6 unit test job|
openstack/cloudkitty-dashboard  |
https://review.openstack.org/598890 | master|
| import zuul job settings from project-config|
openstack/cloudkitty-dashboard  |
https://review.openstack.org/598902 | stable/ocata  |
| import zuul job settings from project-config|
openstack/cloudkitty-dashboard  |
https://review.openstack.org/598908 | stable/pike   |
| import zuul job settings from project-config|
openstack/cloudkitty-dashboard  |
https://review.openstack.org/598914 | stable/queens |
| import zuul job settings from project-config|
openstack/cloudkitty-dashboard  |
https://review.openstack.org/598920 | stable/rocky  |
| import zuul job settings from project-config|
openstack/cloudkitty-specs  |
https://review.openstack.org/598893 | master|
| import zuul job settings from project-config|
openstack/cloudkitty-tempest-plugin |
https://review.openstack.org/598895 | master|
| import zuul job settings from project-config|
openstack/python-cloudkittyclient   |
https://review.openstack.org/598897 | master|
| add python 3.6 unit test job|
openstack/python-cloudkittyclient   |
https://review.openstack.org/598898 | master|
| import zuul job settings from project-config|
openstack/python-cloudkittyclient   |
https://review.openstack.org/598904 | stable/ocata  |
| import zuul job settings from project-config|
openstack/python-cloudkittyclient   |
https://review.openstack.org/598910 | stable/pike   |
| import zuul job settings from project-config|
openstack/python-cloudkittyclient   |
https://review.openstack.org/598917 | stable/queens |
| import zuul job settings from project-config|
openstack/python-cloudkittyclient   |
https://review.openstack.org/598923 | stable/rocky  |
+-+-+-+---+

__
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] fluentd logging status

[Juan Antonio Osorio Robles]

Logging is a topic that I think should get more love on the TripleO side.


On 08/24/2018 12:17 PM, Juan Badia Payno wrote:
> Recently, I did a little test regarding fluentd logging on the gates
> master[1], queens[2], pike [3]. I don't like the status of it, I'm
> still working on them, but basically there are quite a lot of
> misconfigured logs and some services that they are not configured at all.
>
> I think we need to put some effort on the logging. The purpose of this
> email is to point out that we need to do a little effort on the task.
>
> First of all, I think we need to enable fluentd on all the scenarios,
> as it is on the tests [1][2][3] commented on the beginning of the
> email. Once everything is ok and some automatic test regarding logging
> is done they can be disabled.
Wes, do you have an opinion about this? I think it would be a good idea
to avoid these types of regressions.
>
> I'd love not to create a new bug for every misconfigured/unconfigured
> service, but if requested to grab more attention on it, I will open it.
One bug to fix all this is fine, but we do need a public place to track
all the work that needs to be done. Lets reference that place on the
bug. Could be Trello or an etherpad, or whatever you want, it's up to you.
>
> The plan I have in mind is something like:
>  * Make an initial picture of what the fluentd/log status is (from
> pike upwards).
>  * Fix all misconfigured services. (designate,...)
>  * Add the non-configured services. (manila,...)
>  * Add an automated check to find a possible
> unconfigured/misconfigured problem.
>
> Any comments, doubts or questions are welcome
>
> Cheers,
> Juan
>
> [1] https://review.openstack.org/594836
> [2] https://review.openstack.org/594838
> [3] https://review.openstack.org/594840
>
>
>
> __
> 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] fluentd logging status

[Juan Antonio Osorio Robles]

Logging is a topic that I think should get more love on the TripleO side.


On 08/24/2018 12:17 PM, Juan Badia Payno wrote:
> Recently, I did a little test regarding fluentd logging on the gates
> master[1], queens[2], pike [3]. I don't like the status of it, I'm
> still working on them, but basically there are quite a lot of
> misconfigured logs and some services that they are not configured at all.
>
> I think we need to put some effort on the logging. The purpose of this
> email is to point out that we need to do a little effort on the task.
>
> First of all, I think we need to enable fluentd on all the scenarios,
> as it is on the tests [1][2][3] commented on the beginning of the
> email. Once everything is ok and some automatic test regarding logging
> is done they can be disabled.
Wes, do you have an opinion about this? I think it would be a good idea
to avoid these types of regressions.
>
> I'd love not to create a new bug for every misconfigured/unconfigured
> service, but if requested to grab more attention on it, I will open it.
One bug to fix all this is fine, but we do need a public place to track
all the work that needs to be done. Lets reference that place on the
bug. Could be Trello or an etherpad, or whatever you want, it's up to you.
>
> The plan I have in mind is something like:
>  * Make an initial picture of what the fluentd/log status is (from
> pike upwards).
>  * Fix all misconfigured services. (designate,...)
>  * Add the non-configured services. (manila,...)
>  * Add an automated check to find a possible
> unconfigured/misconfigured problem.
>
> Any comments, doubts or questions are welcome
>
> Cheers,
> Juan
>
> [1] https://review.openstack.org/594836
> [2] https://review.openstack.org/594838
> [3] https://review.openstack.org/594840
>
>
>
> __
> 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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

[Doug Hellmann]

Excerpts from Tobias Urdin's message of 2018-08-31 13:31:24 +0200:
> Oh, that's bad. I will abandon.
> It's a go for Puppet then.
> 
> Best regards

There are quite a few patches for all of the Puppet modules.

+---++-+---+
| Subject   | Repo  
 | URL | Branch|
+---++-+---+
| remove job settings for Puppet OpenStack repositories | 
openstack-infra/project-config | https://review.openstack.org/598709 | 
master|
| import zuul job settings from project-config  | openstack/puppet-aodh 
 | https://review.openstack.org/598679 | master|
| switch documentation job to new PTI   | openstack/puppet-aodh 
 | https://review.openstack.org/598680 | master|
| import zuul job settings from project-config  | openstack/puppet-aodh 
 | https://review.openstack.org/598767 | stable/ocata  |
| import zuul job settings from project-config  | openstack/puppet-aodh 
 | https://review.openstack.org/598801 | stable/pike   |
| import zuul job settings from project-config  | openstack/puppet-aodh 
 | https://review.openstack.org/598836 | stable/queens |
| import zuul job settings from project-config  | openstack/puppet-aodh 
 | https://review.openstack.org/598876 | stable/rocky  |
| import zuul job settings from project-config  | 
openstack/puppet-barbican  | https://review.openstack.org/598681 | 
master|
| switch documentation job to new PTI   | 
openstack/puppet-barbican  | https://review.openstack.org/598682 | 
master|
| import zuul job settings from project-config  | 
openstack/puppet-barbican  | https://review.openstack.org/598768 | 
stable/ocata  |
| import zuul job settings from project-config  | 
openstack/puppet-barbican  | https://review.openstack.org/598802 | 
stable/pike   |
| import zuul job settings from project-config  | 
openstack/puppet-barbican  | https://review.openstack.org/598837 | 
stable/queens |
| import zuul job settings from project-config  | 
openstack/puppet-barbican  | https://review.openstack.org/598877 | 
stable/rocky  |
| import zuul job settings from project-config  | 
openstack/puppet-ceilometer| https://review.openstack.org/598683 | 
master|
| switch documentation job to new PTI   | 
openstack/puppet-ceilometer| https://review.openstack.org/598684 | 
master|
| import zuul job settings from project-config  | 
openstack/puppet-ceilometer| https://review.openstack.org/598769 | 
stable/ocata  |
| import zuul job settings from project-config  | 
openstack/puppet-ceilometer| https://review.openstack.org/598803 | 
stable/pike   |
| import zuul job settings from project-config  | 
openstack/puppet-ceilometer| https://review.openstack.org/598838 | 
stable/queens |
| import zuul job settings from project-config  | 
openstack/puppet-ceilometer| https://review.openstack.org/598878 | 
stable/rocky  |
| import zuul job settings from project-config  | openstack/puppet-ceph 
 | https://review.openstack.org/598685 | master|
| switch documentation job to new PTI   | openstack/puppet-ceph 
 | https://review.openstack.org/598686 | master|
| import zuul job settings from project-config  | 
openstack/puppet-cinder| https://review.openstack.org/598687 | 
master|
| switch documentation job to new PTI   | 
openstack/puppet-cinder| https://review.openstack.org/598688 | 
master|
| import zuul job settings from project-config  | 
openstack/puppet-cinder| https://review.openstack.org/598770 | 
stable/ocata  |
| import zuul job settings from project-config  | 
openstack/puppet-cinder| https://review.openstack.org/598804 | 
stable/pike   |
| import zuul job settings from project-config  | 
openstack/puppet-cinder| https://review.openstack.org/598839 | 
stable/queens |
| import zuul job settings from project-config  | 
openstack/puppet-cinder| https://review.openstack.org/598879 | 
stable/rocky  |
| import zuul job settings from project-config  | 
openstack/puppet-cloudkitty| https://review.openstack.org/598689 | 
master  

Re: [openstack-dev] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

[Doug Hellmann]

Excerpts from Christophe Sauthier's message of 2018-08-31 11:20:33 +0200:

> We are ready to start on the cloudkitty's team !
> 
> Christophe

Here are the patches:

+-+-+-+---+
| Subject | Repo
| URL | Branch|
+-+-+-+---+
| remove job settings for cloudkitty repositories | 
openstack-infra/project-config  | https://review.openstack.org/598929 | 
master|
| import zuul job settings from project-config| openstack/cloudkitty
| https://review.openstack.org/598884 | master|
| switch documentation job to new PTI | openstack/cloudkitty
| https://review.openstack.org/598885 | master|
| add python 3.6 unit test job| openstack/cloudkitty
| https://review.openstack.org/598886 | master|
| import zuul job settings from project-config| openstack/cloudkitty
| https://review.openstack.org/598900 | stable/ocata  |
| import zuul job settings from project-config| openstack/cloudkitty
| https://review.openstack.org/598906 | stable/pike   |
| import zuul job settings from project-config| openstack/cloudkitty
| https://review.openstack.org/598912 | stable/queens |
| import zuul job settings from project-config| openstack/cloudkitty
| https://review.openstack.org/598918 | stable/rocky  |
| import zuul job settings from project-config| 
openstack/cloudkitty-dashboard  | https://review.openstack.org/59 | 
master|
| switch documentation job to new PTI | 
openstack/cloudkitty-dashboard  | https://review.openstack.org/598889 | 
master|
| add python 3.6 unit test job| 
openstack/cloudkitty-dashboard  | https://review.openstack.org/598890 | 
master|
| import zuul job settings from project-config| 
openstack/cloudkitty-dashboard  | https://review.openstack.org/598902 | 
stable/ocata  |
| import zuul job settings from project-config| 
openstack/cloudkitty-dashboard  | https://review.openstack.org/598908 | 
stable/pike   |
| import zuul job settings from project-config| 
openstack/cloudkitty-dashboard  | https://review.openstack.org/598914 | 
stable/queens |
| import zuul job settings from project-config| 
openstack/cloudkitty-dashboard  | https://review.openstack.org/598920 | 
stable/rocky  |
| import zuul job settings from project-config| openstack/cloudkitty-specs  
| https://review.openstack.org/598893 | master|
| import zuul job settings from project-config| 
openstack/cloudkitty-tempest-plugin | https://review.openstack.org/598895 | 
master|
| import zuul job settings from project-config| 
openstack/python-cloudkittyclient   | https://review.openstack.org/598897 | 
master|
| add python 3.6 unit test job| 
openstack/python-cloudkittyclient   | https://review.openstack.org/598898 | 
master|
| import zuul job settings from project-config| 
openstack/python-cloudkittyclient   | https://review.openstack.org/598904 | 
stable/ocata  |
| import zuul job settings from project-config| 
openstack/python-cloudkittyclient   | https://review.openstack.org/598910 | 
stable/pike   |
| import zuul job settings from project-config| 
openstack/python-cloudkittyclient   | https://review.openstack.org/598917 | 
stable/queens |
| import zuul job settings from project-config| 
openstack/python-cloudkittyclient   | https://review.openstack.org/598923 | 
stable/rocky  |
+-+-+-+---+

__
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] quickstart for humans

[Honza Pokorny]

On 2018-08-31 13:17, Dougal Matthews wrote:
> On 31 August 2018 at 12:11, Steven Hardy  wrote:
> 
> > On Thu, Aug 30, 2018 at 3:28 PM, Honza Pokorny  wrote:
> > > Hello!
> > >
> > > Over the last few months, it seems that tripleo-quickstart has evolved
> > > into a CI tool.  It's primarily used by computers, and not humans.
> > > tripleo-quickstart is a helpful set of ansible playbooks, and a
> > > collection of feature sets.  However, it's become less useful for
> > > setting up development environments by humans.  For example, devmode.sh
> > > was recently deprecated without a user-friendly replacement. Moreover,
> > > during some informal irc conversations in #oooq, some developers even
> > > mentioned the plan to merge tripleo-quickstart and tripleo-ci.
> >
> > I was recently directed to the reproducer-quickstart.sh script that's
> > written in the logs directory for all oooq CI jobs - does that help as
> > a replacement for the previous devmode interface?
> >
> > Not that familiar with it myself but it seems to target many of the
> > use-cases you mention e.g uniform reproducer for issues, potentially
> > quicker way to replicate CI results?
> >
> 
> It is very good for that. However, the problem I have with reproducer
> scripts is that they are tied to the CI output. If I am working on a patch,
> the only way I know to get a reproducer is to submit the patch and then
> wait for CI to finish and then run the script again myself.
> 
> It would be very useful if I there was a tool where I could run a specific
> CI job, with a gerrit patch included (or even a local change would be more
> amazing!). Perhaps even a reproducer script generator would do the job.
> 

Yes, the reproducer seems to work quite well.  It's just not very
user-friendly.  The issue is that you need to find the right CI job, go
to the logs, download the file, etc. Instead of simply cloning a repo,
installing the tool, and running it when needed.

As such, we already have a couple of patches to introduce a reproducer
script generator.  One by me, and one by Gabriele.

https://review.openstack.org/#/c/586843/
https://review.openstack.org/#/c/548005/

> 
> 
> 
> >
> > Steve
> >
> > __
> > 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] [tripleo] quickstart for humans

[Dougal Matthews]

On 31 August 2018 at 12:11, Steven Hardy  wrote:

> On Thu, Aug 30, 2018 at 3:28 PM, Honza Pokorny  wrote:
> > Hello!
> >
> > Over the last few months, it seems that tripleo-quickstart has evolved
> > into a CI tool.  It's primarily used by computers, and not humans.
> > tripleo-quickstart is a helpful set of ansible playbooks, and a
> > collection of feature sets.  However, it's become less useful for
> > setting up development environments by humans.  For example, devmode.sh
> > was recently deprecated without a user-friendly replacement. Moreover,
> > during some informal irc conversations in #oooq, some developers even
> > mentioned the plan to merge tripleo-quickstart and tripleo-ci.
>
> I was recently directed to the reproducer-quickstart.sh script that's
> written in the logs directory for all oooq CI jobs - does that help as
> a replacement for the previous devmode interface?
>
> Not that familiar with it myself but it seems to target many of the
> use-cases you mention e.g uniform reproducer for issues, potentially
> quicker way to replicate CI results?
>

It is very good for that. However, the problem I have with reproducer
scripts is that they are tied to the CI output. If I am working on a patch,
the only way I know to get a reproducer is to submit the patch and then
wait for CI to finish and then run the script again myself.

It would be very useful if I there was a tool where I could run a specific
CI job, with a gerrit patch included (or even a local change would be more
amazing!). Perhaps even a reproducer script generator would do the job.




>
> Steve
>
> __
> 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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

[Doug Hellmann]

Excerpts from Mehdi Abaakouk's message of 2018-08-31 08:09:00 +0200:
> Telemetry is ready

Here you go:

+++-+---+
| Subject| Repo 
  | URL | Branch|
+++-+---+
| remove job settings for Telemetry repositories | 
openstack-infra/project-config | https://review.openstack.org/598671 | 
master|
| import zuul job settings from project-config   | openstack/aodh   
  | https://review.openstack.org/598628 | master|
| switch documentation job to new PTI| openstack/aodh   
  | https://review.openstack.org/598629 | master|
| add python 3.6 unit test job   | openstack/aodh   
  | https://review.openstack.org/598630 | master|
| import zuul job settings from project-config   | openstack/aodh   
  | https://review.openstack.org/598648 | stable/ocata  |
| import zuul job settings from project-config   | openstack/aodh   
  | https://review.openstack.org/598653 | stable/pike   |
| import zuul job settings from project-config   | openstack/aodh   
  | https://review.openstack.org/598659 | stable/queens |
| import zuul job settings from project-config   | openstack/aodh   
  | https://review.openstack.org/598665 | stable/rocky  |
| import zuul job settings from project-config   | openstack/ceilometer 
  | https://review.openstack.org/598631 | master|
| switch documentation job to new PTI| openstack/ceilometer 
  | https://review.openstack.org/598632 | master|
| add python 3.6 unit test job   | openstack/ceilometer 
  | https://review.openstack.org/598633 | master|
| import zuul job settings from project-config   | openstack/ceilometer 
  | https://review.openstack.org/598649 | stable/ocata  |
| import zuul job settings from project-config   | openstack/ceilometer 
  | https://review.openstack.org/598654 | stable/pike   |
| import zuul job settings from project-config   | openstack/ceilometer 
  | https://review.openstack.org/598660 | stable/queens |
| import zuul job settings from project-config   | openstack/ceilometer 
  | https://review.openstack.org/598666 | stable/rocky  |
| import zuul job settings from project-config   | 
openstack/ceilometermiddleware | https://review.openstack.org/598634 | 
master|
| switch documentation job to new PTI| 
openstack/ceilometermiddleware | https://review.openstack.org/598635 | 
master|
| add python 3.6 unit test job   | 
openstack/ceilometermiddleware | https://review.openstack.org/598636 | 
master|
| import zuul job settings from project-config   | 
openstack/ceilometermiddleware | https://review.openstack.org/598650 | 
stable/ocata  |
| import zuul job settings from project-config   | 
openstack/ceilometermiddleware | https://review.openstack.org/598655 | 
stable/pike   |
| import zuul job settings from project-config   | 
openstack/ceilometermiddleware | https://review.openstack.org/598661 | 
stable/queens |
| import zuul job settings from project-config   | 
openstack/ceilometermiddleware | https://review.openstack.org/598667 | 
stable/rocky  |
| convert py35 jobs to py3   | openstack/panko  
  | https://review.openstack.org/575831 | master|
| import zuul job settings from project-config   | openstack/panko  
  | https://review.openstack.org/598637 | master|
| switch documentation job to new PTI| openstack/panko  
  | https://review.openstack.org/598638 | master|
| add python 3.6 unit test job   | openstack/panko  
  | https://review.openstack.org/598639 | master|
| import zuul job settings from project-config   | openstack/panko  
  | https://review.openstack.org/598651 | stable/ocata  |
| import zuul job settings from project-config   | openstack/panko  
  | https://review.openstack.org/598656 | stable/pike   |
| import zuul job settings from project-config   | openstack/panko  
  | https://review.openstack.org/598662 | stable/queens |
| import zuul job settings from project-config   | openstack/panko  
  | https://review.openstack.org/598668 | stable/rocky  |
| import zuul job settings from project-config   | openstack/python-aodhclient  
  | https://review.openstack.org/598640 | master|
| switch documentation 

Re: [openstack-dev] [Openstack-operators] [all] Bringing the community together (combine the lists!)

[Thomas Goirand]

On 08/30/2018 11:33 PM, Jeremy Stanley wrote:
> On 2018-08-30 22:49:26 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> I really don't want this. I'm happy with things being sorted in
>> multiple lists, even though I'm subscribed to multiples.
> 
> I understand where you're coming from

I'm coming from the time when OpenStack had a list on launchpad where
everything was mixed. We did the split because it was really annoying to
have everything mixed.

> I was accustomed to communities where developers had one mailing
> list, users had another, and whenever a user asked a question on the
> developer mailing list they were told to go away and bother the user
> mailing list instead (not even a good, old-fashioned "RTFM" for
> their trouble).

I don't think that's what we are doing. Usually, when someone does the
mistake, we do reply to him/her, at the same time pointing to the
correct list.

> You're probably intimately familiar with at least
> one of these communities. ;)

I know what you have in mind! Indeed, in that list, it happens that some
people are a bit harsh to users. Hopefully, the folks in OpenStack devel
aren't like this.

> As the years went by, it's become apparent to me that this is
> actually an antisocial behavior pattern

In the OpenStack lists, every day, some developers take the time to
answer users. So I don't see what there is to fix.

> I believe OpenStack actually wants users to see the
> development work which is underway, come to understand it, and
> become part of that process.

Users are very much welcome in our -dev list. I don't think there's a
problem here.

> Requiring them to have their
> conversations elsewhere sends the opposite message.

In many places and occasion, we've sent the correct message.

On 08/30/2018 11:45 PM, Jimmy McArthur wrote:
> IMO this is easily solved by tagging.  If emails are properly tagged
> (which they typically are), most email clients will properly sort on
> rules and you can just auto-delete if you're 100% not interested in a
> particular topic.

This topically works with folks used to send tags. It doesn't for new
comers, which is what you see with newbies coming to ask questions.

Cheers,

Thomas Goirand (zigo)

__
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 Carlos Goncalves (cgoncalves) as an Octavia core reviewer

[Nir Magnezi]

Carlos made a significant impact with quality reviews and code
contributions.
I think he would make a great addition to the core team.

+1 From me.

/Nir

On Fri, Aug 31, 2018 at 6:29 AM Jacky Hu  wrote:

> +1
> Definitely a good contributor for the octavia community.
>
> 发自我的 iPhone
>
> > 在 2018年8月31日，上午11:24，Michael Johnson  写道：
> >
> > Hello Octavia community,
> >
> > I would like to propose Carlos Goncalves as a core reviewer on the
> > Octavia project.
> >
> > Carlos has provided numerous enhancements to the Octavia project,
> > including setting up the grenade gate for Octavia upgrade testing.
> >
> > Over the last few releases he has also been providing quality reviews,
> > in line with the other core reviewers [1]. I feel that Carlos would
> > make an excellent 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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

[Doug Hellmann]

Excerpts from Adrian Turjak's message of 2018-08-31 17:51:15 +1200:
> Adjutant should be should be good to go. I don't believe there are any
> blockers (unless I've missed some).

I've proposed the needed patches:

+---++-+---+
| Subject   | Repo  
 | URL | Branch|
+---++-+---+
| remove job settings for adjutant repositories | 
openstack-infra/project-config | https://review.openstack.org/598620 | master   
 |
| import zuul job settings from project-config  | openstack/adjutant
 | https://review.openstack.org/598615 | master|
| add python 3.6 unit test job  | openstack/adjutant
 | https://review.openstack.org/598616 | master|
| import zuul job settings from project-config  | openstack/adjutant
 | https://review.openstack.org/598617 | stable/pike   |
| import zuul job settings from project-config  | openstack/adjutant
 | https://review.openstack.org/598618 | stable/queens |
| import zuul job settings from project-config  | openstack/adjutant
 | https://review.openstack.org/598619 | stable/rocky  |
+---++-+---+

__
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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

[Doug Hellmann]

Excerpts from Samuel Cassiba's message of 2018-08-30 16:50:30 -0700:
> On Thu, Aug 30, 2018 at 4:24 PM, Doug Hellmann  wrote:
> > Below is the list of project teams that have not yet started migrating
> > their zuul configuration. If you're ready to go, please respond to this
> > email to let us know so we can start proposing patches.
> >
> > Doug
> >
> > | adjutant| 3 repos   |
> > | barbican| 5 repos   |
> > | Chef OpenStack  | 19 repos  |
> > | cinder  | 6 repos   |
> > | cloudkitty  | 5 repos   |
> > | I18n| 2 repos   |
> > | Infrastructure  | 158 repos |
> > | loci| 1 repos   |
> > | nova| 6 repos   |
> > | OpenStack Charms| 80 repos  |
> > | Packaging-rpm   | 4 repos   |
> > | Puppet OpenStack| 47 repos  |
> > | Quality Assurance   | 22 repos  |
> > | Telemetry   | 8 repos   |
> > | trove   | 5 repos   |
> >
> 
> On behalf of Chef OpenStack, that one is good to go.
> 
> Best,
> Samuel (scas)
> 

It looks like most of the settings for the Chef repos are already
in-tree, so there are just these 2 patches to consider:

+-++-++
| Subject | Repo
   | URL | Branch |
+-++-++
| remove job settings for Chef OpenStack repositories | 
openstack-infra/project-config | https://review.openstack.org/598614 | master |
| import zuul job settings from project-config| 
openstack/openstack-chef-specs | https://review.openstack.org/598613 | master |
+-++-++

__
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] [Openstack-operators] [ironic][tripleo][edge] Discussing ironic federation and distributed deployments

[Emilien Macchi]

On Fri, Aug 31, 2018 at 4:42 AM Dmitry Tantsur  wrote:

> This is about a call a week before the PTG, not the PTG itself. You're
> still
> very welcome to join!
>

It's good too! Our TripleO IRC meeting is at 14 UTC.

Thanks,
-- 
Emilien Macchi
__
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] [charms] Deployment guide stable/rocky cut

[Edward Hope-Morley]

Hi Frode, I think it would be a good idea to add a link to the charm
deployment guide at the following page:

https://docs.openstack.org/rocky/deploy/

- Ed


On 17/08/18 08:47, Frode Nordahl wrote:
> Hello OpenStack charmers,
>
> I am writing to inform you that  a `stable/rocky` branch has been cut
> for the `openstack/charm-deployment-guide` repository.
>
> Should there be any further updates to the guide before the release
> the changes will need to be landed in `master` and then back-ported to
> `stable/rocky`.
>
> -- 
> Frode Nordahl
> Software Engineer
> Canonical 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

__
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][tripleo][oslo][all] Bumping eventlet to 0.24.1

[Jim Rollenhagen]

On Thu, Aug 30, 2018 at 11:10 PM, Matthew Thode 
wrote:

> On 18-08-30 20:52:46, Matthew Thode wrote:
> > On 18-08-23 09:50:13, Matthew Thode wrote:
> > > This is your warning, if you have concerns please comment in
> > > https://review.openstack.org/589382 .  cross tests pass, so that's a
> > > good sign... atm this is only for stein.
> > >
> >
> > Consider yourself on notice, https://review.openstack.org/589382 is
> > planned to be merged on monday.
> >
>
> A bit more of follow up since that was so dry.  There are some projects
> that have not branched (mainly cycle-trailing and plugins).
>
> There has historically been some breakage with each eventlet update,
> this one is not expected to be much different unfortunately.  Currently
> there are known issues with oslo.service but they look solvable.  A list
> of all projects using eventlet is attached.
>
> The full list of non-branched projects will be at the bottom of this
> message, but the projects that I think should be more careful are the
> following.
>
> kolla kolla-ansible heat-agents heat-dashboard tripleo-ipsec
>
> the rest of the repos seem to be plugins, which I'm personally less
> concerned about, but should still be branched (preferably sooner rather
> than later).
>

Tempest plugins, like tempest, are not meant to be branched:
http://lists.openstack.org/pipermail/openstack-dev/2018-August/133211.html

// jim


>
> ansible-role-container-registry
> ansible-role-redhat-subscription
> ansible-role-tripleo-modify-image
> barbican-tempest-plugin
> blazar-tempest-plugin
> cinder-tempest-plugin
> cloudkitty-tempest-plugin
> congress-tempest-plugin
> designate-tempest-plugin
> devstack-plugin-amqp1
> devstack-plugin-kafka
> ec2api-tempest-plugin
> heat-agents
> heat-dashboard
> heat-tempest-plugin
> ironic-tempest-plugin
> keystone-tempest-plugin
> kolla-ansible
> kolla
> kuryr-tempest-plugin
> magnum-tempest-plugin
> manila-tempest-plugin
> mistral-tempest-plugin
> monasca-kibana-plugin
> monasca-tempest-plugin
> murano-tempest-plugin
> networking-generic-switch-tempest-plugin
> neutron-tempest-plugin
> octavia-tempest-plugin
> oswin-tempest-plugin
> patrole
> release-test
> sahara-tests
> senlin-tempest-plugin
> solum-tempest-plugin
> telemetry-tempest-plugin
> tempest-tripleo-ui
> tempest
> tripleo-ipsec
> trove-tempest-plugin
> vitrage-tempest-plugin
> watcher-tempest-plugin
> zaqar-tempest-plugin
> zun-tempest-plugin
>
> --
> Matthew Thode (prometheanfire)
>
> __
> 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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

[Tobias Urdin]

Oh, that's bad. I will abandon.
It's a go for Puppet then.

Best regards

On 08/31/2018 12:36 PM, Andreas Jaeger wrote:

On 2018-08-31 10:49, Tobias Urdin wrote:

Hello Doug,

I've proposed moving all job config from project-config to the repos [1].
I don't know what to do with the periodic job here [2] should that be
left in project-config or moved?


Tobias, I'm sorry to see you doing this - but please abandon!  You've
done only part of the work and finishing it will complicate it. Doug has
scripts for these and can easily run that. What Doug asked for was for
an official "go ahead" from the puppet team,

Andreas



__
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] quickstart for humans

[Steven Hardy]

On Thu, Aug 30, 2018 at 3:28 PM, Honza Pokorny  wrote:
> Hello!
>
> Over the last few months, it seems that tripleo-quickstart has evolved
> into a CI tool.  It's primarily used by computers, and not humans.
> tripleo-quickstart is a helpful set of ansible playbooks, and a
> collection of feature sets.  However, it's become less useful for
> setting up development environments by humans.  For example, devmode.sh
> was recently deprecated without a user-friendly replacement. Moreover,
> during some informal irc conversations in #oooq, some developers even
> mentioned the plan to merge tripleo-quickstart and tripleo-ci.

I was recently directed to the reproducer-quickstart.sh script that's
written in the logs directory for all oooq CI jobs - does that help as
a replacement for the previous devmode interface?

Not that familiar with it myself but it seems to target many of the
use-cases you mention e.g uniform reproducer for issues, potentially
quicker way to replicate CI results?

Steve

__
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] [tempest][qa][congress] trouble setting tempest feature flag

[Ghanshyam Mann]

  On Wed, 29 Aug 2018 08:20:37 +0900 Eric K  
wrote  
 > Ha. Turned out to be a simple mistake in hyphens vs underscores.

Thanks for update and good to know it is resolved now. Sorry I could not 
checked this further due to PTO.

-gmann

 > On Tue, Aug 28, 2018 at 3:06 PM Eric K  wrote:
 > >
 > > Any thoughts on what could be going wrong that the tempest tests still
 > > see the default conf values rather than those set here? Thanks lots!
 > >
 > > Here is the devstack log line showing the flags being set:
 > > http://logs.openstack.org/64/594564/4/check/congress-devstack-api-mysql/ce34264/logs/devstacklog.txt.gz#_2018-08-28_21_23_15_934
 > >
 > > On Wed, Aug 22, 2018 at 9:12 AM Eric K  wrote:
 > > >
 > > > Hi all,
 > > >
 > > > I have added feature flags for the congress tempest plugin [1] and set
 > > > them in the devstack plugin [2], but the flags seem to be ignored. The
 > > > tests are skipped [3] according to the default False flag rather than
 > > > run according to the True flag set in devstack plugin. Any hints on
 > > > what may be wrong? Thanks so much!
 > > >
 > > > [1] https://review.openstack.org/#/c/594747/3
 > > > [2] https://review.openstack.org/#/c/594793/1/devstack/plugin.sh
 > > > [3] 
 > > > http://logs.openstack.org/64/594564/3/check/congress-devstack-api-mysql/b2cd46f/logs/testr_results.html.gz
 > > > (the bottom two skipped tests were expected to run)
 > 
 > __
 > 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-lxd]Feature support matrix of nova-lxd

[James Page]

Hi Rikimaru

On Fri, 31 Aug 2018 at 11:28 Rikimaru Honjo 
wrote:

> Hello,
>
> I'm planning to write a feature support matrix[1] of nova-lxd and
> add it to nova-lxd repository.
> A similar document exists as todo.txt[2], but this is old.
>
> Can I write it?
>

Yes please!


> If someone is writing the same document now, I'll stop writing.
>

They are not - please go ahead - this would be a valuable contribution for
users evaluating this driver.

Regards

Jjames
__
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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

[Andreas Jaeger]

On 2018-08-31 10:49, Tobias Urdin wrote:

Hello Doug,

I've proposed moving all job config from project-config to the repos [1].
I don't know what to do with the periodic job here [2] should that be 
left in project-config or moved?




Tobias, I'm sorry to see you doing this - but please abandon!  You've 
done only part of the work and finishing it will complicate it. Doug has 
scripts for these and can easily run that. What Doug asked for was for 
an official "go ahead" from the puppet team,


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] quickstart for humans

[Cédric Jeanneret]

On 08/30/2018 04:28 PM, Honza Pokorny wrote:
> Hello!
> 
> Over the last few months, it seems that tripleo-quickstart has evolved
> into a CI tool.  It's primarily used by computers, and not humans.
> tripleo-quickstart is a helpful set of ansible playbooks, and a
> collection of feature sets.  However, it's become less useful for
> setting up development environments by humans.  For example, devmode.sh
> was recently deprecated without a user-friendly replacement. Moreover,
> during some informal irc conversations in #oooq, some developers even
> mentioned the plan to merge tripleo-quickstart and tripleo-ci.
> 
> I think it would be beneficial to create a set of defaults for
> tripleo-quickstart that can be used to spin up new environments; a set
> of defaults for humans.  This can either be a well-maintained script in
> tripleo-quickstart itself, or a brand new project, e.g.
> tripleo-quickstart-humans.  The number of settings, knobs, and flags
> should be kept to a minimum.
> 
> This would accomplish two goals:
> 
> 1.  It would bring uniformity to the team.  Each environment is
> installed the same way.  When something goes wrong, we can
> eliminate differences in setup when debugging.  This should save a
> lot of time.
> 
> 2.  Quicker and more reliable environment setup.  If the set of defaults
> is used by many people, it should container fewer bugs because more
> people using something should translate into more bug reports, and
> more bug fixes.
> 
> These thoughts are coming from the context of tripleo-ui development.  I
> need an environment in order to develop, but I don't necessarily always
> care about how it's installed.  I want something that works for most
> scenarios.
> 
> What do you think?  Does this make sense?  Does something like this
> already exist?

Hello,

As an exercise in order to learn a bit more ansible and refresh my
deploy knowledge, I've create that simple thing:
https://github.com/cjeanner/tripleo-lab
It's "more or less generic", but it was probably never deployed outside
my home infra - its aim is to provide a quick'n'dropable libvirt env,
allowing some tweaking in a convenient way.
That's not at quickstart level - but in order to boostrap an undercloud
or a more complete env, it's more than enough.

The other reason I made this was the feeling quickstart is a beast, not
really easy to master - apparently I'm not the only one """fearing
it. I probably didn't dig deep enough. And I wanted to get my own thing,
with some proxy/local mirror support in order to alleviate network
traffic on my home line (it's fast, but still... it's faster on the LAN
;) ).

Cheers,

C.

> 
> Thanks for listening!
> 
> Honza
> 
> __
> 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
> 

-- 
Cédric Jeanneret
Software Engineer
DFG:DF



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] [nova-lxd]Feature support matrix of nova-lxd

[Rikimaru Honjo]

Hello,

I'm planning to write a feature support matrix[1] of nova-lxd and
add it to nova-lxd repository.
A similar document exists as todo.txt[2], but this is old.

Can I write it?
If someone is writing the same document now, I'll stop writing.

[1]
It will be like this:
https://docs.openstack.org/nova/latest/user/support-matrix.html

[2]
https://github.com/openstack/nova-lxd/blob/master/specs/todo.txt

Best regards,
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@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

[openstack-dev] [upgrade][sig] Upgrade SIG/Stein PTG etherpad

[James Page]

Hi Folks

We have a half day planned on Monday afternoon in Denver for the customary
discussion around OpenStack upgrades.

I've started a pad here:
https://etherpad.openstack.org/p/upgrade-sig-ptg-stein

Please feel free to add ideas and indicate if you will be participating in
the discussion.

Cheers

James
__
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] quickstart for humans

[Jiří Stránský]

On 30.8.2018 16:28, Honza Pokorny wrote:

Hello!

Over the last few months, it seems that tripleo-quickstart has evolved
into a CI tool.  It's primarily used by computers, and not humans.
tripleo-quickstart is a helpful set of ansible playbooks, and a
collection of feature sets.  However, it's become less useful for
setting up development environments by humans.  For example, devmode.sh
was recently deprecated without a user-friendly replacement. Moreover,
during some informal irc conversations in #oooq, some developers even
mentioned the plan to merge tripleo-quickstart and tripleo-ci.

I think it would be beneficial to create a set of defaults for
tripleo-quickstart that can be used to spin up new environments; a set
of defaults for humans.  This can either be a well-maintained script in
tripleo-quickstart itself, or a brand new project, e.g.
tripleo-quickstart-humans.  The number of settings, knobs, and flags
should be kept to a minimum.

This would accomplish two goals:

1.  It would bring uniformity to the team.  Each environment is
 installed the same way.  When something goes wrong, we can
 eliminate differences in setup when debugging.  This should save a
 lot of time.

2.  Quicker and more reliable environment setup.  If the set of defaults
 is used by many people, it should container fewer bugs because more
 people using something should translate into more bug reports, and
 more bug fixes.

These thoughts are coming from the context of tripleo-ui development.  I
need an environment in order to develop, but I don't necessarily always
care about how it's installed.  I want something that works for most
scenarios.

What do you think?  Does this make sense?  Does something like this
already exist?


I've been tinkering in this area for a long time, previously with 
inlunch [1], and now quicklunch [2] (which is a wrapper around 
quickstart), and i've been involved in various conversations about this 
over the past years, so i feel like i may have some insight to share on 
all this in general.


* A single config for everyone is not achievable, IMO. Someone wants HA, 
others want Ceph, Sahara, OpenDaylight, etc. There's no overlap here to 
be found i think, while respecting that the resulting deployment needs 
to be of reasonable size.


* "for humans" definition differs significantly based on who you ask. 
E.g. my intention with [2] was to readily expose *more* knobs and tweaks 
and be more transparent with the underlying workings of Ansible, because 
i felt like quickstart.sh hides too much from me. In my opinion [2] is 
sufficiently "for humans", yet it does pretty much the opposite of what 
you're looking for.


* It's hard to strike a good balance between for-CI and for-humans (and 
the various definitions of for-humans ;) ), but it's worth to keep doing 
that as high in the software stack as possible, because there is great 
value in running CI and all dev envs with the same (underlying) tool. 
Over the years i've observed that Quickstart is trying hard to 
consolidate various requirements, but it's simply difficult to please 
all stakeholders, as often the requirements are somewhat contradictory. 
(This point is not in conflict with anything discussed so far, but i 
just think it's worth mentioning, so that we don't display Quickstart in 
a way it doesn't deserve.)


These points are to illustrate my previous experience, that when we go 
above a certain layer of "this is a generic all-purpose configurable 
tool" (= Quickstart), it seems to yield better results to focus on 
building the next layer/wrapper for "humans like me" rather than "humans 
in general".


So with regards to the specific goal stemming from tripleo-ui dev 
requirements as you mentioned above, IMO it makes sense to team up with 
UI folks and others who have similar expectations about what a TripleO 
dev env means, and make some wrapper around Quickstart like you 
suggested. Since you want to reduce rather than extend the number of 
knobs, it could even be just a script perhaps.


My 2 cents, i hope it helps a bit.

Jirka

[1] https://github.com/jistr/inlunch
[2] https://gitlab.com/jistr/quicklunch



Thanks for listening!

Honza

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

[Jesse Pretorius]

> From: Andy McCrae 

> Now that Rocky is all but ready it seems like a good time! Since changing 
> roles I've not been able to keep up enough focus on reviews and other 
> obligations - so I think it's time to step aside as a core reviewer.

> I want to say thanks to everybody in the community, I'm really proud to see 
> the work we've done and how the OSA team has grown. I've learned a tonne from 
> all of you - it's definitely been a great experience.

Right from the start of the project, back in Icehouse, your can-do attitude was 
inspiring. This carried through to your leadership of the project as PTL later. 
You are already missed. Thank you for everything you put into it and we wish 
you the best for your next endeavours.


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

[Christophe Sauthier]

Hello Doug

Le 2018-08-31 01:24, Doug Hellmann a écrit :

Below is the list of project teams that have not yet started migrating
their zuul configuration. If you're ready to go, please respond to 
this

email to let us know so we can start proposing patches.

Doug

| adjutant| 3 repos   |
| barbican| 5 repos   |
| Chef OpenStack  | 19 repos  |
| cinder  | 6 repos   |
| cloudkitty  | 5 repos   |
| I18n| 2 repos   |
| Infrastructure  | 158 repos |
| loci| 1 repos   |
| nova| 6 repos   |
| OpenStack Charms| 80 repos  |
| Packaging-rpm   | 4 repos   |
| Puppet OpenStack| 47 repos  |
| Quality Assurance   | 22 repos  |
| Telemetry   | 8 repos   |
| trove   | 5 repos   |


We are ready to start on the cloudkitty's team !

   Christophe



Christophe Sauthier
CEO

Objectif Libre : Au service de votre Cloud

+33 (0) 6 16 98 63 96 | christophe.sauth...@objectif-libre.com

https://www.objectif-libre.com | @objectiflibre
Recevez la Pause Cloud Et DevOps : https://olib.re/abo-pause



__
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] Bringing the community together (combine the lists!)

[Thierry Carrez]

Jeremy Stanley wrote:

[...]
The proposal is simple: create a new openstack-discuss mailing list
to cover all the above sorts of discussion and stop using the other
four. [...]

Also, in case you were wondering, no the irony of cross-posting this
message to four mailing lists is not lost on me. ;)


As someone who just had to process a dozen of ML moderation requests 
about non-member posting to lists due to replies to a cross-posted 
topic, I wholeheartedly support the list merging :)


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

Re: [openstack-dev] [Neutron] Stepping down from Neutron core team

[Slawomir Kaplonski]

It’s sad news. Thanks Kuba for all Your help You gave me when I was newcomer in 
Neutron community.
Good luck in Your next projects :)

> Wiadomość napisana przez Jakub Libosvar  w dniu 
> 31.08.2018, o godz. 10:24:
> 
> Hi all,
> 
> as you have might already heard, I'm no longer involved in Neutron
> development due to some changes. Therefore I'm officially stepping down
> from the core team because I can't provide same quality reviews as I
> tried to do before.
> 
> I'd like to thank you all for the opportunity I was given in the Neutron
> team, thank you for all I have learned over the years professionally,
> technically and personally. Tomorrow it's gonna be exactly 5 years since
> I started hacking Neutron and I must say I really enjoyed working with
> all Neutrinos here and I had privilege to meet most of you in person and
> that has an extreme value for me. Keep on being a great community!
> 
> Thank you again!
> Kuba
> 
> __
> 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

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

[Tobias Urdin]

Hello Doug,

I've proposed moving all job config from project-config to the repos [1].
I don't know what to do with the periodic job here [2] should that be 
left in project-config or moved?


Best regards
Tobias

[1] https://review.openstack.org/#/q/topic:move-zuul-config
[2] 
https://github.com/openstack-infra/project-config/blob/master/zuul.d/projects.yaml#L10891


On 08/31/2018 01:34 AM, Doug Hellmann wrote:

Below is the list of project teams that have not yet started migrating
their zuul configuration. If you're ready to go, please respond to this
email to let us know so we can start proposing patches.

Doug

| adjutant| 3 repos   |
| barbican| 5 repos   |
| Chef OpenStack  | 19 repos  |
| cinder  | 6 repos   |
| cloudkitty  | 5 repos   |
| I18n| 2 repos   |
| Infrastructure  | 158 repos |
| loci| 1 repos   |
| nova| 6 repos   |
| OpenStack Charms| 80 repos  |
| Packaging-rpm   | 4 repos   |
| Puppet OpenStack| 47 repos  |
| Quality Assurance   | 22 repos  |
| Telemetry   | 8 repos   |
| trove   | 5 repos   |

__
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] PTG topics and agenda

[Juan Antonio Osorio Robles]

Thanks, merged the topics.


On 08/30/2018 07:10 PM, Giulio Fidente wrote:
> On 8/28/18 2:50 PM, Juan Antonio Osorio Robles wrote:
>> Hello folks!
>>
>>
>> With the PTG being quite soon, I just wanted to remind folks to add your
>> topics on the etherpad: https://etherpad.openstack.org/p/tripleo-ptg-stein
> thanks Juan,
>
> I think the Edge (line 53) and Split Control Plane (line 74) sessions
> can probably be merged into a single one.
>
> I'd be fine with James driving it, I think it'd be fine to discuss the
> "control plane updates" issue [1] in that same session.
>
> 1.
> http://lists.openstack.org/pipermail/openstack-dev/2018-August/133247.html
>


__
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] [Openstack-operators] [ironic][tripleo][edge] Discussing ironic federation and distributed deployments

[Dmitry Tantsur]

On 08/30/2018 07:29 PM, Emilien Macchi wrote:



On Thu, Aug 30, 2018 at 1:21 PM Julia Kreger > wrote:


Greetings everyone,

It looks like the most agreeable time on the doodle[1] seems to be
Tuesday September 4th at 13:00 UTC. Are there any objections to using
this time?

If not, I'll go ahead and create an etherpad, and setup a bluejeans
call for that time to enable high bandwidth discussion.


TripleO sessions start on Wednesday, so +1 from us (unless I missed something).


This is about a call a week before the PTG, not the PTG itself. You're still 
very welcome to join!


Dmitry


--
Emilien Macchi


__
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] [Neutron] Stepping down from Neutron core team

[Daniel Alvarez Sanchez]

Thanks a lot Kuba for all your contributions!
You've been a great mentor to me since I joined OpenStack and I'm so happy
that I got to work with you. Great engineer and even better person!
All the best, my friend!

On Fri, Aug 31, 2018 at 10:25 AM Jakub Libosvar  wrote:

> Hi all,
>
> as you have might already heard, I'm no longer involved in Neutron
> development due to some changes. Therefore I'm officially stepping down
> from the core team because I can't provide same quality reviews as I
> tried to do before.
>
> I'd like to thank you all for the opportunity I was given in the Neutron
> team, thank you for all I have learned over the years professionally,
> technically and personally. Tomorrow it's gonna be exactly 5 years since
> I started hacking Neutron and I must say I really enjoyed working with
> all Neutrinos here and I had privilege to meet most of you in person and
> that has an extreme value for me. Keep on being a great community!
>
> Thank you again!
> Kuba
>
> __
> 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] [Openstack-operators] [Openstack-sigs] [all] Bringing the community together (combine the lists!)

[Stephen Finucane]

On Fri, 2018-08-31 at 10:03 +1000, Tony Breeds wrote:
> On Thu, Aug 30, 2018 at 09:12:57PM +, Jeremy Stanley wrote:
> > On 2018-08-31 01:13:58 +0800 (+0800), Rico Lin wrote:
> > [...]
> > > What needs to be done for this is full topic categories support
> > > under `options` page so people get to filter emails properly.
> > 
> > [...]
> > 
> > Unfortunately, topic filtering is one of the MM2 features the
> > Mailman community decided nobody used (or at least not enough to
> > warrant preserving it in MM3). I do think we need to be consistent
> > about tagging subjects to make client-side filtering more effective
> > for people who want that, but if we _do_ want to be able to upgrade
> > we shouldn't continue to rely on server-side filtering support in
> > Mailman unless we can somehow work with them to help in
> > reimplementing it.
> 
> The suggestion is to implement it as a 3rd party plugin or work with the
> mm community to implement:
> https://wiki.mailman.psf.io/DEV/Dynamic%20Sublists
> 
> So if we decide we really want that in mm3 we have options.
> 
> Yours Tony.

I've tinked with mailman 3 before so I could probably take a shot at
this over the next few week(end)s; however, I've no idea how this
feature is supposed to work. Any chance an admin of the current list
could send me a couple of screenshots of the feature in mailman 2 along
with a brief description of the feature? Alternatively, maybe we could
upload them to the wiki page Tony linked above or, better yet, to the
technical details page for same:

  https://wiki.mailman.psf.io/DEV/Brief%20Technical%20Details

Cheers,
Stephen


__
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][nova] Small bandwidth demo on the PTG

[Balázs Gibizer]

On Thu, Aug 30, 2018 at 8:13 PM, melanie witt  
wrote:

On Thu, 30 Aug 2018 12:43:06 -0500, Miguel Lavalle wrote:

Gibi, Bence,

In fact, I added the demo explicitly to the Neutron PTG agenda from 
1:30 to 2, to give it visiblilty


I'm interested in seeing the demo too. Will the demo be shown at the 
Neutron room or the Nova room? Historically, lunch has ended at 1:30, 
so this will be during the same time as the Neutron/Nova cross 
project time. Should we just co-locate together for the demo and the 
session? I expect anyone watching the demo will want to participate 
in the Neutron/Nova session as well. Either room is fine by me.




I assume that the nova - neturon cross project session will be in the 
nova room, so I propose to have the demo there as well to avoid 
unnecessarily moving people around. For us it is totally OK to start 
the demo at 1:30.


Cheers,
gibi



-melanie

On Thu, Aug 30, 2018 at 3:55 AM, Balázs Gibizer 
mailto:balazs.gibi...@ericsson.com>> 
wrote:


Hi,

Based on the Nova PTG planning etherpad [1] there is a need to 
talk

about the current state of the bandwidth work [2][3]. Bence
(rubasov) has already planned to show a small demo to Neutron 
folks

about the current state of the implementation. So Bence and I are
wondering about bringing that demo close to the nova - neutron 
cross

project session. That session is currently planned to happen
Thursday after lunch. So we are think about showing the demo 
right

before that session starts. It would start 30 minutes before the
nova - neutron cross project session.

Are Nova folks also interested in seeing such a demo?

If you are interested in seeing the demo please drop us a line or
ping us in IRC so we know who should we wait for.

Cheers,
gibi

[1] https://etherpad.openstack.org/p/nova-ptg-stein

[2]

https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html



[3]

https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/bandwidth-resource-provider.html






__

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

[Frank Kloeker]

Hey Andy,

I can only underline what Ian says. It was a pleasure to work with you, 
many thanks for your kind support all the time. Keep your ears stiff, 
what we say in Germany. And good luck :)


kind regards
Frank

Am 2018-08-30 20:05, schrieb Ian Y. Choi:

Hello Andy,

Thanks a lot for your work on OpenStack-Ansible team.

It was very happy to collaborate with you as different teams (me: I18n
team) during Ocata and Pike release cycles,
and I think I18n team now has better insight on OpenStack-Ansible
thanks to the help from you and so many kind contributors.


With many thanks,

/Ian

Andy McCrae wrote on 8/31/2018 2:40 AM:
Now that Rocky is all but ready it seems like a good time! Since 
changing roles I've not been able to keep up enough focus on reviews 
and other obligations - so I think it's time to step aside as a core 
reviewer.


I want to say thanks to everybody in the community, I'm really proud 
to see the work we've done and how the OSA team has grown. I've 
learned a tonne from all of you - it's definitely been a great 
experience.


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




__
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] [Neutron] Stepping down from Neutron core team

[Jakub Libosvar]

Hi all,

as you have might already heard, I'm no longer involved in Neutron
development due to some changes. Therefore I'm officially stepping down
from the core team because I can't provide same quality reviews as I
tried to do before.

I'd like to thank you all for the opportunity I was given in the Neutron
team, thank you for all I have learned over the years professionally,
technically and personally. Tomorrow it's gonna be exactly 5 years since
I started hacking Neutron and I must say I really enjoyed working with
all Neutrinos here and I had privilege to meet most of you in person and
that has an extreme value for me. Keep on being a great community!

Thank you again!
Kuba

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

[Markos Chandras]

On 30/08/18 18:40, Andy McCrae wrote:
> Now that Rocky is all but ready it seems like a good time! Since
> changing roles I've not been able to keep up enough focus on reviews and
> other obligations - so I think it's time to step aside as a core reviewer.
> 
> I want to say thanks to everybody in the community, I'm really proud to
> see the work we've done and how the OSA team has grown. I've learned a
> tonne from all of you - it's definitely been a great experience.
> 
> Thanks,
> Andy
> 
> 
Hello Andy,

It is sad to see you go. Thank you very much for everything you've done
for OpenStack-Ansible and for trusting me as a core reviewer when I
still was relatively a new to the project.

Best of luck on your new role :)

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

__
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] [goals][python3][adjutant][barbican][chef][cinder][cloudkitty][i18n][infra][loci][nova][charms][rpm][puppet][qa][telemetry][trove] join the bandwagon!

[Mehdi Abaakouk]

Telemetry is ready

On Thu, Aug 30, 2018 at 07:24:23PM -0400, Doug Hellmann wrote:

Below is the list of project teams that have not yet started migrating
their zuul configuration. If you're ready to go, please respond to this
email to let us know so we can start proposing patches.

Doug

| adjutant| 3 repos   |
| barbican| 5 repos   |
| Chef OpenStack  | 19 repos  |
| cinder  | 6 repos   |
| cloudkitty  | 5 repos   |
| I18n| 2 repos   |
| Infrastructure  | 158 repos |
| loci| 1 repos   |
| nova| 6 repos   |
| OpenStack Charms| 80 repos  |
| Packaging-rpm   | 4 repos   |
| Puppet OpenStack| 47 repos  |
| Quality Assurance   | 22 repos  |
| Telemetry   | 8 repos   |
| trove   | 5 repos   |

__
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


--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
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