Re: [openstack-dev] [kolla] Dropping core reviewer

[Surya Singh]

words are not strong enough to appreciate your immense contribution and
help in OpenStack community.
Projects like Kolla, Heat and Magnum are still rocking and many more to
come in future from you.
Hope to see you around.

Wish you all the luck !!
-- Surya

On Wed, Aug 8, 2018 at 6:15 PM Paul Bourke  wrote:

> +1. Will always have good memories of when Steve was getting the project
> off the ground. Thanks Steve for doing a great job of building the
> community around Kolla, and for all your help in general!
>
> Best of luck,
> -Paul
>
> On 08/08/18 12:23, Eduardo Gonzalez wrote:
> > Steve,
> >
> > Is sad to see you leaving kolla core team, hope to still see you around
> > IRC and Summit/PTGs.
> >
> > I truly appreciate your leadership, guidance and commitment to make
> > kolla the great project it is now.
> >
> > Best luck on your new projects and board of directors.
> >
> > Regards
> >
> >
> >
> >
> >
> > 2018-08-07 16:28 GMT+02:00 Steven Dake (stdake)  > >:
> >
> > Kollians,
> >
> >
> > Many of you that know me well know my feelings towards participating
> > as a core reviewer in a project.  Folks with the ability to +2/+W
> > gerrit changes can sometimes unintentionally harm a codebase if they
> > are not consistently reviewing and maintaining codebase context.  I
> > also believe in leading an exception-free life, and I'm no exception
> > to my own rules.  As I am not reviewing Kolla actively given my
> > OpenStack individually elected board of directors service and other
> > responsibilities, I am dropping core reviewer ability for the Kolla
> > repositories.
> >
> >
> > I want to take a moment to thank the thousands of people that have
> > contributed and shaped Kolla into the modern deployment system for
> > OpenStack that it is today.  I personally find Kolla to be my finest
> > body of work as a leader.  Kolla would not have been possible
> > without the involvement of the OpenStack global community working
> > together to resolve the operational pain points of OpenStack.  Thank
> > you for your contributions.
> >
> >
> > Finally, quoting Thierry [1] from our initial application to
> > OpenStack, " ... Long live Kolla!"
> >
> >
> > Cheers!
> >
> > -steve
> >
> >
> > [1] https://review.openstack.org/#/c/206789/
> > 
> >
> >
> >
> >
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://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] [requirements][release][congress] FFE request to bump python-monascaclient to 1.12.1

[Matthew Thode]

On 18-08-08 18:00:35, Eric K wrote:
> Requesting the raised minimun just for openstack/congress.
> https://review.openstack.org/#/c/590021/
> 
> No re-release required; it'll just take effect in RC1.
> 
> 
> 
> On 8/8/18, 2:06 PM, "Matthew Thode"  wrote:
> 
> >On 18-08-08 13:14:08, Eric K wrote:
> >> python-monascaclient 1.12.0 paired with osc-lib 1.11.0 seems to
> >> experience a problem around Session.
> >> 
> >> python-monascaclient 1.12.1 fixes the issue [1]. So I'd like to bump
> >> congress requirements to python-monascaclient>=1.12.1 if it is not
> >> disruptive to packaging [2]. If it is disruptive, we can just note it
> >> as a known issue.
> >
> >Which project(s) will need the new minimum?  Those projects would need
> >re-releases.  Then my question then becomes if those projects need a
> >raised minumum too, and for which project(s).  And so on.
> >

SGTM then, ack by requirements

-- 
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] [requirements][release][congress] FFE request to bump doc req sphinx to 1.7.3

[Matthew Thode]

On 18-08-08 18:00:14, Eric K wrote:
> Requesting the raised minimun just for openstack/congress.
> https://review.openstack.org/#/c/589995/
> 
> No re-release required; it'll just take effect in RC1.
> 
> On 8/8/18, 2:07 PM, "Matthew Thode"  wrote:
> 
> >On 18-08-08 13:20:47, Eric K wrote:
> >> Lower versions of sphinx seems to experience a problem where the
> >> exclude_patterns option is not in effect. I'd like to bump the
> >> docs/requirements to sphinx>=1.7.3 if it is not disruptive to
> >> packaging. If it is disruptive to packaging we can leave it as is.
> >> 
> >> Thanks!
> >> 
> >> https://review.openstack.org/#/c/589995/
> >> 
> >
> >Which project(s) will need the new minimum?  Those projects would need
> >re-releases.  Then my question then becomes if those projects need a
> >raised minumum too, and for which project(s).  And so on.
> >

ack from requirements then

-- 
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] Stepping down as coordinator for the Outreachy internships

[Remo Mattei]

Great Job!! Victoria. 

Ciao

> On Aug 8, 2018, at 19:28, Ghanshyam Mann  wrote:
> 
> Thanks Victoria  for such a great work and well coordinated. You have done 
> remarkable work in internships program. 
> 
> -gmann 
> 
>  On Wed, 08 Aug 2018 08:47:28 +0900 Victoria Martínez de la Cruz 
>  wrote  
>> Hi all,
>> I'm reaching you out to let you know that I'll be stepping down as 
>> coordinator for OpenStack next round. I had been contributing to this effort 
>> for several rounds now and I believe is a good moment for somebody else to 
>> take the lead. You all know how important is Outreachy to me and I'm 
>> grateful for all the amazing things I've done as part of the Outreachy 
>> program and all the great people I've met in the way. I plan to keep 
>> involved with the internships but leave the coordination tasks to somebody 
>> else.
>> If you are interested in becoming an Outreachy coordinator, let me know and 
>> I can share my experience and provide some guidance.
>> Thanks,
>> Victoria 
>> __
>> 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] [nova][placement] Excessive WARNING level log messages in placement-api

[Jay Pipes]

For evidence, see:

http://logs.openstack.org/41/590041/1/check/tempest-full-py3/db08dec/controller/logs/screen-placement-api.txt.gz?level=WARNING

thousands of these are filling the logs with WARNING-level log messages, 
making it difficult to find anything:


Aug 08 22:17:30.837557 ubuntu-xenial-inap-mtl01-0001226060 
devstack@placement-api.service[14403]: WARNING py.warnings 
[req-a809b022-59af-4628-be73-488cfec3187d 
req-d46cb1f0-431f-490f-955b-b9c2cd9f6437 service placement] 
/usr/local/lib/python3.5/dist-packages/oslo_policy/policy.py:896: 
UserWarning: Policy placement:resource_providers:list failed scope 
check. The token used to make the request was project scoped but the 
policy requires ['system'] scope. This behavior may change in the future 
where using the intended scope is required
Aug 08 22:17:30.837800 ubuntu-xenial-inap-mtl01-0001226060 
devstack@placement-api.service[14403]:   warnings.warn(msg)
Aug 08 22:17:30.838067 ubuntu-xenial-inap-mtl01-0001226060 
devstack@placement-api.service[14403]:


Is there any way we can get rid of these?

Thanks,
-jay

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

Re: [openstack-dev] Stepping down as coordinator for the Outreachy internships

[Ghanshyam Mann]

Thanks Victoria  for such a great work and well coordinated. You have done 
remarkable work in internships program. 

-gmann 

  On Wed, 08 Aug 2018 08:47:28 +0900 Victoria Martínez de la Cruz 
 wrote  
 > Hi all,
 > I'm reaching you out to let you know that I'll be stepping down as 
 > coordinator for OpenStack next round. I had been contributing to this effort 
 > for several rounds now and I believe is a good moment for somebody else to 
 > take the lead. You all know how important is Outreachy to me and I'm 
 > grateful for all the amazing things I've done as part of the Outreachy 
 > program and all the great people I've met in the way. I plan to keep 
 > involved with the internships but leave the coordination tasks to somebody 
 > else.
 > If you are interested in becoming an Outreachy coordinator, let me know and 
 > I can share my experience and provide some guidance.
 > Thanks,
 > Victoria 
 > __
 > 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] [requirements][release][congress] FFE request to bump python-monascaclient to 1.12.1

[Eric K]

Requesting the raised minimun just for openstack/congress.
https://review.openstack.org/#/c/590021/

No re-release required; it'll just take effect in RC1.



On 8/8/18, 2:06 PM, "Matthew Thode"  wrote:

>On 18-08-08 13:14:08, Eric K wrote:
>> python-monascaclient 1.12.0 paired with osc-lib 1.11.0 seems to
>> experience a problem around Session.
>> 
>> python-monascaclient 1.12.1 fixes the issue [1]. So I'd like to bump
>> congress requirements to python-monascaclient>=1.12.1 if it is not
>> disruptive to packaging [2]. If it is disruptive, we can just note it
>> as a known issue.
>
>Which project(s) will need the new minimum?  Those projects would need
>re-releases.  Then my question then becomes if those projects need a
>raised minumum too, and for which project(s).  And so on.
>
>-- 
>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] [requirements][release][congress] FFE request to bump doc req sphinx to 1.7.3

[Eric K]

Requesting the raised minimun just for openstack/congress.
https://review.openstack.org/#/c/589995/

No re-release required; it'll just take effect in RC1.

On 8/8/18, 2:07 PM, "Matthew Thode"  wrote:

>On 18-08-08 13:20:47, Eric K wrote:
>> Lower versions of sphinx seems to experience a problem where the
>> exclude_patterns option is not in effect. I'd like to bump the
>> docs/requirements to sphinx>=1.7.3 if it is not disruptive to
>> packaging. If it is disruptive to packaging we can leave it as is.
>> 
>> Thanks!
>> 
>> https://review.openstack.org/#/c/589995/
>> 
>
>Which project(s) will need the new minimum?  Those projects would need
>re-releases.  Then my question then becomes if those projects need a
>raised minumum too, and for which project(s).  And so on.
>
>-- 
>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] [all][tc][election] Timing of the Upcoming Stein TC election

[Kendall Nelson]

Hello!

On Tue, Aug 7, 2018 at 9:39 PM Tony Breeds  wrote:

> Hello all,
> With the PTL elections behind us it's time to start looking at the
> TC election.  Our charter[1] says:
>
>   The election is held no later than 6 weeks prior to each OpenStack
>   Summit (on or before ‘S-6’ week), with elections held open for no less
>   than four business days.
>
> Assuming we have the same structure that gives us a timeline of:
>
>   Summit is at: 2018-11-13
>   Latest possible completion is at: 2018-10-02
>   Moving back to Tuesday: 2018-10-02
>   TC Election from 2018-09-25T23:45 to 2018-10-02T23:45
>   TC Campaigning from 2018-09-18T23:45 to 2018-09-25T23:45
>   TC Nominations from 2018-09-11T23:45 to 2018-09-18T23:45
>
> This puts the bulk of the nomination period during the PTG, which is
> sub-optimal as the nominations cause a distraction from the PTG but more
> so because the campaigning will coincide with travel home, and some
> community members take vacation along with the PTG.
>
> So I'd like to bring up the idea of moving the election forward a
> little so that it's actually the campaigning period that overlaps with
> the PTG:
>
>   TC Electionfrom 2018-09-18T23:45 to 2018-09-27T23:45
>   TC Campaigning from 2018-09-06T23:45 to 2018-09-18T23:45
>   TC Nominations from 2018-08-30T23:45 to 2018-09-06T23:45
>

+2!


> This gives us longer campaigning and election periods.
>
> There are some advantages to doing this:
>
>  * A panel style Q could be held formally or informally ;P
>  * There's improved scope for for incoming, outgoing and staying put TC
>members to interact in a high bandwidth way.
>  * In personi/private discussions with TC candidates/members.
>
> However it isn't without downsides:
>
>   * Election fatigue, We've just had the PTL elections and the UC
> elections are currently running.  Less break before the TC elections
> may not be a good thing.
>

Simultaneously, would be nice to get it done with.


>   * TC candidates that can't travel to the PTG could be disadvantaged
>

We also can and should post things on the ML for longer discussion as the
'debate' likely wouldn't be much longer than over lunch one day.


>   * The campaigning would all happen at the PTG and not on the mailing
> list disadvantaging community members not at the PTG.
>
> So thoughts?
>

I think this is a good plan :) Ready to +2 the config change as soon as I
see it.


>
> Yours Tony.
>
> [1] https://governance.openstack.org/tc/reference/charter.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


-Kendall (diablo_rojo)
__
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] [requirements][release][congress] FFE request to bump doc req sphinx to 1.7.3

[Matthew Thode]

On 18-08-08 13:20:47, Eric K wrote:
> Lower versions of sphinx seems to experience a problem where the
> exclude_patterns option is not in effect. I'd like to bump the
> docs/requirements to sphinx>=1.7.3 if it is not disruptive to
> packaging. If it is disruptive to packaging we can leave it as is.
> 
> Thanks!
> 
> https://review.openstack.org/#/c/589995/
> 

Which project(s) will need the new minimum?  Those projects would need
re-releases.  Then my question then becomes if those projects need a
raised minumum too, and for which project(s).  And so on.

-- 
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] [requirements][release][congress] FFE request to bump python-monascaclient to 1.12.1

[Matthew Thode]

On 18-08-08 13:14:08, Eric K wrote:
> python-monascaclient 1.12.0 paired with osc-lib 1.11.0 seems to
> experience a problem around Session.
> 
> python-monascaclient 1.12.1 fixes the issue [1]. So I'd like to bump
> congress requirements to python-monascaclient>=1.12.1 if it is not
> disruptive to packaging [2]. If it is disruptive, we can just note it
> as a known issue.

Which project(s) will need the new minimum?  Those projects would need
re-releases.  Then my question then becomes if those projects need a
raised minumum too, and for which project(s).  And so on.

-- 
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] [requirements][release][congress] FFE request to bump doc req sphinx to 1.7.3

[Eric K]

Lower versions of sphinx seems to experience a problem where the
exclude_patterns option is not in effect. I'd like to bump the
docs/requirements to sphinx>=1.7.3 if it is not disruptive to
packaging. If it is disruptive to packaging we can leave it as is.

Thanks!

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

__
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] [requirements][release][congress] FFE request to bump python-monascaclient to 1.12.1

[Eric K]

python-monascaclient 1.12.0 paired with osc-lib 1.11.0 seems to
experience a problem around Session.

python-monascaclient 1.12.1 fixes the issue [1]. So I'd like to bump
congress requirements to python-monascaclient>=1.12.1 if it is not
disruptive to packaging [2]. If it is disruptive, we can just note it
as a known issue.

Thanks!

[1] https://review.openstack.org/#/c/579139/
[2] https://review.openstack.org/#/c/590021/

__
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] [cinder][api] strict schema validation and microversioning

[Sean McGinnis]

On Wed, Aug 08, 2018 at 05:15:26PM +, Sean McGinnis wrote:
> On Tue, Aug 07, 2018 at 05:27:06PM -0500, Monty Taylor wrote:
> > On 08/07/2018 05:03 PM, Akihiro Motoki wrote:
> > >Hi Cinder and API-SIG folks,
> > >
> > >During reviewing a horizon bug [0], I noticed the behavior of Cinder API
> > >3.0 was changed.
> > >Cinder introduced more strict schema validation for creating/updating
> > >volume encryption type
> > >during Rocky and a new micro version 3.53 was introduced[1].
> > >
> > >Previously, Cinder API like 3.0 accepts unused fields in POST requests
> > >but after [1] landed unused fields are now rejected even when Cinder API
> > >3.0 is used.
> > >In my understanding on the microversioning, the existing behavior for
> > >older versions should be kept.
> > >Is it correct?
> > 
> > I agree with your assessment that 3.0 was used there - and also that I would
> > expect the api validation to only change if 3.53 microversion was used.
> > 
> 
> I filed a bug to track this:
> 
> https://bugs.launchpad.net/cinder/+bug/1786054
> 

Sorry, between lack of attention to detail (lack of coffee?) and an incorrect
link, I think I went down the wrong rabbit hole.

The change was actually introduced in [0]. I have submitted [1] to allow the
additional parameters in the volume type encryption API. This was definitely an
oversight when we allowed that one through.

Apologies for the hassle this has caused.

[0] https://review.openstack.org/#/c/561140/
[1] https://review.openstack.org/#/c/590014/

__
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 lagging behind 2 major python versions: we need a Python 3.7 gate

[Corey Bryant]

On Wed, Aug 8, 2018 at 10:29 AM, Mehdi Abaakouk  wrote:

> On Wed, Aug 08, 2018 at 08:35:20AM -0400, Corey Bryant wrote:
>
>> On Wed, Aug 8, 2018 at 3:43 AM, Thomas Goirand  wrote:
>>
>> On 08/07/2018 06:10 PM, Corey Bryant wrote:
>>> > I was concerned that there wouldn't be any
>>> > gating until Ubuntu 20.04 (April 2020)
>>> Same over here. I'm concerned that it takes another 2 years, which
>>> really, we cannot afford.
>>>
>>> > but Py3.7 is available in bionic today.
>>>
>>
> Yeah but it's the beta3 version.
>
>
Yes, that's something I mentioned before but it was snipped from the
conversation. We're going to try and get that updated.

Corey

-- 
> 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
>
__
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] Patches to speed up plan operations

[Jiri Tomasek]

Hello, thanks for bringing this up.

I am going to try to test this patch with TripleO UI tomorrow. Without
properly looking at the patch, questions I would like to get answers for
are:

How is this going to affect ways to create/update deployment plan?
Currently user is able to create deployment plan by:
- not providing any files - creating deployment plan from default files in
/usr/share/openstack-tripleo-heat-templates
- providing a tarball
- providing a local directory of files to create plan from
- providing a git repository link

These changes will have an impact on certain TripleO UI operations where
(in rare cases) we reach directly for a swift object

IIUC it seems we are deciding to consider deployment plan as a black box
packed in a tarball, which I quite like, we'll need to provide a standard
way how to provide custom files to the plan.

How is this going to affect CLI vs GUI workflow as currently CLI creates
the plan as part of the deploy command, rather than GUI starts its workflow
by selecting/creating deployment plan and whole configuration of the plan
is performed on the deployment plan. Then the deployment plan gets
deployed. We are aiming to introduce CLI commands to consolidate the
behaviour of both clients to what GUI workflow is currently.

I am going to try to find answers to these questions and identify potential
problems in next couple of days.

-- Jirka


On Tue, Aug 7, 2018 at 5:34 PM Dan Prince  wrote:

> Thanks for taking this on Ian! I'm fully on board with the effort. I
> like the consolidation and performance improvements. Storing t-h-t
> templates in Swift worked okay 3-4 years ago. Now that we have more
> templates, many of which need .j2 rendering the storage there has
> become quite a bottleneck.
>
> Additionally, since we'd be sending commands to Heat via local
> filesystem template storage we could consider using softlinks again
> within t-h-t which should help with refactoring and deprecation
> efforts.
>
> Dan
> On Wed, Aug 1, 2018 at 7:35 PM Ian Main  wrote:
> >
> >
> > Hey folks!
> >
> > So I've been working on some patches to speed up plan operations in
> TripleO.  This was originally driven by the UI needing to be able to
> perform a 'plan upload' in something less than several minutes. :)
> >
> > https://review.openstack.org/#/c/581153/
> > https://review.openstack.org/#/c/581141/
> >
> > I have a functioning set of patches, and it actually cuts over 2 minutes
> off the overcloud deployment time.
> >
> > Without patch:
> > + openstack overcloud plan create --templates
> /home/stack/tripleo-heat-templates/ overcloud
> > Creating Swift container to store the plan
> > Creating plan from template files in: /home/stack/tripleo-heat-templates/
> > Plan created.
> > real3m3.415s
> >
> > With patch:
> > + openstack overcloud plan create --templates
> /home/stack/tripleo-heat-templates/ overcloud
> > Creating Swift container to store the plan
> > Creating plan from template files in: /home/stack/tripleo-heat-templates/
> > Plan created.
> > real0m44.694s
> >
> > This is on VMs.  On real hardware it now takes something like 15-20
> seconds to do the plan upload which is much more manageable from the UI
> standpoint.
> >
> > Some things about what this patch does:
> >
> > - It makes use of process-templates.py (written for the undercloud) to
> process the jinjafied templates.  This reduces replication with the
> existing version in the code base and is very fast as it's all done on
> local disk.
> > - It stores the bulk of the templates as a tarball in swift.  Any
> individual files in swift take precedence over the contents of the tarball
> so it should be backwards compatible.  This is a great speed up as we're
> not accessing a lot of individual files in swift.
> >
> > There's still some work to do; cleaning up and fixing the unit tests,
> testing upgrades etc.  I just wanted to get some feedback on the general
> idea and hopefully some reviews and/or help - especially with the unit test
> stuff.
> >
> > Thanks everyone!
> >
> > Ian
> >
> >
> __
> > 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] [cinder][api] strict schema validation and microversioning

[Sean McGinnis]

On Tue, Aug 07, 2018 at 05:27:06PM -0500, Monty Taylor wrote:
> On 08/07/2018 05:03 PM, Akihiro Motoki wrote:
> >Hi Cinder and API-SIG folks,
> >
> >During reviewing a horizon bug [0], I noticed the behavior of Cinder API
> >3.0 was changed.
> >Cinder introduced more strict schema validation for creating/updating
> >volume encryption type
> >during Rocky and a new micro version 3.53 was introduced[1].
> >
> >Previously, Cinder API like 3.0 accepts unused fields in POST requests
> >but after [1] landed unused fields are now rejected even when Cinder API
> >3.0 is used.
> >In my understanding on the microversioning, the existing behavior for
> >older versions should be kept.
> >Is it correct?
> 
> I agree with your assessment that 3.0 was used there - and also that I would
> expect the api validation to only change if 3.53 microversion was used.
> 

I filed a bug to track this:

https://bugs.launchpad.net/cinder/+bug/1786054

But something doesn't seem right from what I've seen. I've put up a patch to
add some extra unit testing around this. I expected some of those unit tests to
fail, but everything seemed happy and working the way it is supposed to with
prior to 3.53 accepting anything and 3.53 or later rejecting extra parameters.

Since that didn't work, I tried reproducing this against a running system using
curl. With no version specified (defaulting to the base 3.0 microversion)
creation succeeded:

curl -g -i -X POST
http://192.168.1.234/volume/v3/95ae21ce92a34b3c92601f3304ea0a46/volumes -H
"Accept: "Content-Type: application/json" -H "User-Agent: python-cinderclient"
-H "X-Auth-Token: $OS_TOKEN" -d '{"volume": {"backup_id": null, "description":
null, "multiattach": false, "source_volid": null, "consistencygroup_id": null,
"snapshot_id": null, "size": 1, "name": "New", "imageRef": null,
"availability_zone": null, "volume_type": null, "metadata": {}, "project_id":
"testing", "junk": "garbage"}}'

I then tried specifying the microversion that introduces the strict schema
checking to make sure I was able to get the appropriate failure, which worked
as expected:

curl -g -i -X POST
http://192.168.1.234/volume/v3/95ae21ce92a34b3c92601f3304ea0a46/volumes -H
"Accept: "Content-Type: application/json" -H "User-Agent: python-cinderclient"
-H "X-Auth-Token: $OS_TOKEN" -d '{"volume": {"backup_id": null, "description":
null, "multiattach": false, "source_volid": null, "consistencygroup_id": null,
"snapshot_id": null, "size": 1, "name": "New-mv353", "imageRef": null,
"availability_zone": null, "volume_type": null, "metadata": {}, "project_id":
"testing", "junk": "garbage"}}' -H "OpenStack-API-Version: volume 3.53"
HTTP/1.1 400 Bad Request
...

And to test boundary conditions, I then specified the microversion just prior
to the one that enabled strict checking:

curl -g -i -X POST
http://192.168.1.234/volume/v3/95ae21ce92a34b3c92601f3304ea0a46/volumes -H "Ac
"Content-Type: application/json" -H "User-Agent: python-cinderclient" -H
"X-Auth-Token: $OS_TOKEN" -d '{"volume": {"backup_id": null, "description":
null, "multiattach": false, "source_volid": null, "consistencygroup_id": null,
"snapshot_id": null, "size": 1, "name": "New-mv352", "imageRef": null,
"availability_zone": null, "volume_type": null, "metadata": {}, "project_id":
"testing", "junk": "garbage"}}' -H "OpenStack-API-Version: volume 3.52"
HTTP/1.1 202 Accepted

In all cases except the strict checking one, the volume was created
successfully even though the junk extra parameters ("project_id": "testing",
"junk": "garbage") were provided.

So I'm missing something here. Is it possible horizon is requesting the latest
API version and not defaulting to 3.0?

Sean

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

Re: [openstack-dev] PTG Denver Horns

[Thierry Carrez]

Monty Taylor wrote:

On 08/08/2018 09:12 AM, Jeremy Stanley wrote:

Speaking of which, is it too soon to put in bids to name the Denver
summit and associated release in 2019 "OpenStack Train"? I feel like
we're all honorary railroad engineers by now.


It seems like a good opportunity to apply the Brian Waldon exception.


I'm not even sure we need to apply the Brian Waldon exception, as noisy 
trains seem to be a permanent geographic feature of Denver.


--
Thierry Carrez (ttx)

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

[openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...

[Jay S Bryant]

Team,

A reminder that we have our weekly Cinder meeting on Wednesdays at 16:00 
UTC.  I bring this up as I can no longer send the courtesy pings without 
being kicked from IRC.  So, if you wish to join the meeting please add a 
reminder to your calendar of choice.


Thank you!

Jay



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

Re: [openstack-dev] [release] FFE for python-cloudkittyclient 2.0.0

[Matthew Thode]

On 18-08-08 17:57:32, Christophe Sauthier wrote:
> 
> 
> Le 2018-08-08 17:44, Matthew Thode a écrit :
> > On 18-08-08 16:49:51, Christophe Sauthier wrote:
> > > Hello all
> > > 
> > > I'd like to ask for a FFE to release for python-cloudkittyclient
> > > 2.0.0
> > > 
> > > The review is located here :
> > > 
> > > Since it is the first time we are asking for such thing so please do
> > > not
> > > hesitate to point me if I am not doing things right.
> > 
> > Will you require a bump to the minimum version required in requirements
> > files?
> 
> We can do a bump since only the cloudkitty-dashboard depends on the client.
> 

SGTM then, ack from reqs

-- 
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] [vitrage][ptl] PTL on vacation

[Ifat Afek]

Hi all,

I'll be on vacation between 12th and 31st of August. Anna Reznikov (
anna.rezni...@nokia.com) will replace me during this time and will handle
the Vitrage release.

Thanks,
Ifat
__
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]Notification update week 30

[Matt Riedemann]

On 7/23/2018 8:58 AM, Balázs Gibizer wrote:

Versioned notification transformation
-
We have only a handfull of patches left before we can finally finish the 
multi year effort of transforming every legacy notifiaction to the 
versioned format. 3 of those patches already have a +2:

https://review.openstack.org/#/q/status:open+topic:bp/versioned-notification-transformation-rocky


Since we're past feature freeze for Rocky I had assumed this blueprint 
was going to be closed and we'd wrap up early in Stein, then start 
talking about communicating deprecation of the legacy notifications at 
the PTG.


--

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] [release] FFE for python-cloudkittyclient 2.0.0

[Christophe Sauthier]

Le 2018-08-08 17:44, Matthew Thode a écrit :

On 18-08-08 16:49:51, Christophe Sauthier wrote:

Hello all

I'd like to ask for a FFE to release for python-cloudkittyclient 
2.0.0


The review is located here :

Since it is the first time we are asking for such thing so please do 
not

hesitate to point me if I am not doing things right.


Will you require a bump to the minimum version required in 
requirements

files?


We can do a bump since only the cloudkitty-dashboard depends on the 
client.


Thanks for your help !

   Christophe


Christophe Sauthier
CEO

Objectif Libre : Au service de votre Cloud

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

www.objectif-libre.com | @objectiflibre | 
www.linkedin.com/company/objectif-libre

Recevez la Pause Cloud Et DevOps : 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] Paste unmaintained

[Chris Dent]

On Wed, 8 Aug 2018, Thomas Goirand wrote:


I'll try to investigate then. However, the way you're suggesting
mandates systemd which is probably not desirable.


"or some other supervisor"


--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] Paste unmaintained

[Thomas Goirand]

On 08/08/2018 04:38 PM, Chris Dent wrote:
> On Wed, 8 Aug 2018, Thomas Goirand wrote:
> 
>> I'd be more than happy to have a better logging without the need of
>> paste/pastescript, but so far, that's the only way I found that worked
>> with uwsgi. Do you know any other way?
> 
> Yes, use systemd or some other supervisor which is responsible for
> catching stderr. That's why I pointed to devstack and my container
> thing. Not because I think devstack is glorious or anything, but
> because the logging works and presumably something can be learned
> from that.
> 
> Apparently what you're doing in the debian packages doesn't work
> (without logging middleware), which isn't surprising because that's
> exactly how uwsgi and WSGI is supposed to work.
> 
> What I've been trying to suggest throughout this subthread is that
> it sounds like however things are being packaged in debian is not
> right, and that something needs to be changed. Also that your bold
> assertion that uwsgi doesn't work without paste is only true in the
> narrow way in which you are using it (which is the wrong way to use
> it).

Thanks.

I'll try to investigate then. However, the way you're suggesting
mandates systemd which is probably not desirable.

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] [release] FFE for python-cloudkittyclient 2.0.0

[Matthew Thode]

On 18-08-08 16:49:51, Christophe Sauthier wrote:
> Hello all
> 
> I'd like to ask for a FFE to release for python-cloudkittyclient 2.0.0
> 
> The review is located here :
> 
> Since it is the first time we are asking for such thing so please do not
> hesitate to point me if I am not doing things right.

Will you require a bump to the minimum version required in requirements
files?

-- 
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] 答复: Re: [python-senlinclient][release][requirements]FFE for python-senlinclient 1.8.0

[Matthew Thode]

On 18-08-08 19:05:50, liu.xuefe...@zte.com.cn wrote:
> Yes,  just need upper-constraints raised for this.
> 
> On Tue, Aug 07, 2018 at 03:25:39PM -0500, Sean McGinnis wrote:
> > Added requirements tag to the subject since this is a requirements FFE.
> > 
> > On Tue, Aug 07, 2018 at 11:44:04PM +0800, liu.xuefe...@zte.com.cn wrote:
> > > hi, all
> > > 
> > > 
> > > I'd like to request an FFE to release 1.8.0(stable/rocky)
> > >  for python-senlinclient.
> > > 
> > > The CURRENT_API_VERSION has been changed to "1.10", we need this release.
> > > 
> 
> XueFeng, do you just need upper-constraints raised for this, or also the
> minimum version? From that last sentence, I'm assuming you need to ensure only
> 1.8.0 is used for Rocky deployments.
> 

OK, if it's JUST upper-constraints that needs to change then FFE
approved by requirements.

-- 
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] PTG Denver Horns

[Jay S Bryant]

On 8/8/2018 9:12 AM, Jeremy Stanley wrote:

On 2018-08-08 06:51:27 -0500 (-0500), David Medberry wrote:

So basically, we have added "sl" to osc. Duly noted.

(FWIW, I frequently use "sl" as a demo of how "live" a VM is during live
migration. The train "stutters" a bit during the cutover.)

Now I can base it on PTG design work in a backronym fashion.

[...]

Speaking of which, is it too soon to put in bids to name the Denver
summit and associated release in 2019 "OpenStack Train"? I feel like
we're all honorary railroad engineers by now.


+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 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] [Cyborg] Agent - Conductor update

[Nadathur, Sundar]

Hi Zhenghao,

On 8/8/2018 4:10 AM, Zhenghao ZH21 Wang wrote:

Hi Sundar,
All look good to me. And I agreed with the new solution as your suggestion. But 
I still confused why we will lost some device info if we do diff on agent?
Could u give me an example to explain how to lost and what we will lost?


To do the diff, the agent would need the previous configuration of 
devices on the host. If it keeps that previous config in its process 
memory, it will lose it if it dies and restarts for any reason. So, it 
should persist it. The ideal place to persist that is the Cyborg db. So, 
let us say the agent writes the config to the db each time via the 
conductor.


However, consider the scenario where the agent pushes an update to the 
conductor, and restarts before the conductor has written it to the db. 
This can result in a race condition. If we don't address that properly, 
the agent may get the copy in the db and not the latest update. That is 
the loss we were talking about.


To prevent that race, the restarted agent should ask the conductor to 
get the latest, and the conductor must be smart enough to 'synchronize' 
with the previous unfinished update. This seems like unnecessary 
complication.


I think this is what you are asking about. If not, please let me know 
what you meant.



Best regards
Zhenghao Wang
Cloud Researcher

Email: wangz...@lenovo.com
Tel: (+86) 18519550096
Enterprise & Cloud Research Lab, Lenovo Research
No.6 Shangdi West Road, Haidian District, Beijing

Regards,
Sundar

__
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] [release] FFE for python-cloudkittyclient 2.0.0

[Christophe Sauthier]

Hello all

I'd like to ask for a FFE to release for python-cloudkittyclient 2.0.0

The review is located here :

Since it is the first time we are asking for such thing so please do 
not hesitate to point me if I am not doing things right.


Cheers

  Christophe


Christophe Sauthier
CEO

Objectif Libre : Au service de votre Cloud

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

www.objectif-libre.com | @objectiflibre | 
www.linkedin.com/company/objectif-libre

Recevez la Pause Cloud Et DevOps : 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] Stepping down as coordinator for the Outreachy internships

[Amy Marrich]

Victoria,

Thank you for everything you've down with the Outreachy program!

Amy (spotz)

On Tue, Aug 7, 2018 at 6:47 PM, Victoria Martínez de la Cruz <
victo...@vmartinezdelacruz.com> wrote:

> Hi all,
>
> I'm reaching you out to let you know that I'll be stepping down as
> coordinator for OpenStack next round. I had been contributing to this
> effort for several rounds now and I believe is a good moment for somebody
> else to take the lead. You all know how important is Outreachy to me and
> I'm grateful for all the amazing things I've done as part of the Outreachy
> program and all the great people I've met in the way. I plan to keep
> involved with the internships but leave the coordination tasks to somebody
> else.
>
> If you are interested in becoming an Outreachy coordinator, let me know
> and I can share my experience and provide some guidance.
>
> Thanks,
>
> Victoria
>
> __
> 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] Paste unmaintained

[Chris Dent]

On Wed, 8 Aug 2018, Thomas Goirand wrote:


I'd be more than happy to have a better logging without the need of
paste/pastescript, but so far, that's the only way I found that worked
with uwsgi. Do you know any other way?


Yes, use systemd or some other supervisor which is responsible for
catching stderr. That's why I pointed to devstack and my container
thing. Not because I think devstack is glorious or anything, but
because the logging works and presumably something can be learned
from that.

Apparently what you're doing in the debian packages doesn't work
(without logging middleware), which isn't surprising because that's
exactly how uwsgi and WSGI is supposed to work.

What I've been trying to suggest throughout this subthread is that
it sounds like however things are being packaged in debian is not
right, and that something needs to be changed. Also that your bold
assertion that uwsgi doesn't work without paste is only true in the
narrow way in which you are using it (which is the wrong way to use
it).

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] storlets 2.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

A new release candidate for storlets for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/storlets/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

http://git.openstack.org/cgit/openstack/storlets/log/?h=stable/rocky

Release notes for storlets can be found at:

http://docs.openstack.org/releasenotes/storlets/




__
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] [cyborg]Team Weekly Meeting 2018.08.08

[Jeremy Stanley]

On 2018-08-08 16:45:22 +0800 (+0800), Zhipeng Huang wrote:
> We are rushing towards the end of Rocky cycle and let's use the meeting to
> sync up with any important features still on the fly.
> 
> starting UTC1400 at #openstack-cyborg, as usual

Please consider adding your meeting to the IRC meetings schedule at
http://eavesdrop.openstack.org/ (the first sentence in the section
contains instructions for doing so), that way people in the
community can find out when it is held without having to rely solely
on announcements. Thanks!
-- 
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] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

[Mehdi Abaakouk]

On Wed, Aug 08, 2018 at 08:35:20AM -0400, Corey Bryant wrote:

On Wed, Aug 8, 2018 at 3:43 AM, Thomas Goirand  wrote:


On 08/07/2018 06:10 PM, Corey Bryant wrote:
> I was concerned that there wouldn't be any
> gating until Ubuntu 20.04 (April 2020)
Same over here. I'm concerned that it takes another 2 years, which
really, we cannot afford.

> but Py3.7 is available in bionic today.


Yeah but it's the beta3 version.

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

Re: [openstack-dev] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

[Mehdi Abaakouk]

On Wed, Aug 08, 2018 at 09:35:04AM -0400, Doug Hellmann wrote:

Excerpts from Andrey Kurilin's message of 2018-08-08 15:25:01 +0300:

Thanks Thomas for pointing to the issue, I checked it locally and here is
an update for openstack/rally (rally framework without in-tree OpenStack
plugins) project:

- added unittest job with py37 env


It would be really useful if you could help set up a job definition in
openstack-zuul-jobs like we have for openstack-tox-py36 [1], so that other
projects can easily add the job, too. Do you have time to do that?


I have already done this kind of stuff for Telemetry project. And our
project already gate on py37. The only restriction is that we have to
use a fedora-28 instance with the python-3.7 package installed manually
(via bindep.txt). Ubuntu 18.04 LTS only a beta version of python 3.7 in
universe repo.

So I'm guessing we have to wait next Ubuntu LTS to add this job
everywhere.

https://github.com/openstack/ceilometer/blob/master/.zuul.yaml#L12
https://github.com/openstack/ceilometer/blob/master/bindep.txt#L7

Cheers,

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

Re: [openstack-dev] Stepping down as coordinator for the Outreachy internships

[Jeremy Stanley]

On 2018-08-07 20:47:28 (-0300), Victoria Martínez de la Cruz wrote:
> I'm reaching you out to let you know that I'll be stepping down as
> coordinator for OpenStack next round.
[...]

You've done a great job, and mentoring a new coordinator is just
another great example of that; thanks for all you've done and all
you have yet to do, it's important!
-- 
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] ?==?utf-8?q? PTG Denver Horns

[jean-philippe]

On Wednesday, August 08, 2018 16:12 CEST, Jeremy Stanley  
wrote: 
 
> On 2018-08-08 06:51:27 -0500 (-0500), David Medberry wrote:
> > So basically, we have added "sl" to osc. Duly noted.
> > 
> > (FWIW, I frequently use "sl" as a demo of how "live" a VM is during live
> > migration. The train "stutters" a bit during the cutover.)
> > 
> > Now I can base it on PTG design work in a backronym fashion.
> [...]
> 
> Speaking of which, is it too soon to put in bids to name the Denver
> summit and associated release in 2019 "OpenStack Train"? I feel like
> we're all honorary railroad engineers by now.
> -- 
> Jeremy Stanley
 
 +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] PTG Denver Horns

[Monty Taylor]

On 08/08/2018 09:12 AM, Jeremy Stanley wrote:

On 2018-08-08 06:51:27 -0500 (-0500), David Medberry wrote:

So basically, we have added "sl" to osc. Duly noted.

(FWIW, I frequently use "sl" as a demo of how "live" a VM is during live
migration. The train "stutters" a bit during the cutover.)

Now I can base it on PTG design work in a backronym fashion.

[...]

Speaking of which, is it too soon to put in bids to name the Denver
summit and associated release in 2019 "OpenStack Train"? I feel like
we're all honorary railroad engineers by now.


It seems like a good opportunity to apply the Brian Waldon exception.

__
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] Paste unmaintained

[Thomas Goirand]

On 08/08/2018 10:43 AM, Chris Dent wrote:
> On Wed, 8 Aug 2018, Thomas Goirand wrote:
> 
>> If you don't configure uwsgi to do any special logging, then then only
>> thing you'll see in the log file is client requests, without any kind of
>> logging from the wsgi application. To have proper logging, one needs to
>> add, in the uwsgi config file:
>>
>> paste-logger = true
>>
>> If you do that, then you need the python3-pastescript installed, which
>> itself depends on the python3-paste package.
>>
>> Really, I don't see how an operator could run without the paste-logger
>> option activated. Without it, you see nothing in the logs.
> 
> I'm pretty sure your statements here are not true. In the uwsgi
> configs for services in devstack, paste-logger is not used.

I have never mentioned devstack ! :)

> Can you please point me to where you are seeing these problems?

In the Debian packages, if I don't do paste-logger = true, I will not
see any debug output.

> Clearly something is confused somewhere. Is the difference in our
> experiences that both of the situations I describe above are happy
> with logging being on stderr and you're talking about being able to
> config logging to files, within the application itself?

If there's no paste-logger, what the application prints on stderr
doesn't appear in the log file that uwsgi logs into. That's precisely
what paste-logger fixes.

> If that's
> the case then my response would b: don't do that. Let systemd, or
> your container, or apache2, or whatever process/service orchestration
> system you have going manage that. That's what they are there for.

I'd be more than happy to have a better logging without the need of
paste/pastescript, but so far, that's the only way I found that worked
with uwsgi. Do you know any other way?

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] PTG Denver Horns

[Jeremy Stanley]

On 2018-08-08 06:51:27 -0500 (-0500), David Medberry wrote:
> So basically, we have added "sl" to osc. Duly noted.
> 
> (FWIW, I frequently use "sl" as a demo of how "live" a VM is during live
> migration. The train "stutters" a bit during the cutover.)
> 
> Now I can base it on PTG design work in a backronym fashion.
[...]

Speaking of which, is it too soon to put in bids to name the Denver
summit and associated release in 2019 "OpenStack Train"? I feel like
we're all honorary railroad engineers by now.
-- 
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] Stepping down as coordinator for the Outreachy internships

[Jay Pipes]

On 08/08/2018 09:32 AM, Doug Hellmann wrote:

Excerpts from Victoria Martínez de la Cruz's message of 2018-08-07 20:47:28 
-0300:

Hi all,

I'm reaching you out to let you know that I'll be stepping down as
coordinator for OpenStack next round. I had been contributing to this
effort for several rounds now and I believe is a good moment for somebody
else to take the lead. You all know how important is Outreachy to me and
I'm grateful for all the amazing things I've done as part of the Outreachy
program and all the great people I've met in the way. I plan to keep
involved with the internships but leave the coordination tasks to somebody
else.

If you are interested in becoming an Outreachy coordinator, let me know and
I can share my experience and provide some guidance.

Thanks,

Victoria


Thank you, Victoria. Mentoring new developers is an important
responsibility, and your patient service in working with the Outreachy
program has set a good example.


Big +1.

-jay

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

Re: [openstack-dev] [all][elections] Project Team Lead Election Conclusion and Results

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2018-08-08 10:20:15 +1000:
> Thank you to the electorate, to all those who voted and to all
> candidates who put their name forward for Project Team Lead (PTL) in
> this election. A healthy, open process breeds trust in our decision
> making capability thank you to all those who make this process possible.
> 
> Now for the results of the PTL election process, please join me in
> extending congratulations to the following PTLs:
> 
>  * Adjutant  : Adrian Turjak   
>  * Barbican  : Ade Lee 
>  * Blazar: Pierre Riteau   
>  * Chef OpenStack: Samuel Cassiba  
>  * Cinder: Jay Bryant  
>  * Cloudkitty: Luka Peschke
>  * Congress  : Eric Kao
>  * Cyborg: Li Liu  
>  * Designate : Graham Hayes
>  * Documentation : Petr Kovar  
>  * Dragonflow: [1]
>  * Ec2 Api   : Andrey Pavlov   
>  * Freezer   : [1]
>  * Glance: Erno Kuvaja 
>  * Heat  : Rico Lin
>  * Horizon   : Ivan Kolodyazhny
>  * I18n  : Frank Kloeker   
>  * Infrastructure: Clark Boylan
>  * Ironic: Julia Kreger
>  * Karbor: Pengju Jiao 
>  * Keystone  : Lance Bragstad  
>  * Kolla : Eduardo Gonzalez Gutierrez  
>  * Kuryr : Daniel Mellado  
>  * Loci  : [1]
>  * Magnum: Spyros Trigazis 
>  * Manila: Thomas Barron   
>  * Masakari  : Sampath Priyankara  
>  * Mistral   : Dougal Matthews 
>  * Monasca   : Witek Bedyk 
>  * Murano: Rong Zhu
>  * Neutron   : Miguel Lavalle  
>  * Nova  : Melanie Witt
>  * Octavia   : Michael Johnson 
>  * OpenStackAnsible  : Mohammed Naser  
>  * OpenStackClient   : Dean Troyer 
>  * OpenStackSDK  : Monty Taylor
>  * OpenStack Charms  : Frode Nordahl   
>  * OpenStack Helm: Pete Birley 
>  * Oslo  : Ben Nemec   
>  * Packaging Rpm : [1]
>  * PowerVMStackers   : Matthew Edmonds 
>  * Puppet OpenStack  : Tobias Urdin
>  * Qinling   : Lingxian Kong   
>  * Quality Assurance : Ghanshyam Mann  
>  * Rally : Andrey Kurilin  
>  * RefStack  : [1]
>  * Release Management: Sean McGinnis   
>  * Requirements  : Matthew Thode   
>  * Sahara: Telles Nobrega  
>  * Searchlight   : [1]
>  * Security  : [1]
>  * Senlin: Duc Truong  
>  * Solum : Rong Zhu
>  * Storlets  : Kota Tsuyuzaki  
>  * Swift : John Dickinson  
>  * Tacker: dharmendra kushwaha 
>  * Telemetry : Julien Danjou   
>  * Tricircle : baisen song 
>  * Tripleo   : Juan Osorio Robles  
>  * Trove : [1]
>  * Vitrage   : Ifat Afek   
>  * Watcher   : Alexander Chadin
>  * Winstackers  

Re: [openstack-dev] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

[Doug Hellmann]

Excerpts from Andrey Kurilin's message of 2018-08-08 15:25:01 +0300:
> Thanks Thomas for pointing to the issue, I checked it locally and here is
> an update for openstack/rally (rally framework without in-tree OpenStack
> plugins) project:
> 
> - added unittest job with py37 env

It would be really useful if you could help set up a job definition in
openstack-zuul-jobs like we have for openstack-tox-py36 [1], so that other
projects can easily add the job, too. Do you have time to do that?

Doug

[1] 
http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/jobs.yaml#n354

__
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] Stepping down as coordinator for the Outreachy internships

[Doug Hellmann]

Excerpts from Victoria Martínez de la Cruz's message of 2018-08-07 20:47:28 
-0300:
> Hi all,
> 
> I'm reaching you out to let you know that I'll be stepping down as
> coordinator for OpenStack next round. I had been contributing to this
> effort for several rounds now and I believe is a good moment for somebody
> else to take the lead. You all know how important is Outreachy to me and
> I'm grateful for all the amazing things I've done as part of the Outreachy
> program and all the great people I've met in the way. I plan to keep
> involved with the internships but leave the coordination tasks to somebody
> else.
> 
> If you are interested in becoming an Outreachy coordinator, let me know and
> I can share my experience and provide some guidance.
> 
> Thanks,
> 
> Victoria

Thank you, Victoria. Mentoring new developers is an important
responsibility, and your patient service in working with the Outreachy
program has set a good example.

Doug

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

Re: [openstack-dev] [oslo] proposing Moisés Guimarães for oslo.config core

[Ken Giusti]

On Wed, Aug 8, 2018 at 9:19 AM Doug Hellmann  wrote:
>
> Excerpts from Doug Hellmann's message of 2018-08-01 09:27:09 -0400:
> > Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
> > during the Rocky cycle to add driver support. Based on that work,
> > and a discussion we have had since then about general cleanup needed
> > in oslo.config, I think he would make a good addition to the
> > oslo.config review team.
> >
> > Please indicate your approval or concerns with +1/-1.
> >
> > Doug
>
> Normally I would have added moguimar to the oslo-config-core team
> today, after a week's wait. Funny story, though. There is no
> oslo-config-core team.
>
> oslo.config is one of a few of our libraries that we never set up with a
> separate review team. It is managed by oslo-core. We could set up a new
> review team for that library, but after giving it some thought I
> realized that *most* of the libraries are fairly stable, our team is
> pretty small, and Moisés is a good guy so maybe we don't need to worry
> about that.
>
> I spoke with Moisés, and he agreed to be part of the larger core team.
> He pointed out that the next phase of the driver work is going to happen
> in castellan, so it would be useful to have another reviewer there. And
> I'm sure we can trust him to be careful with reviews in other repos
> until he learns his way around.
>
> So, I would like to amend my original proposal and suggest that we add
> Moisés to the oslo-core team.
>
> Please indicate support with +1 or present any concerns you have. I
> apologize for the confusion on my part.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

+1

-- 
Ken Giusti  (kgiu...@gmail.com)

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

Re: [openstack-dev] [oslo] proposing Moisés Guimarães for oslo.config core

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-08-01 09:27:09 -0400:
> Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
> during the Rocky cycle to add driver support. Based on that work,
> and a discussion we have had since then about general cleanup needed
> in oslo.config, I think he would make a good addition to the
> oslo.config review team.
> 
> Please indicate your approval or concerns with +1/-1.
> 
> Doug

Normally I would have added moguimar to the oslo-config-core team
today, after a week's wait. Funny story, though. There is no
oslo-config-core team.

oslo.config is one of a few of our libraries that we never set up with a
separate review team. It is managed by oslo-core. We could set up a new
review team for that library, but after giving it some thought I
realized that *most* of the libraries are fairly stable, our team is
pretty small, and Moisés is a good guy so maybe we don't need to worry
about that.

I spoke with Moisés, and he agreed to be part of the larger core team.
He pointed out that the next phase of the driver work is going to happen
in castellan, so it would be useful to have another reviewer there. And
I'm sure we can trust him to be careful with reviews in other repos
until he learns his way around.

So, I would like to amend my original proposal and suggest that we add
Moisés to the oslo-core team.

Please indicate support with +1 or present any concerns you have. I
apologize for the confusion on my part.

Doug

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

Re: [openstack-dev] Stepping down as coordinator for the Outreachy internships

[Mahati C]

Thank you Victoria for the initiative and the effort all these years!

On a related note, I will continue to coordinate OpenStack Outreachy for
the next round and if anyone else would like to join the effort, please
feel free to contact me or Victoria.

Best,
Mahati

On Wed, Aug 8, 2018 at 5:17 AM, Victoria Martínez de la Cruz <
victo...@vmartinezdelacruz.com> wrote:

> Hi all,
>
> I'm reaching you out to let you know that I'll be stepping down as
> coordinator for OpenStack next round. I had been contributing to this
> effort for several rounds now and I believe is a good moment for somebody
> else to take the lead. You all know how important is Outreachy to me and
> I'm grateful for all the amazing things I've done as part of the Outreachy
> program and all the great people I've met in the way. I plan to keep
> involved with the internships but leave the coordination tasks to somebody
> else.
>
> If you are interested in becoming an Outreachy coordinator, let me know
> and I can share my experience and provide some guidance.
>
> Thanks,
>
> Victoria
>
> __
> 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] Stepping down as coordinator for the Outreachy internships

[Telles Nobrega]

Thanks Victoria, you did a great job!!! Thanks for the effort

On Wed, Aug 8, 2018 at 9:44 AM Emilien Macchi  wrote:

> Thanks Victoria for all your efforts, highly recognized!
>
> ---
> Emilien Macchi
>
> On Tue, Aug 7, 2018, 7:48 PM Victoria Martínez de la Cruz, <
> victo...@vmartinezdelacruz.com> wrote:
>
>> Hi all,
>>
>> I'm reaching you out to let you know that I'll be stepping down as
>> coordinator for OpenStack next round. I had been contributing to this
>> effort for several rounds now and I believe is a good moment for somebody
>> else to take the lead. You all know how important is Outreachy to me and
>> I'm grateful for all the amazing things I've done as part of the Outreachy
>> program and all the great people I've met in the way. I plan to keep
>> involved with the internships but leave the coordination tasks to somebody
>> else.
>>
>> If you are interested in becoming an Outreachy coordinator, let me know
>> and I can share my experience and provide some guidance.
>>
>> Thanks,
>>
>> Victoria
>> __
>> 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
>
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat Brasil  

Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
 Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
pelo Great Place to Work.
__
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] Dropping core reviewer

[Paul Bourke]

+1. Will always have good memories of when Steve was getting the project 
off the ground. Thanks Steve for doing a great job of building the 
community around Kolla, and for all your help in general!


Best of luck,
-Paul

On 08/08/18 12:23, Eduardo Gonzalez wrote:

Steve,

Is sad to see you leaving kolla core team, hope to still see you around 
IRC and Summit/PTGs.


I truly appreciate your leadership, guidance and commitment to make 
kolla the great project it is now.


Best luck on your new projects and board of directors.

Regards





2018-08-07 16:28 GMT+02:00 Steven Dake (stdake) >:


Kollians,


Many of you that know me well know my feelings towards participating
as a core reviewer in a project.  Folks with the ability to +2/+W
gerrit changes can sometimes unintentionally harm a codebase if they
are not consistently reviewing and maintaining codebase context.  I
also believe in leading an exception-free life, and I'm no exception
to my own rules.  As I am not reviewing Kolla actively given my
OpenStack individually elected board of directors service and other
responsibilities, I am dropping core reviewer ability for the Kolla
repositories.


I want to take a moment to thank the thousands of people that have
contributed and shaped Kolla into the modern deployment system for
OpenStack that it is today.  I personally find Kolla to be my finest
body of work as a leader.  Kolla would not have been possible
without the involvement of the OpenStack global community working
together to resolve the operational pain points of OpenStack.  Thank
you for your contributions.


Finally, quoting Thierry [1] from our initial application to
OpenStack, " ... Long live Kolla!"


Cheers!

-steve


[1] https://review.openstack.org/#/c/206789/






__
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] Stepping down as coordinator for the Outreachy internships

[Emilien Macchi]

Thanks Victoria for all your efforts, highly recognized!

---
Emilien Macchi

On Tue, Aug 7, 2018, 7:48 PM Victoria Martínez de la Cruz, <
victo...@vmartinezdelacruz.com> wrote:

> Hi all,
>
> I'm reaching you out to let you know that I'll be stepping down as
> coordinator for OpenStack next round. I had been contributing to this
> effort for several rounds now and I believe is a good moment for somebody
> else to take the lead. You all know how important is Outreachy to me and
> I'm grateful for all the amazing things I've done as part of the Outreachy
> program and all the great people I've met in the way. I plan to keep
> involved with the internships but leave the coordination tasks to somebody
> else.
>
> If you are interested in becoming an Outreachy coordinator, let me know
> and I can share my experience and provide some guidance.
>
> Thanks,
>
> Victoria
> __
> 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] Stepping down as coordinator for the Outreachy internships

[Emilien Macchi]

---
Emilien Macchi

On Wed, Aug 8, 2018, 5:14 AM Thierry Carrez,  wrote:

> Victoria Martínez de la Cruz wrote:
> > I'm reaching you out to let you know that I'll be stepping down as
> > coordinator for OpenStack next round. I had been contributing to this
> > effort for several rounds now and I believe is a good moment for
> > somebody else to take the lead. You all know how important is Outreachy
> > to me and I'm grateful for all the amazing things I've done as part of
> > the Outreachy program and all the great people I've met in the way. I
> > plan to keep involved with the internships but leave the coordination
> > tasks to somebody else.
>
> Thanks for helping with this effort for all this time !
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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 lagging behind 2 major python versions: we need a Python 3.7 gate

[Corey Bryant]

On Wed, Aug 8, 2018 at 3:43 AM, Thomas Goirand  wrote:

> On 08/07/2018 06:10 PM, Corey Bryant wrote:
> > I was concerned that there wouldn't be any
> > gating until Ubuntu 20.04 (April 2020)
> Same over here. I'm concerned that it takes another 2 years, which
> really, we cannot afford.
>
> > but Py3.7 is available in bionic today.
>
> Is Bionic going to be released with Py3.7? In Debconf18 in Taiwan, Doko
> didn't seem completely sure about it.
>
>
Bionic was released with py3.7 in April 2018. Py3.6 is the default for
Bionic but Py3.7 is available.

https://launchpad.net/ubuntu/+source/python3.7

Corey

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
>
__
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 lagging behind 2 major python versions: we need a Python 3.7 gate

[Andrey Kurilin]

Thanks Thomas for pointing to the issue, I checked it locally and here is
an update for openstack/rally (rally framework without in-tree OpenStack
plugins) project:

- added unittest job with py37 env
- fixed all issues
- released a new version (1.1.0)

As for the openstack/rally-openstack (rally plugins for OpenStack
platform), I'm planning to do the same this week.

пн, 6 авг. 2018 г. в 20:11, Thomas Goirand :

> On 08/02/2018 10:43 AM, Andrey Kurilin wrote:
> > There's also some "raise StopIteration" issues in:
> > - ceilometer
> > - cinder
> > - designate
> > - glance
> > - glare
> > - heat
> > - karbor
> > - manila
> > - murano
> > - networking-ovn
> > - neutron-vpnaas
> > - nova
> > - rally
> >
> >
> > Can you provide any traceback or steps to reproduce the issue for Rally
> > project ?
>
> I'm not sure there's any. The only thing I know is that it has stop
> StopIteration stuff, but I'm not sure if they are part of generators, in
> which case they should simply be replaced by "return" if you want it to
> be py 3.7 compatible.
>
> I didn't have time to investigate these, but at least Glance was
> affected, and a patch was sent (as well as an async patch). None of them
> has been merged yet:
>
> https://review.openstack.org/#/c/586050/
> https://review.openstack.org/#/c/586716/
>
> That'd be ok if at least there was some reviews. It looks like nobody
> cares but Debian & Ubuntu people... :(
>
> 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
>


-- 
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] [cinder][api] strict schema validation and microversioning

[Sean McGinnis]

>  > > 
>  > > Previously, Cinder API like 3.0 accepts unused fields in POST requests
>  > > but after [1] landed unused fields are now rejected even when Cinder API 
>  > > 3.0 is used.
>  > > In my understanding on the microversioning, the existing behavior for 
>  > > older versions should be kept.
>  > > Is it correct?
>  > 
>  > I agree with your assessment that 3.0 was used there - and also that I 
>  > would expect the api validation to only change if 3.53 microversion was 
>  > used.
> 
> +1. As you know, neutron also implemented strict validation in Rocky but with 
> discovery via config option and extensions mechanism. Same way Cinder should 
> make it with backward compatible way till 3.53 version. 
> 

I agree. I _thought_ that was the way it was implemented, but apparently
something was missed.

I will try to look at this soon and see what would need to be changed to get
this behaving correctly. Unless someone else has the time and can beat me to
it, which would be very much 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] PTG Denver Horns

[David Medberry]

So basically, we have added "sl" to osc. Duly noted.

(FWIW, I frequently use "sl" as a demo of how "live" a VM is during live
migration. The train "stutters" a bit during the cutover.)

Now I can base it on PTG design work in a backronym fashion.

On Wed, Aug 8, 2018 at 5:30 AM, Colleen Murphy  wrote:

> On Wed, Aug 8, 2018, at 12:18 PM, Adam Spiers wrote:
> > Matthew Thode  wrote:
> > >On 18-08-07 23:18:26, David Medberry wrote:
> > >> Requests have finally been made (today, August 7, 2018) to end the
> horns on
> > >> the train from Denver to Denver International airport (within the city
> > >> limits of Denver.) Prior approval had been given to remove the
> FLAGGERS
> > >> that were stationed at each crossing intersection.
> > >>
> > >> Of particular note (at the bottom of the article):
> > >>
> > >> There’s no estimate for how long it could take the FRA to approve
> quiet
> > >> zones.
> > >>
> > >> ref:
> > >> https://www.9news.com/article/news/local/next/denver-
> officially-asks-fra-for-permission-to-quiet-a-line-horns/73-581499094
> > >>
> > >> I'd recommend bringing your sleeping aids, ear plugs, etc, just in
> case not
> > >> approved by next month's PTG. (The Renaissance is within Denver
> proper as
> > >> near as I can tell so that nearby intersection should be covered by
> this
> > >> ruling/decision if and when it comes down.)
> > >
> > >Thanks for the update, if you are up to it, keeping us informed on this
> > >would be nice, if only for the hilarity.
> >
> > Thanks indeed for the warning.
> >
> > If the approval doesn't go through, we may need to resume the design
> > work started last year; see lines 187 onwards of
> >
> > https://etherpad.openstack.org/p/queens-PTG-feedback
>
> Luckily the client work for this is already started:
> https://github.com/dtroyer/osc-choochoo
>
> __
> 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] Dropping core reviewer

[Eduardo Gonzalez]

Steve,

Is sad to see you leaving kolla core team, hope to still see you around IRC
and Summit/PTGs.

I truly appreciate your leadership, guidance and commitment to make kolla
the great project it is now.

Best luck on your new projects and board of directors.

Regards





2018-08-07 16:28 GMT+02:00 Steven Dake (stdake) :

> Kollians,
>
>
> Many of you that know me well know my feelings towards participating as a
> core reviewer in a project.  Folks with the ability to +2/+W gerrit changes
> can sometimes unintentionally harm a codebase if they are not consistently
> reviewing and maintaining codebase context.  I also believe in leading an
> exception-free life, and I'm no exception to my own rules.  As I am not
> reviewing Kolla actively given my OpenStack individually elected board of
> directors service and other responsibilities, I am dropping core reviewer
> ability for the Kolla repositories.
>
>
> I want to take a moment to thank the thousands of people that have
> contributed and shaped Kolla into the modern deployment system for
> OpenStack that it is today.  I personally find Kolla to be my finest body
> of work as a leader.  Kolla would not have been possible without the
> involvement of the OpenStack global community working together to resolve
> the operational pain points of OpenStack.  Thank you for your contributions.
>
>
> Finally, quoting Thierry [1] from our initial application to OpenStack,
> " ... Long live Kolla!"
>
>
> Cheers!
>
> -steve
>
>
> [1] https://review.openstack.org/#/c/206789/
>
>
>
>
>
> __
> 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] 答复: Re: [python-senlinclient][release][requirements]FFE for python-senlinclient 1.8.0

[liu.xuefeng1]

Hi, Sean






Yes,  just need upper-constraints raised for this.






Thanks


XueFeng











原始邮件



发件人：SeanMcGinnis 
收件人：OpenStack Development Mailing List (not for usage questions) 

日 期 ：2018年08月08日 04:30
主 题 ：Re: [openstack-dev] [python-senlinclient][release][requirements]FFE for 
python-senlinclient 1.8.0


On Tue, Aug 07, 2018 at 03:25:39PM -0500, Sean McGinnis wrote:
> Added requirements tag to the subject since this is a requirements FFE.
> 
> On Tue, Aug 07, 2018 at 11:44:04PM +0800, liu.xuefe...@zte.com.cn wrote:
> > hi, all
> > 
> > 
> > I'd like to request an FFE to release 1.8.0(stable/rocky)
> >  for python-senlinclient.
> > 
> > The CURRENT_API_VERSION has been changed to "1.10", we need this release.
> > 

XueFeng, do you just need upper-constraints raised for this, or also the
minimum version? From that last sentence, I'm assuming you need to ensure only
1.8.0 is used for Rocky deployments.


__
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] [watcher] Stein etherpad

[Чадин Александр Сергеевич]

Greetings Watcher team,

I’ve created etherpad page[1] where we can discuss long-term topics,
blueprints for Stein release, comments to last release and whatever you want
about Watcher. I’ll fill it with blueprints since next week (I’m still on 
vacation till the EOW).
Come and share your feedback!

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


Best Regards,

Alex

__
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] PTG Denver Horns

[Colleen Murphy]

On Wed, Aug 8, 2018, at 12:18 PM, Adam Spiers wrote:
> Matthew Thode  wrote:
> >On 18-08-07 23:18:26, David Medberry wrote:
> >> Requests have finally been made (today, August 7, 2018) to end the horns on
> >> the train from Denver to Denver International airport (within the city
> >> limits of Denver.) Prior approval had been given to remove the FLAGGERS
> >> that were stationed at each crossing intersection.
> >>
> >> Of particular note (at the bottom of the article):
> >>
> >> There’s no estimate for how long it could take the FRA to approve quiet
> >> zones.
> >>
> >> ref:
> >> https://www.9news.com/article/news/local/next/denver-officially-asks-fra-for-permission-to-quiet-a-line-horns/73-581499094
> >>
> >> I'd recommend bringing your sleeping aids, ear plugs, etc, just in case not
> >> approved by next month's PTG. (The Renaissance is within Denver proper as
> >> near as I can tell so that nearby intersection should be covered by this
> >> ruling/decision if and when it comes down.)
> >
> >Thanks for the update, if you are up to it, keeping us informed on this
> >would be nice, if only for the hilarity.
> 
> Thanks indeed for the warning.
> 
> If the approval doesn't go through, we may need to resume the design
> work started last year; see lines 187 onwards of
> 
> https://etherpad.openstack.org/p/queens-PTG-feedback

Luckily the client work for this is already started: 
https://github.com/dtroyer/osc-choochoo

__
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] PTG Denver Horns

[Adam Spiers]

Matthew Thode  wrote:

On 18-08-07 23:18:26, David Medberry wrote:

Requests have finally been made (today, August 7, 2018) to end the horns on
the train from Denver to Denver International airport (within the city
limits of Denver.) Prior approval had been given to remove the FLAGGERS
that were stationed at each crossing intersection.

Of particular note (at the bottom of the article):

There’s no estimate for how long it could take the FRA to approve quiet
zones.

ref:
https://www.9news.com/article/news/local/next/denver-officially-asks-fra-for-permission-to-quiet-a-line-horns/73-581499094

I'd recommend bringing your sleeping aids, ear plugs, etc, just in case not
approved by next month's PTG. (The Renaissance is within Denver proper as
near as I can tell so that nearby intersection should be covered by this
ruling/decision if and when it comes down.)


Thanks for the update, if you are up to it, keeping us informed on this
would be nice, if only for the hilarity.


Thanks indeed for the warning.

If the approval doesn't go through, we may need to resume the design
work started last year; see lines 187 onwards of

   https://etherpad.openstack.org/p/queens-PTG-feedback

__
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] murano-dashboard 6.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

A new release candidate for murano-dashboard for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/murano-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

http://git.openstack.org/cgit/openstack/murano-dashboard/log/?h=stable/rocky

Release notes for murano-dashboard can be found at:

http://docs.openstack.org/releasenotes/murano-dashboard/




__
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] murano 6.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

A new release candidate for murano for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/murano/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

http://git.openstack.org/cgit/openstack/murano/log/?h=stable/rocky

Release notes for murano can be found at:

http://docs.openstack.org/releasenotes/murano/




__
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] Stepping down as coordinator for the Outreachy internships

[Thierry Carrez]

Victoria Martínez de la Cruz wrote:
I'm reaching you out to let you know that I'll be stepping down as 
coordinator for OpenStack next round. I had been contributing to this 
effort for several rounds now and I believe is a good moment for 
somebody else to take the lead. You all know how important is Outreachy 
to me and I'm grateful for all the amazing things I've done as part of 
the Outreachy program and all the great people I've met in the way. I 
plan to keep involved with the internships but leave the coordination 
tasks to somebody else.


Thanks for helping with this effort for all this time !

--
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] [all][elections] Project Team Lead Election Conclusion and Results

[Thierry Carrez]

Tony Breeds wrote:

Thank you to the electorate, to all those who voted and to all
candidates who put their name forward for Project Team Lead (PTL) in
this election. A healthy, open process breeds trust in our decision
making capability thank you to all those who make this process possible.

Now for the results of the PTL election process, please join me in
extending congratulations to the following PTLs:
[...]


Congrats to all, and thank you for stepping up and helping stewarding 
our various project teams !


--
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] Does neutron support QinQ(vlan transparent) ?

[Frank Wang]

Awesome! Thanks, I'll take some time to review this patch. we can discuss it 
deeper during the review


At 2018-08-08 14:59:21, "Bence Romsics"  wrote:
>Hi,
>
>Just about a week ago Li Zhouzhou pushed a change for review to
>support vlan transparency with ovs too (building on the relatively new
>QinQ support in ovs):
>
>https://review.openstack.org/576687
>
>I did not get time to look into the patch deeper yet, but I guess
>reviews are always welcome. I also cc-ed this mail so he/she can chime
>in.
>
>Cheers,
>Bence Romsics
>On Tue, Aug 7, 2018 at 1:32 PM Sean Mooney  wrote:
>>
>> TL;DR
>> it wont work with the ovs agent but "should" work with linux bridge.
>> see full message below for details.
>> regards
>> sean.
>>
>> the linux bridge agent supports the  vlan_transparent option only when
>> createing networks with an l3 segmentation type e.g. vxlan,gre...
>>
>> ovs using the neutron l2 agnet does not supprot vlan_transparent
>> netwroks because of how that agent use vlans for tenant isolation on
>> the br-int.
>>
>> it is possible to use achive vlan transparancy with ovs usign an sdn
>> controller such as odl or ovn but that was not what you asked in your
>> question so i wont expand on that futher.
>>
>> if you deploy openstack with linux bridge networking and then create a
>> tenant network of type vxlan with vlan_transparancy set to true and
>> your tenants
>> generate QinQ traffic with an mtu reduced so that it will fix within
>> the vxlan tunnel unfragmented then yes it should be possibly however
>> you may need to disable port_security/security groups on the port as
>> im not sure if the ip tables firewall driver will correctly handel
>> this case.
>>
>> an alternive to disabling security groups would be to add an explicit
>> rule that matched on the etehrnet type and allowed QinQ traffic on
>> ingress and egress from the vm.
>>
>> as far as i am aware this is not tested in the gate so while it should
>> work  the lack of documentation and test coverage means you will
>> likely be one of the first to test it if you
>> choose to do so and it may fail for many reasons.
>>
>>
>> On 7 August 2018 at 09:15, Frank Wang  wrote:
>> > Hello folks,
>> >
>> > I noted that the API already has the vlan_transparent attribute in the
>> > network, Do neutron-agents(linux-bridge, openvswitch) support QinQ?  I
>> > didn't find any reference materials that could guide me on how to use or
>> > configure it.
>> >
>> > Thank for your time reading this, Any comments would be 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
>> >
>>
>> __
>> 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] [cyborg]Team Weekly Meeting 2018.08.08

[Zhipeng Huang]

Hi Team,

We are rushing towards the end of Rocky cycle and let's use the meeting to
sync up with any important features still on the fly.

starting UTC1400 at #openstack-cyborg, as usual

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] Paste unmaintained

[Chris Dent]

On Wed, 8 Aug 2018, Thomas Goirand wrote:


If you don't configure uwsgi to do any special logging, then then only
thing you'll see in the log file is client requests, without any kind of
logging from the wsgi application. To have proper logging, one needs to
add, in the uwsgi config file:

paste-logger = true

If you do that, then you need the python3-pastescript installed, which
itself depends on the python3-paste package.

Really, I don't see how an operator could run without the paste-logger
option activated. Without it, you see nothing in the logs.


I'm pretty sure your statements here are not true. In the uwsgi
configs for services in devstack, paste-logger is not used. In the
uwsgi set up [1] I use in placedock [2], paste-logger is not used.

Yet both have perfectly reasonable logs showing a variety of log
levels, including request logs at INFO, and server debugging and
warnings where you would expect it to be.

Can you please point me to where you are seeing these problems?
Clearly something is confused somewhere. Is the difference in our
experiences that both of the situations I describe above are happy
with logging being on stderr and you're talking about being able to
config logging to files, within the application itself? If that's
the case then my response would b: don't do that. Let systemd, or
your container, or apache2, or whatever process/service orchestration
system you have going manage that. That's what they are there for.

[1] https://github.com/cdent/placedock/blob/master/shared/placement-uwsgi.ini
[2] https://github.com/cdent/placedock

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] Stepping down as coordinator for the Outreachy internships

[Julie Pichon]

On 8 August 2018 at 00:47, Victoria Martínez de la Cruz
 wrote:
> I'm reaching you out to let you know that I'll be stepping down as
> coordinator for OpenStack next round. I had been contributing to this effort
> for several rounds now and I believe is a good moment for somebody else to
> take the lead. You all know how important is Outreachy to me and I'm
> grateful for all the amazing things I've done as part of the Outreachy
> program and all the great people I've met in the way. I plan to keep
> involved with the internships but leave the coordination tasks to somebody
> else.

Thanks for doing such a wonderful job and keeping Outreachy going the
last few years! :)

Julie

> If you are interested in becoming an Outreachy coordinator, let me know and
> I can share my experience and provide some guidance.
>
> Thanks,
>
> Victoria

__
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 lagging behind 2 major python versions: we need a Python 3.7 gate

[Thomas Goirand]

On 08/07/2018 06:10 PM, Corey Bryant wrote:
> I was concerned that there wouldn't be any
> gating until Ubuntu 20.04 (April 2020)
Same over here. I'm concerned that it takes another 2 years, which
really, we cannot afford.

> but Py3.7 is available in bionic today.

Is Bionic going to be released with Py3.7? In Debconf18 in Taiwan, Doko
didn't seem completely sure about it.

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] Paste unmaintained

[Thomas Goirand]

On 08/07/2018 05:17 PM, Doug Hellmann wrote:
> Excerpts from Thomas Goirand's message of 2018-08-07 16:57:59 +0200:
>> On 08/02/2018 04:27 PM, Doug Hellmann wrote:
>>>
>>> The last I heard, a few years ago Ian moved away from Python to
>>> JavaScript as part of his work at Mozilla. The support around
>>> paste.deploy has been sporadic since then, and was one of the reasons
>>> we discussed a goal of dropping paste.ini as a configuration file.
>>
>> Doug,
>>
>> That's nice to have direct dependency, but this doesn't cover
>> everything. If using uwsgi, if you want any kind of logging from the
>> wsgi application, you need to use pastescript, which itself runtimes
>> depends on paste. So, anything which potentially has an API also depends
>> indirectly on Paste.
> 
> I'm not sure why that would be the case. Surely *any* middleware could
> set up logging?
> 
> Doug

Doug,

If you don't configure uwsgi to do any special logging, then then only
thing you'll see in the log file is client requests, without any kind of
logging from the wsgi application. To have proper logging, one needs to
add, in the uwsgi config file:

paste-logger = true

If you do that, then you need the python3-pastescript installed, which
itself depends on the python3-paste package.

Really, I don't see how an operator could run without the paste-logger
option activated. Without it, you see nothing in the logs.

I hope this helps,
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] [neutron] Does neutron support QinQ(vlan transparent) ?

[Bence Romsics]

Hi,

Just about a week ago Li Zhouzhou pushed a change for review to
support vlan transparency with ovs too (building on the relatively new
QinQ support in ovs):

https://review.openstack.org/576687

I did not get time to look into the patch deeper yet, but I guess
reviews are always welcome. I also cc-ed this mail so he/she can chime
in.

Cheers,
Bence Romsics
On Tue, Aug 7, 2018 at 1:32 PM Sean Mooney  wrote:
>
> TL;DR
> it wont work with the ovs agent but "should" work with linux bridge.
> see full message below for details.
> regards
> sean.
>
> the linux bridge agent supports the  vlan_transparent option only when
> createing networks with an l3 segmentation type e.g. vxlan,gre...
>
> ovs using the neutron l2 agnet does not supprot vlan_transparent
> netwroks because of how that agent use vlans for tenant isolation on
> the br-int.
>
> it is possible to use achive vlan transparancy with ovs usign an sdn
> controller such as odl or ovn but that was not what you asked in your
> question so i wont expand on that futher.
>
> if you deploy openstack with linux bridge networking and then create a
> tenant network of type vxlan with vlan_transparancy set to true and
> your tenants
> generate QinQ traffic with an mtu reduced so that it will fix within
> the vxlan tunnel unfragmented then yes it should be possibly however
> you may need to disable port_security/security groups on the port as
> im not sure if the ip tables firewall driver will correctly handel
> this case.
>
> an alternive to disabling security groups would be to add an explicit
> rule that matched on the etehrnet type and allowed QinQ traffic on
> ingress and egress from the vm.
>
> as far as i am aware this is not tested in the gate so while it should
> work  the lack of documentation and test coverage means you will
> likely be one of the first to test it if you
> choose to do so and it may fail for many reasons.
>
>
> On 7 August 2018 at 09:15, Frank Wang  wrote:
> > Hello folks,
> >
> > I noted that the API already has the vlan_transparent attribute in the
> > network, Do neutron-agents(linux-bridge, openvswitch) support QinQ?  I
> > didn't find any reference materials that could guide me on how to use or
> > configure it.
> >
> > Thank for your time reading this, Any comments would be 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
> >
>
> __
> 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