Re: [openstack-dev] [requirements][masakari] FFE for adding python-masakariclient in global-requirements

[Sam P]

Hi Tony,

Correction:
>> You can take that or:
>> https://review.openstack.org/#/c/457491/
> Thanks for the update and I will try to merge #/c/457491 asap.
> Otherwise I will resolve the merge conflicts.
I did not realize that you add [1] depends on [2]. I will wait for [2]
to get merged.

[1] https://review.openstack.org/#/c/457491
[2] https://review.openstack.org/#/c/491692/
--- Regards,
Sampath



On Thu, Aug 10, 2017 at 11:59 PM, Sam P  wrote:
> Hi Tony,
>
>  As you suggested, I would like go with option 1.
>
>> Once that merges the bot will suggest a review to update your
>> requirements files.
>>
>> You can take that or:
>> https://review.openstack.org/#/c/457491/
> Thanks for the update and I will try to merge #/c/457491 asap.
> Otherwise I will resolve the merge conflicts.
>
>> Apart from the change described above you're right.  You need to block
>> and changes generated by the proposal bot from the time requirements
>> branches until you branch.
>> All good?
> All good.  Thank you for all the help and support..
>
>
> --- Regards,
> Sampath
>
>
>
> On Thu, Aug 10, 2017 at 7:08 PM, Tony Breeds  wrote:
>> On Thu, Aug 10, 2017 at 12:58:21PM -0500, Sam P wrote:
>>> Hi Tony,
>>>
>>> For maskari-monitors, earliest we can cut stable/pike is 8/11.
>>> You was mentioned about masakari and related projects in [1].
>>> For python-masakariclient, stable/pike can be cut on 8/11.
>>> However, for maskari I would like to land few changes before cut 
>>> stable/pike and
>>> hopefully we can cut stable/pike after 8/15 masakari team meeting.
>>>
>>>   As I discussed with Matthew[2], In the case, you unfreeze
>>> requirements before 8/15,
>>>  we can block requirements update for masakari till we create the
>>> stable/pike branch.
>>>  Any comments on this plan?
>>
>> Based on what you've said Masakari is going to have a stable/pike
>> branch.  So we have 3 options:
>>
>> 1) Grant the FFE and ensure that the bot-generated change lands in
>>masakari-monitors before they branch ; or
>>
>> 2) Wait until after both requirements and masakari branch and takes this
>>on master backport it to pike (which would kinda sorta be a process
>>violation) and then let the bot take over ; or
>>
>> 3) Just take this on master and disable the check-requirements for
>>masakari on stable/*
>>
>> It seems to me that option 1 is the least work and ends up with the best
>> result.
>>
>> So with that in mind I'm going to approve:
>> https://review.openstack.org/#/c/491692/
>>
>> Once that merges the bot will suggest a review to update your
>> requirements files.
>>
>> You can take that or:
>> https://review.openstack.org/#/c/457491/
>>
>> or some combination of both after resolving any merge conflicts.
>>
>> You'll need to do one of those before you branch stable/pike
>>
>> Apart from the change described above you're right.  You need to block
>> and changes generated by the proposal bot from the time requirements
>> branches until you branch.
>>
>> All good?
>>
>> Yours Tony.
>>
>> __
>> OpenStack Development Mailing 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][infra]Plan to support Python 3.6 ?

[Ian Wienand]

On 08/09/2017 11:25 PM, ChangBo Guo wrote:

We received Python 3.6 related Bug recently [1][2]. That let me think
what's the plan to support Python 3.6 for OpenStack in the future.   Python
3.6 was released on December 23, 2016, has some different behaviors from
Python 3.5[3]. talked with cdent in the IRC, would like to discuss this
through mailing list , and suggest a discussion at the PTG[3]

1. what's the time to support Python 3.6 ?

2. what 's the  plan or process ?


If you really want to live on the edge, Fedora 26 CI nodes are
available and include Python 3.6.  I'll be happy to help if you're not
familiar with using different nodes for jobs, or with any issues.

I've had devstack going in experimental successfully.  I probably
wouldn't recommend throwing it in as a voting gate job straight away,
but everything should be there :)

-i


__
OpenStack Development Mailing 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][masakari] FFE for adding python-masakariclient in global-requirements

[Sam P]

Hi Tony,

 As you suggested, I would like go with option 1.

> Once that merges the bot will suggest a review to update your
> requirements files.
>
> You can take that or:
> https://review.openstack.org/#/c/457491/
Thanks for the update and I will try to merge #/c/457491 asap.
Otherwise I will resolve the merge conflicts.

> Apart from the change described above you're right.  You need to block
> and changes generated by the proposal bot from the time requirements
> branches until you branch.
> All good?
All good.  Thank you for all the help and support..


--- Regards,
Sampath



On Thu, Aug 10, 2017 at 7:08 PM, Tony Breeds  wrote:
> On Thu, Aug 10, 2017 at 12:58:21PM -0500, Sam P wrote:
>> Hi Tony,
>>
>> For maskari-monitors, earliest we can cut stable/pike is 8/11.
>> You was mentioned about masakari and related projects in [1].
>> For python-masakariclient, stable/pike can be cut on 8/11.
>> However, for maskari I would like to land few changes before cut stable/pike 
>> and
>> hopefully we can cut stable/pike after 8/15 masakari team meeting.
>>
>>   As I discussed with Matthew[2], In the case, you unfreeze
>> requirements before 8/15,
>>  we can block requirements update for masakari till we create the
>> stable/pike branch.
>>  Any comments on this plan?
>
> Based on what you've said Masakari is going to have a stable/pike
> branch.  So we have 3 options:
>
> 1) Grant the FFE and ensure that the bot-generated change lands in
>masakari-monitors before they branch ; or
>
> 2) Wait until after both requirements and masakari branch and takes this
>on master backport it to pike (which would kinda sorta be a process
>violation) and then let the bot take over ; or
>
> 3) Just take this on master and disable the check-requirements for
>masakari on stable/*
>
> It seems to me that option 1 is the least work and ends up with the best
> result.
>
> So with that in mind I'm going to approve:
> https://review.openstack.org/#/c/491692/
>
> Once that merges the bot will suggest a review to update your
> requirements files.
>
> You can take that or:
> https://review.openstack.org/#/c/457491/
>
> or some combination of both after resolving any merge conflicts.
>
> You'll need to do one of those before you branch stable/pike
>
> Apart from the change described above you're right.  You need to block
> and changes generated by the proposal bot from the time requirements
> branches until you branch.
>
> All good?
>
> Yours Tony.
>
> __
> OpenStack Development Mailing 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][puppet] Hold off on approving patches until further notice

[Alex Schultz]

On Thu, Aug 10, 2017 at 11:12 AM, Paul Belanger  wrote:
> On Thu, Aug 10, 2017 at 07:03:32AM -0600, Alex Schultz wrote:
>> FYI,
>>
>> The gates are hosed for a variety of reasons[0][1] and we can't get
>> critical patches merged. Please hold off on rechecking or approving
>> anything new until further notice.   We're hoping to get some of the
>> fixes for this merged today.  I will send a note when it's OK to merge
>> again.
>>
>> [0] https://bugs.launchpad.net/tripleo/+bug/1709428
>> [1] https://bugs.launchpad.net/tripleo/+bug/1709327
>>
> So far, these are the 3 patches we need to land today:
>
>   Exclude networking-bagpipe from dlrn
> - https://review.openstack.org/491878
>
>   Disable existing repositories in tripleo-ci
> - https://review.openstack.org/492289
>
>   Stop trying to build networking-bagpipe with DLRN
> - https://review.openstack.org/492339
>
> These 3 fixes will take care of the large amount of gate resets tripleo is
> currently seeing. Like Alex says, please try not to approve / recheck anything
> until we land these.
>

Ok so we've managed to land patches to improve the reliability.

https://review.openstack.org/492339 - merged
https://review.openstack.org/491878 - still pending but we managed to
get the package fixed so this one is not as critical anymore
https://review.openstack.org/491522 - merged
https://review.openstack.org/492289 - merged

We found that the undercloud-container's job is still trying to pull
from buildlogs.centos.org, and I've proposed a fix
https://review.openstack.org/#/c/492786/

I've restored (and approved) previously approved patches that have a
high/critical bug or a FFE approved blueprint associated.

It should be noted that the following patches for tripleo do not have
a bug or bp reference so they should be updated prior to being
re-approved:
https://review.openstack.org/#/c/400407/
https://review.openstack.org/#/c/489083/
https://review.openstack.org/#/c/475457/

For tripleo patches, please refer to Emilien's email[0] about the RC
schedule with includes these rules about what patches should be
merged.  Please be careful on rechecks and check failures. Do not
blindly recheck.  We have noticed some issues with citycloud nodes, so
if you spot problems with specific clouds please let us know so we can
track these and work with infra on it.

Thanks,
-Alex

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120806.html

> Thanks,
> PB
>
> __
> OpenStack Development Mailing 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] [keystone] keystone 12.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/keystone/

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

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

http://git.openstack.org/cgit/openstack/keystone/log/?h=stable/pike

Release notes for keystone can be found at:

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




__
OpenStack Development Mailing 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] cinder 11.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/cinder/

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

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

http://git.openstack.org/cgit/openstack/cinder/log/?h=stable/pike

Release notes for cinder can be found at:

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




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

[openstack-dev] [ironic]Is there document about drac driver?

[王俊]

Hi,
 I make a test about dell server,but I can find few docs about drac 
driver, anybody can give me a suggestion?

保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！
__
OpenStack Development Mailing 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][vpnaas] pike rc

[Takashi Yamamoto]

done

http://git.openstack.org/cgit/openstack/neutron-vpnaas/tag/?h=11.0.0.0rc1
https://review.openstack.org/#/q/status:open+project:openstack/neutron-vpnaas+branch:stable/pike+topic:create-pike

On Tue, Aug 8, 2017 at 10:46 AM, Takashi Yamamoto  wrote:
> hi,
>
> can anyone with an appropriate permission create a stable/pike
> and pike rc1 for neutron-vpnaas?
>
> stable/pike
> 11.0.0.0rc1
> openstack/neutron-vpnaas
> 8278615c1f35f98447a3f9692a78ab45e90ee8c6
>
> thank you.

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

[openstack-dev] [glance] glance 15.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/glance/

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

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

http://git.openstack.org/cgit/openstack/glance/log/?h=stable/pike

Release notes for glance can be found at:

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




__
OpenStack Development Mailing 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] [senlin] senlin 4.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/senlin/

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

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

http://git.openstack.org/cgit/openstack/senlin/log/?h=stable/pike

Release notes for senlin can be found at:

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

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/senlin

and tag it *pike-rc-potential* to bring it to the senlin
release crew's attention.


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

[openstack-dev] neutron-vpnaas 11.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for neutron-vpnaas for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-vpnaas/

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

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

http://git.openstack.org/cgit/openstack/neutron-vpnaas/log/?h=stable/pike

Release notes for neutron-vpnaas can be found at:

http://docs.openstack.org/releasenotes/neutron-vpnaas/




__
OpenStack Development Mailing 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] [congress] congress 6.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/congress/

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

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

http://git.openstack.org/cgit/openstack/congress/log/?h=stable/pike

Release notes for congress can be found at:

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




__
OpenStack Development Mailing 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] [sahara] sahara-dashboard 7.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

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

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

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

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

http://git.openstack.org/cgit/openstack/sahara-dashboard/log/?h=stable/pike

Release notes for sahara-dashboard can be found at:

http://docs.openstack.org/releasenotes/sahara-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] [sahara] sahara-image-elements 7.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for sahara-image-elements for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/sahara-image-elements/

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

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


http://git.openstack.org/cgit/openstack/sahara-image-elements/log/?h=stable/pike

Release notes for sahara-image-elements can be found at:

http://docs.openstack.org/releasenotes/sahara-image-elements/




__
OpenStack Development Mailing 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] [sahara] sahara-extra 7.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for sahara-extra for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/sahara-extra/

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

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

http://git.openstack.org/cgit/openstack/sahara-extra/log/?h=stable/pike

Release notes for sahara-extra can be found at:

http://docs.openstack.org/releasenotes/sahara-extra/




__
OpenStack Development Mailing 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] [sahara] sahara 7.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/sahara/

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

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

http://git.openstack.org/cgit/openstack/sahara/log/?h=stable/pike

Release notes for sahara can be found at:

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




__
OpenStack Development Mailing 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][tap-as-a-service] pike branch/release

[Takashi Yamamoto]

done.

http://git.openstack.org/cgit/openstack/tap-as-a-service/tag/?h=2.0.0
https://review.openstack.org/#/q/status:open+project:openstack/tap-as-a-service+branch:stable/pike+topic:create-pike

On Tue, Aug 8, 2017 at 10:07 PM, Takashi Yamamoto  wrote:
> hi,
>
> On Tue, Aug 8, 2017 at 9:14 PM, Doug Hellmann  wrote:
>> Excerpts from Takashi Yamamoto's message of 2017-08-08 10:49:09 +0900:
>>> hi
>>>
>>> i'll create stable/pike (and probably a release) for tap-as-a-service
>>> in this week.
>>>
>>
>> We have a bunch of tools that expect stable branches to only be created
>> from releases, so please do tag before branching.
>
> ok.  thank you!
>
>>
>> Doug
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [requirements][masakari] FFE for adding python-masakariclient in global-requirements

[Tony Breeds]

On Thu, Aug 10, 2017 at 12:58:21PM -0500, Sam P wrote:
> Hi Tony,
> 
> For maskari-monitors, earliest we can cut stable/pike is 8/11.
> You was mentioned about masakari and related projects in [1].
> For python-masakariclient, stable/pike can be cut on 8/11.
> However, for maskari I would like to land few changes before cut stable/pike 
> and
> hopefully we can cut stable/pike after 8/15 masakari team meeting.
> 
>   As I discussed with Matthew[2], In the case, you unfreeze
> requirements before 8/15,
>  we can block requirements update for masakari till we create the
> stable/pike branch.
>  Any comments on this plan?

Based on what you've said Masakari is going to have a stable/pike
branch.  So we have 3 options:

1) Grant the FFE and ensure that the bot-generated change lands in
   masakari-monitors before they branch ; or

2) Wait until after both requirements and masakari branch and takes this
   on master backport it to pike (which would kinda sorta be a process
   violation) and then let the bot take over ; or

3) Just take this on master and disable the check-requirements for
   masakari on stable/*

It seems to me that option 1 is the least work and ends up with the best
result.

So with that in mind I'm going to approve:
https://review.openstack.org/#/c/491692/

Once that merges the bot will suggest a review to update your
requirements files.

You can take that or:
https://review.openstack.org/#/c/457491/

or some combination of both after resolving any merge conflicts.

You'll need to do one of those before you branch stable/pike

Apart from the change described above you're right.  You need to block
and changes generated by the proposal bot from the time requirements
branches until you branch.

All good?

Yours Tony.


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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Tony Breeds]

On Thu, Aug 10, 2017 at 11:01:23PM +, Jeremy Stanley wrote:

> Yes, it comes up often enough and as far as I'm aware reviewers
> haven't previously rejected unofficial projects who want to receive
> requirements updates. There are definitely projects who don't want
> to (or for license reasons perhaps even can't) be official teams but
> would still like their dependencies to remain compatible with those
> of official OpenStack deliverables.

Thanks.  I know you aren't suggesting altering the ability for OpenStack
Hosted projects to participate in the requirements process but I want to
go on the records saying 

I see having OpenStack Hosted projects syncing from requirements as a
big plus and I'd be pretty down on any move to reject them.  I'd also
resist any process change that makes it harder for Hosted projects (as
opposed to Governed projects) to participate in the requirements
process.

At this point it's hard for the affected teams to even see this thread
as there isn't an easy way to identify them.

Yours Tony.


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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Jeremy Stanley]

On 2017-08-11 08:49:18 +1000 (+1000), Tony Breeds wrote:
> On Thu, Aug 10, 2017 at 07:22:56PM +0900, Akihiro Motoki wrote:
[...]
> > I am not sure that projects not under the TC governance can use
> > openstack/releases repo. Is the openstack/release repo for
> > projects under the governance?
> 
> I didn't think that was the rule but it's certainly been said
> enough in the last 24 hours that it probably is correct.
> 
> With that in mind we'd do better if there was a process for
> Openstack Hosted projects to follow.
> 
> Perhaps they could maintain a
> 'deliverables//.yaml in their own repo that would
> mirror (but probably get out od sync with, openstack/releases.
> From a requirements POV I just need somewheer to look for data on
> the projects that are managed but not official.

Yes, it comes up often enough and as far as I'm aware reviewers
haven't previously rejected unofficial projects who want to receive
requirements updates. There are definitely projects who don't want
to (or for license reasons perhaps even can't) be official teams but
would still like their dependencies to remain compatible with those
of official OpenStack deliverables.
-- 
Jeremy Stanley


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

[OpenStack-Infra] Zuul v3: some layout checks disabled in project-config

[James E. Blair]

Hi,

With https://review.openstack.org/492697 we are moving gating of Zuul
itself and some related job repos from Zuul v2 to Zuul v3.  As part of
this, we need to disable some of the checks that we perform on the
layout file.  That change disables the following checks for the
openstack-infra/* repos only:

* usage of the merge-check template
* at least one check job
* at least one gate job
* every gerrit project appears in zuul

The first three should only be needed for a short time while we continue
to construct the post and release pipelines in Zuul v3.  After that is
complete, we should be able to reinstate those checks, but we will need
to keep the final check disabled (for openstack-infra repos at least)
until Zuul v2 is retired.

-Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Tony Breeds]

On Fri, Aug 11, 2017 at 12:46:20AM +0900, Ian Y. Choi wrote:
> Akihiro Motoki wrote on 8/10/2017 7:22 PM:
> > Tony,
> > 
> > Thanks for taking care.
> 
> 
> > 
> > > i18n   I18n
> > At now, i18n repo is a part of governance but this is a project which
> > has no need to cut a release,
> > so it always follows the master branch of the requirements repo.
> > It is not a blocker for opening the master branch in the requirements repo.
> > 
> 
> 
> Right - i18n repository has I18n contributor guide, translation glossary,
> and useful scripts with translate.openstack.org
> which all do not need to have stable branches to be maintained.

Now that I know what it is I can handle it in my script.  That's fine
 
> I am not pretty sure but it seems that some project repositories which are
> affected by requirements.txt in stable branches
> need to follow "stable:follows-policy" [1] for official projects?

No that is a seperate thing.  That tag asserts that the code delivered
via that repo adheres to the stable policy.

What this email thread is about is repos that subscribe to the 
 
Yours Tony.


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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Tony Breeds]

On Thu, Aug 10, 2017 at 07:22:56PM +0900, Akihiro Motoki wrote:
> Tony,
> 
> Thanks for taking care.
> 
> > The following repos don't seem to use the openstack/releases repo so I
> > have less information there.
> 
> Most of them are projects not under the governance (so-called "hosted"
> or "unofficial" projects),
> so I am not sure there is a good way to handle them.
> 
> I can comment some of them which I am involved in deeply.
> 
> > i18n   I18n
> 
> At now, i18n repo is a part of governance but this is a project which
> has no need to cut a release,
> so it always follows the master branch of the requirements repo.
> It is not a blocker for opening the master branch in the requirements repo.

Okay I'll added that to the 'branchless' group.
 
> > neutron-vpnaas
> > neutron-vpnaas-dashboard
> 
> These projects are neutron related and horizon plugin.
> We will do same things for other neutron stadium and horizon plugin projects.
> 
> IMHO we don't need to take care of them much.

As long as you block bot-updates from the time we branch (pike) until the time
you branch (pike) that is all that needs to happen
 
> > python-openstacksdk
> 
> python-openstackclient depends on this, so we need to cut stable/branch
> from the latest release. The status of the project is being discussed
> in the ML thread,
> but I believe we need to cut a stable branch. On the other hand, I
> think it does not
> block the opening of the master of the requirements repo as the latest
> release of
> python-openstacksdk is enough for Pike release of OSC.

As with the neutron-vpnaas repos, you need to block to bit updates or it
*does* block (or hamper) the requirements repo from re-opening master.

> > It'd be great to get some of these repos represented in
> > openstack/releases.  Having a confirmed release-model would go a long
> > way to clearing up the list. An alternate approach would be to remove
> > redundant items from projects.txt
> 
> I am not sure that projects not under the TC governance can use
> openstack/releases repo.
> Is the openstack/release repo for projects under the governance?

I didn't think that was the rule but it's certainly been said enough in
the last 24 hours that it probably is correct.

With that in mind we'd do better if there was a process for Openstack
Hosted projects to follow.

Perhaps they could maintain a 'deliverables//.yaml in
their own repo that would mirror (but probably get out od sync with,
openstack/releases.  From a requirements POV I just need somewheer to
look for data on the projects that are managed but not official.

Yours Tony.


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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Tony Breeds]

On Thu, Aug 10, 2017 at 10:17:23AM -0400, Matthew Treinish wrote:
> On Thu, Aug 10, 2017 at 03:46:32PM +1000, Tony Breeds wrote:
> > 
> > Hi All,
> > In an effort to qualify which projects are likley to be affected if
> > when we open the requirements repo I generated a list of all repos that:
> > 
> > 1. Subscribe to requirements management
> > 2. Do not already have a stable/pike branch
> > 3. Do not follow the cycle-with-milestones, cycle-trailing or
> >independent release models
> > 4. Are not a 'branchless' project (tempest or tempest-plugin)
> > 
> > These repos I believe *should* have a stable/pike branch or will see
> > problems when we open openstack/requirements.  Those issues were
> > described in [1]
> > 
> > It turns out close to 1/3rd of projects that subscribe to requirements
> > management are not ready for us to re-open for master.  So we need you
> > help to get that number down to a much more acceptable number.
> > 
> > The good news is it's pretty easy to fix this with the cool tools and
> > workflow in the releases repo[2].  I suspect that the 'service' will
> > take care of themselves, and the horizon-plugins are waiting to horizon
> > to cut RC1.
> > 
> > Repos with type: horizon-plugin
> > ironic-ui  ironic  
> > manila-ui  manila  
> > monasca-ui monasca 
> > neutron-fwaas-dashboardneutron 
> > solum-dashboardsolum   
> > tacker-horizon tacker  
> > watcher-dashboard  watcher 
> > zun-ui zun 
> > 
> > Repos with type: other
> > python-openstackclient OpenStackClient 
> > patroleQuality Assurance
> 
> Fwiw, patrole is also a tempest plugin. [1] So it should also fall into the
> branchless category and you don't need to worry about it branching before
> unfreezing requirements.

\o/  I shall update my script and the tracking document.

Thanks.

Yours Tony.


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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Tony Breeds]

On Thu, Aug 10, 2017 at 12:38:43PM +0200, Dmitry Tantsur wrote:
> Hi Tony!
> 
> I hope to finish releasing Ironic stuff next week. We still have a few
> critical things to land.

Cool
 
> On 08/10/2017 07:46 AM, Tony Breeds wrote:
> > 
> > Hi All,
> >  In an effort to qualify which projects are likley to be affected if
> > when we open the requirements repo I generated a list of all repos that:
> > 
> > 1. Subscribe to requirements management
> > 2. Do not already have a stable/pike branch
> > 3. Do not follow the cycle-with-milestones, cycle-trailing or
> > independent release models
> > 4. Are not a 'branchless' project (tempest or tempest-plugin)
> > 
> > These repos I believe *should* have a stable/pike branch or will see
> > problems when we open openstack/requirements.  Those issues were
> > described in [1]
> > 
> > It turns out close to 1/3rd of projects that subscribe to requirements
> > management are not ready for us to re-open for master.  So we need you
> > help to get that number down to a much more acceptable number.
> > 
> > The good news is it's pretty easy to fix this with the cool tools and
> > workflow in the releases repo[2].  I suspect that the 'service' will
> > take care of themselves, and the horizon-plugins are waiting to horizon
> > to cut RC1.
> > 
> > Repos with type: horizon-plugin
> > ironic-ui  ironic
> 
> This was released already.

Hmm okay perhaps my repo is out of date.  I'll check that.
 
> > manila-ui  manila
> > monasca-ui monasca
> > neutron-fwaas-dashboardneutron
> > solum-dashboardsolum
> > tacker-horizon tacker
> > watcher-dashboard  watcher
> > zun-ui zun
> > 
> > Repos with type: other
> > python-openstackclient OpenStackClient
> > patroleQuality Assurance
> > heat-agentsheat
> > ironic-inspector   ironic
> 
> Hmm, this should be type:service too, will double-check.

Cool.

Thanks.

Yours Tony.


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] [all][interop][heat][designate] Proposed updates to OpenStack Powered trademarks: extensions and verticals

[Chris Hoge]

> On Aug 10, 2017, at 2:47 PM, Chris Hoge  wrote:
> 
> At the upcoming board meeting in September, the Interop Working Group
> will be proposing a new trademark program to supplement the OpenStack
> Powered mark. This update formally defines two distinct types of programs.
> 
> 1) Platforms. This captures the three existing trademarks, OpenStack
> Powered Compute, OpenStack Powered Storage, and OpenStack Powered
> Platform. A platform can be thought of as a complete collection of
> OpenStack software to give a core set of functionality. For example,
> OpenStack Powered Storage provides Swift Object Storage and Horizon

Correction to above:
Swift and Keystone. Horizon is not required


> Identity. Compute offers Nova, Horizon, Glance, Cinder and Neutron.

Correction to the above:
Nova, Keystone, Glance, Cinder, and Neutron. Horizon is not required.


> 
> We are generalizing the idea of platforms to be able to capture other
> verticals within the OpenStack ecosystem. For example, we are currently
> working with NFV leaders to potentially build out an OpenStack Powered
> NFV guideline that could be used in a future trademark program.
> 
> 2) Extensions. This captures projects that provide additional
> functionality to platforms, but require certain core services to be
> available.  The intent is for an OpenStack Powered cloud to be able to
> advertise interoperable capabilities that would be nice for users to
> have but aren't strictly required for general interoperability. The
> first two extensions we are focusing on are Heat Orchestration and
> Designate DNS. If a public cloud were offering the Designate API,
> they could qualify to present themselves as "OpenStack Powered Platform
> with DNS".
> 
> We are seeking advisory status from the board at the September board
> meeting, with a goal to launch the new extension programs after the
> January board meeting. The Interop Working Group would also like to
> work with the TC on encouraging more projects to adopt the Interop
> Working Group schema to define what public-facing interfaces and code
> should be present for a deployed instance of that project to qualify
> as interoperable.
> 
> If you would like to see the new extension programs, I have reviews
> up for both Heat and Designate.
> 
> Heat: https://review.openstack.org/#/c/490648/
> Designate: https://review.openstack.org/#/c/492635/
> 
> The new interop guideline schema format is also ready to be presented
> to the board:
> 
> 2.0 schema documentation:
>  
> https://git.openstack.org/cgit/openstack/interop/tree/doc/source/schema/2.0.rst
> 2.0 schema example:
>  
> https://git.openstack.org/cgit/openstack/interop/tree/doc/source/schema/next.2.0.json
> 
> The review for the 2.0 schema (merged):
>  https://review.openstack.org/#/c/430556/
> 
> If you are the PTL of a project that would like to be considered for an
> extension trademark program, please don't hesitate to reach out to me or
> any other member of the Interop Working Group.
> 
> We're pretty excited about how we're planning on extending the trademark
> program next year, and are looking forward to working with the developer
> community to help guarantee the interoperability of OpenStack clouds
> through testing and trademark compliance.
> 
> Thanks!
> 
> Chris Hoge
> Interop Engineer
> OpenStack Foundation
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [all][interop][heat][designate] Proposed updates to OpenStack Powered trademarks: extensions and verticals

[Chris Hoge]

At the upcoming board meeting in September, the Interop Working Group
will be proposing a new trademark program to supplement the OpenStack
Powered mark. This update formally defines two distinct types of programs.

1) Platforms. This captures the three existing trademarks, OpenStack
Powered Compute, OpenStack Powered Storage, and OpenStack Powered
Platform. A platform can be thought of as a complete collection of
OpenStack software to give a core set of functionality. For example,
OpenStack Powered Storage provides Swift Object Storage and Horizon
Identity. Compute offers Nova, Horizon, Glance, Cinder and Neutron.

We are generalizing the idea of platforms to be able to capture other
verticals within the OpenStack ecosystem. For example, we are currently
working with NFV leaders to potentially build out an OpenStack Powered
NFV guideline that could be used in a future trademark program.

2) Extensions. This captures projects that provide additional
functionality to platforms, but require certain core services to be
available.  The intent is for an OpenStack Powered cloud to be able to
advertise interoperable capabilities that would be nice for users to
have but aren't strictly required for general interoperability. The
first two extensions we are focusing on are Heat Orchestration and
Designate DNS. If a public cloud were offering the Designate API,
they could qualify to present themselves as "OpenStack Powered Platform
with DNS".

We are seeking advisory status from the board at the September board
meeting, with a goal to launch the new extension programs after the
January board meeting. The Interop Working Group would also like to
work with the TC on encouraging more projects to adopt the Interop
Working Group schema to define what public-facing interfaces and code
should be present for a deployed instance of that project to qualify
as interoperable.

If you would like to see the new extension programs, I have reviews
up for both Heat and Designate.

Heat: https://review.openstack.org/#/c/490648/
Designate: https://review.openstack.org/#/c/492635/

The new interop guideline schema format is also ready to be presented
to the board:

2.0 schema documentation:
  
https://git.openstack.org/cgit/openstack/interop/tree/doc/source/schema/2.0.rst
2.0 schema example:
  
https://git.openstack.org/cgit/openstack/interop/tree/doc/source/schema/next.2.0.json

The review for the 2.0 schema (merged):
  https://review.openstack.org/#/c/430556/

If you are the PTL of a project that would like to be considered for an
extension trademark program, please don't hesitate to reach out to me or
any other member of the Interop Working Group.

We're pretty excited about how we're planning on extending the trademark
program next year, and are looking forward to working with the developer
community to help guarantee the interoperability of OpenStack clouds
through testing and trademark compliance.

Thanks!

Chris Hoge
Interop Engineer
OpenStack Foundation


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

Re: [openstack-dev] [keystone] removing domain configuration upload via keystone-manage

[Lance Bragstad]

I proposed a patch to remove the deprecation [0].

[0] https://review.openstack.org/492694

On 06/28/2017 09:33 PM, Lance Bragstad wrote:
> Cool - I'm glad this is generating discussion. I personally don't see
> a whole lot of maintenance costs with `keystone-manage
> domain_config_upload`. I was parsing deprecation warnings in the code
> base and noticed it was staged for removal, but it wasn't clear when
> or why. It also wasn't very clear if there was a desire to move away
> from the file-based approach all together, but it was something that
> came up in the meeting.
>
> Based on the responses and the reasons listed, I think removing the
> deprecation to avoid confusion on where we stand would be a good thing
> (especially since it's low maintenance).
>
> I appreciate the feedback!
>
>
> On 06/28/2017 04:22 PM, Steve Martinelli wrote:
>> ++ to what colleen said. I've always preferred using the file-backed
>> approach.
>>
>> I think we deprecated it for completeness and to only have a single
>> tool for configuring LDAP-backed domains. If it's tested well enough
>> and not much effort to support then we should keep it around as an
>> alternative method for configuring LDAP-backed domains.
>>
>> On Wed, Jun 28, 2017 at 4:53 PM, Colleen Murphy > > wrote:
>>
>>> On Wed, Jun 28, 2017 at 2:00 AM, Lance Bragstad
>>> > wrote:
>>>
>>> Hi all,
>>>
>>> Keystone has deprecated the domain configuration upload
>>> capability provided through `keystone-manage`. We
>>> discussed it's removal in today's meeting [0] and wanted
>>> to send a quick note to the operator list. The ability
>>> to upload a domain config into keystone was done as a
>>> stop-gap until the API was marked as stable [1]. It
>>> seems as though file-based domain configuration was only
>>> a band-aid until full support was done.
>>>
>>> Of the operators using the domain config API in
>>> keystone, how many are backing their configurations with
>>> actual configuration files versus the API?
>>>
>>>
>>> [0]
>>> 
>>> http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-06-27-18.00.log.html#l-167
>>> 
>>> 
>>> [1]
>>> 
>>> https://github.com/openstack/keystone/commit/a5c5f5bce812fad3c6c88a23203bd6c00451e7b3
>>> 
>>> 
>>>
>>  I am not clear on why we need to deprecate and remove
>> file-backed domain configuration. The way I see it:
>>
>> * It's reflectve with the primary configuration, so I can copy
>> over the chunks I need from keystone.conf into
>> /etc/keystone/domains/keystone.domain.conf without thinking too
>> hard about it
>> * It's convenient for deployment tools to just lay down config files
>> * It's not that much extra effort for the keystone team to
>> maintain (is it?)
>>
>> The use case for file-backed domain configs is for smaller clouds
>> with just one or two LDAP-backed domains. There's not a real need
>> for users to change domain configs so the file-backed config is
>> plenty fine. I don't see a lot of gain from removing that
>> functionality.
>>
>> I don't particularly care about the keystone-manage tool, if that
>> goes away it would still be relatively easy to write a python
>> script to parse and upload configs if a user does eventually
>> decide to transition.
>>
>> As a side note, SUSE happens to be using file-backed domain
>> configs in our product. It would not be a big deal to rewrite
>> that bit to use the API, but I think it's just as easy to let us
>> keep using it.
>>
>> Colleen
>>
>> 
>> __
>> OpenStack Development Mailing 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
>



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for 

[openstack-dev] [horizon] horizon 12.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/horizon/

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

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

http://git.openstack.org/cgit/openstack/horizon/log/?h=stable/pike

Release notes for horizon can be found at:

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




__
OpenStack Development Mailing 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] [masakari]Remove ERROR instances from recovery targets

[Sam P]

Hi Rikimaru,

 Currently, [1] does not skip error instances from evacuating.
 However, it does make it back to error after evacuating the instance.
 If your requirement does not satisfied with that, then the next option will be
 create a option for not to evacuate error VMs first place.
 Because, solution proposed in [1], there will be small chance that
the VM will be
 active for a small time and it will cause critical problems in
1ACT/n SBY or any HA model.

[1] https://review.openstack.org/#/c/469029/
--- Regards,
Sampath



On Tue, Jul 11, 2017 at 2:51 AM, Rikimaru Honjo
 wrote:
> Hello all,
>
> Current Masakari also rescues ERROR instances when host failure happen.
> Those instances will be changed to ACTIVE after rescued.[1]
>
> But I think that some users don't want to rescue ERROR instances.
> For example, if user is running 1ACT/n SBY application on instances,
> launching ERROR instances will cause unexpected effect.
>
> So I want to add a configurable option.
> ERROR instances won't be rescued if the option is set.
>
> Please talk your opinion about this issue.
>
> P.S.
> I talked about this issue in IRC meeting.
> http://eavesdrop.openstack.org/meetings/masakari/2017/masakari.2017-07-11-04.00.log.html
> But time was up at that time.
>
> [1]
> This is Evacuate API's behavior.
>
> [2]
> There is a possibility that following patch resolve this issue,
> but that will take time.
> https://review.openstack.org/#/c/469029/
>
> Best regards,
> --
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> Rikmaru Honjo
> E-mail:honjo.rikim...@po.ntt-tx.co.jp
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Call for help with in-tree tempest scenario test failures

[Sławek Kapłoński]

Hello,

I’m still checking this QoS scenario test and I found something strange IMHO.
For example, almost all failed tests from last 2 days were executed on nodes 
with names like:
* ubuntu-xenial-2-node-citycloud-YYY- - on those nodes almost (or even all) 
all scenario tests was failed due to failed SSH connection to instance,
* ubuntu-xenial-2-node-rax-iad- - on those nodes QoS test was failed 
because of timeout during reading data

I’m noob in gate tests and how it’s exactly working so my conclusions can be 
completely wrong but maybe those issues are related somehow to some cloud 
providers which provides infrastructure for tests?
Maybe someone more experienced could take a look on that and help me? Thx in 
advance.

—
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




> Wiadomość napisana przez Ihar Hrachyshka  w dniu 
> 03.08.2017, o godz. 23:40:
> 
> Thanks for those who stepped in (Armando and Slawek).
> 
> We still have quite some failures that would benefit from initial log
> triage and fixes. If you feel like in this feature freeze time you
> have less things to do, helping with those scenario failures would be
> a good way to contribute to the project.
> 
> Thanks,
> Ihar
> 
> On Fri, Jul 28, 2017 at 6:02 AM, Sławek Kapłoński  wrote:
>> Hello,
>> 
>> I will try to check QoS tests in this job.
>> 
>> —
>> Best regards
>> Slawek Kaplonski
>> sla...@kaplonski.pl
>> 
>> 
>> 
>> 
>>> Wiadomość napisana przez Jakub Libosvar  w dniu 
>>> 28.07.2017, o godz. 14:49:
>>> 
>>> Hi all,
>>> 
>>> as sending out a call for help with our precious jobs was very
>>> successful last time and we swept all Python 3 functional from Neutron
>>> pretty fast (kudos the the team!), here comes a new round of failures.
>>> 
>>> This time I'm asking for your help >> poster here> with gate-tempest-dsvm-neutron-dvr-multinode-scenario
>>> non-voting job. This job has been part of check queue for a while and is
>>> very very unstable. Such job covers scenarios like router dvr/ha/legacy
>>> migrations, qos, trunk and dvr. I went through current failures and
>>> created an etherpad [1] with categorized failures and logstash queries
>>> that give you latest failures with given particular tests.
>>> 
>>> If you feel like doing troubleshooting and sending fixes for gates,
>>> please pick one test and write down your name to the test.
>>> 
>>> Thanks to all who are willing to participate.
>>> 
>>> Have a great weekend.
>>> Jakub
>>> 
>>> 
>>> [1]
>>> https://etherpad.openstack.org/p/neutron-dvr-multinode-scenario-gate-failures
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing 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



signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing 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] [barbican] barbican 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/barbican/

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

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

http://git.openstack.org/cgit/openstack/barbican/log/?h=stable/pike

Release notes for barbican can be found at:

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




__
OpenStack Development Mailing 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_powervm 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/nova-powervm/

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

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

http://git.openstack.org/cgit/openstack/nova_powervm/log/?h=stable/pike

Release notes for nova_powervm can be found at:

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




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

[openstack-dev] networking-powervm 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for networking-powervm for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/networking-powervm/

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

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


http://git.openstack.org/cgit/openstack/networking-powervm/log/?h=stable/pike

Release notes for networking-powervm can be found at:

http://docs.openstack.org/releasenotes/networking-powervm/




__
OpenStack Development Mailing 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] [telemetry] ceilometer-powervm 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for ceilometer-powervm for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/ceilometer-powervm/

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

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


http://git.openstack.org/cgit/openstack/ceilometer-powervm/log/?h=stable/pike

Release notes for ceilometer-powervm can be found at:

http://docs.openstack.org/releasenotes/ceilometer-powervm/




__
OpenStack Development Mailing 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][infra] Functional job failure rate at 100%

[Jeremy Stanley]

On 2017-08-10 17:13:58 + (+), Mooney, Sean K wrote:
[...]
> so on that it would bre quite trivial to have disk image builder
> install The linux-image-virtual-hwe-16.04
> linux-image-virtual-hwe-16.04-edge to pull in a 4.10 or 4.11
> kernel respctivly if the default 4.4 is broken. We just need a new
> dib element to install the package And modify the  nodepool config
> to include it when it rebuildes the image every night.
> Alternitivly You can pull a vanilla kernel form
> http://kernel.ubuntu.com/~kernel-ppa/mainline/ Follow the process
> documented here https://wiki.ubuntu.com/Kernel/MainlineBuilds If
> you want to maintain testing with 4.4.x
[...]

Sure, your definition of "quite trivial" just differs a lot from
mine. Given that the bug in question seems to have no further impact
to the pace of development with the discussed test temporarily
disabled, that strikes me as a lot more maintainable in the long run
for a problem which started getting urgent attention from the distro
as soon as it was reported to them and will likely be resolved over
the course of the next few days at which point we'll automatically
update to the fixed version and you can try reenabling that test
again.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [nova] Thanks gibi!

[Jay Pipes]

On 08/10/2017 01:57 PM, Matt Riedemann wrote:
Apparently we don't have community contributor awards at the PTG, only 
the summit, and seeing as that's several months away now, which is kind 
of an eternity, I wanted to take the time now to thank gibi (Balazs 
Gibizer to his parents) for all the work he's been doing in Nova.


Not only does gibi lead the versioned notification transformation work, 
which includes running a weekly meeting (that only one other person 
shows up to) and sending a weekly status email, and does it in a 
ridiculously patient and kind way, but he's also been identifying 
several critical issues late in the release related to the Placement and 
claims in the scheduler work that's going on.


And it's not just doing manual testing, reporting a bug and throwing it 
over the wall - which is a major feat in OpenStack on it's own - but 
also taking the time to write automated functional regression tests to 
exhibit the bugs so when we have a fix we can tell it's actually 
working, plus he's been fixing some on his own also.


So with all that, I just wanted to formally and publicly say thanks to 
gibi for the great work he's doing which often goes overlooked when 
we're crunching toward a deadline.


Couldn't agree more. Thank you Gibi for your hard work and valuable 
contributions over the last cycle and more. Your efforts have not gone 
unnoticed.


All the best,
-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][barbican][freezer][horizon][karbor][keystone][mistral][nova][pack-deb][refstack][solum][storlets][swift][tacker][telemetry][watcher][zaqar] Last days for PTL candidate announ

[Anita Kuno]

On 2017-08-07 03:50 PM, Kendall Nelson wrote:

Hello Everyone :)

A quick reminder that we are in the last days for PTL candidate
announcements.

If you want to stand for PTL, don't delay, follow the instructions at [1]
to make sure the community knows your intentions.

Make sure your candidacy has been submitted to the openstack/election
repository and approved by election officials.

Election statistics[2]:

This means that with approximately 2.5 days left more than 27% of projects
will be deemed leaderless.  In this case the TC will be bound by [3].


I thought that the language in this sentence, that the TC is bound by 
the referenced resolution was a bit of mis-stating the relationship, but 
I thought I would let it pass and that things would work themselves out. 
However having read the language in Emmett's post to the TC reporting 
which programs don't have a self-nominated PTL, I'm motivated to clarify.


The TC is not bound. The TC has agreed to follow a process. The election 
officials are bound, in as much as they are obliged to communicate the 
list of leaderless programs to the TC without delay. The TC is enabled 
by the process, not bound by it.


The TC CAN appoint a leader, they are not obliged to appoint a leader. 
The TC may do other things as well, it depends on the circumstances.


Also to clarify, the election officials serve the TC, not the other way 
around.


I'm not sure how this relationship got confused, if I played a role in 
creating the confusion, I apologize.


Thank you,
Anita.



Thank you,


-Kendall Nelson (diablo_rojo)

[1] http://governance.openstack.org/election/#how-to-submit-your-candidacy

[2] Assuming the open reviews below are validated

   https://review.openstack.org/#/q/is:open+project:openstack/election


[3]
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html





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

[openstack-dev] [nova] Thanks gibi!

[Matt Riedemann]

Apparently we don't have community contributor awards at the PTG, only 
the summit, and seeing as that's several months away now, which is kind 
of an eternity, I wanted to take the time now to thank gibi (Balazs 
Gibizer to his parents) for all the work he's been doing in Nova.


Not only does gibi lead the versioned notification transformation work, 
which includes running a weekly meeting (that only one other person 
shows up to) and sending a weekly status email, and does it in a 
ridiculously patient and kind way, but he's also been identifying 
several critical issues late in the release related to the Placement and 
claims in the scheduler work that's going on.


And it's not just doing manual testing, reporting a bug and throwing it 
over the wall - which is a major feat in OpenStack on it's own - but 
also taking the time to write automated functional regression tests to 
exhibit the bugs so when we have a fix we can tell it's actually 
working, plus he's been fixing some on his own also.


So with all that, I just wanted to formally and publicly say thanks to 
gibi for the great work he's doing which often goes overlooked when 
we're crunching toward a deadline.


--

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] [requirements][masakari] FFE for adding python-masakariclient in global-requirements

[Sam P]

Hi Tony,

For maskari-monitors, earliest we can cut stable/pike is 8/11.
You was mentioned about masakari and related projects in [1].
For python-masakariclient, stable/pike can be cut on 8/11.
However, for maskari I would like to land few changes before cut stable/pike and
hopefully we can cut stable/pike after 8/15 masakari team meeting.

  As I discussed with Matthew[2], In the case, you unfreeze
requirements before 8/15,
 we can block requirements update for masakari till we create the
stable/pike branch.
 Any comments on this plan?

> Looking at masakari-monitors the whole history can be seen on one page so 
> it's clearly very new.
I created it 10 months ago. Original code can be found in [3]. We
split [3] into masakari and masakari-monitors and
did lot of enhancements.


[1] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120922.html
[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-requirements/%23openstack-requirements.2017-08-10.log.html#t2017-08-10T17:11:42
[3] https://github.com/ntt-sic/masakari
--- Regards,
Sampath



On Thu, Aug 10, 2017 at 1:23 AM, Bhor, Dinesh  wrote:
> Hi Tony and all,
>
> Sorry for the delay to reply.
>
> We are planning to create the stable/pike branch soon. I am contacting the 
> PTL Sampath Priyankara(samP) for the exact date.
>
> Thanks and Regards,
> Dinesh Bhor | App. Software Dev. Cnslt.
> dinesh.b...@nttdata.com | nttdata.com/americas
>
>
> -Original Message-
> From: Tony Breeds [mailto:t...@bakeyournoodle.com]
> Sent: Wednesday, August 09, 2017 5:25 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [requirements][masakari] FFE for adding 
> python-masakariclient in global-requirements
>
> On Wed, Aug 09, 2017 at 06:39:52AM +, Bhor, Dinesh wrote:
>> Hello everyone,
>>
>> I would like to ask for the FFE for adding "python-masakariclient" in 
>> global-requirements.
>>
>> Earlier, we were not having "check-requirements" job for masakari-* 
>> projects. At that time, we use to manually add "python-masakariclient" as a 
>> requirement in masakari-monitors project [1].
>> Now we have added "check-requirements" job for masakari-* projects,
>> but we missed to add "python-masakariclient" in global-requirements and now 
>> the bigger issue is it is not possible to manually update the 
>> "python-masakariclient" requirement in masakari-monitors project as the 
>> "gate-masakari-monitors-requirements" requirements job keeps failing on the 
>> patch [1].
>> To resolve this problem permanently, we need to add "python-masakariclient" 
>> library requirement in global-requirements.
>> I have submitted a patch [2] for adding the python-masakariclient in 
>> global-requirements.
>>
>> Please consider my request and grant FFE to solve this problem.
>>
>> [1] https://review.openstack.org/#/c/457491/
>> [2] https://review.openstack.org/#/c/491692/
>
> Are you intending to create a stable/pike branch and perform releases from 
> it?  Looking at masakari-monitors the whole history can be seen on one page 
> so it's clearly very new.
>
> Yours Tony.
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] [heat][infra] Help needed! high gate failure rate

[Mohammed Naser]

On Thu, Aug 10, 2017 at 12:04 PM, Paul Belanger  wrote:
> On Thu, Aug 10, 2017 at 07:22:42PM +0530, Rabi Mishra wrote:
>> On Thu, Aug 10, 2017 at 4:34 PM, Rabi Mishra  wrote:
>>
>> > On Thu, Aug 10, 2017 at 2:51 PM, Ian Wienand  wrote:
>> >
>> >> On 08/10/2017 06:18 PM, Rico Lin wrote:
>> >> > We're facing a high failure rate in Heat's gates [1], four of our gate
>> >> > suffering with fail rate from 6 to near 20% in 14 days. which makes
>> >> most of
>> >> > our patch stuck with the gate.
>> >>
>> >> There have been a confluence of things causing some problems recently.
>> >> The loss of OSIC has distributed more load over everything else, and
>> >> we have seen an increase in job timeouts and intermittent networking
>> >> issues (especially if you're downloading large things from remote
>> >> sites).  There have also been some issues with the mirror in rax-ord
>> >> [1]
>> >>
>> >> > gate-heat-dsvm-functional-convg-mysql-lbaasv2-ubuntu-xenial(19.67%)
>> >> > gate-heat-dsvm-functional-convg-mysql-lbaasv2-non-apache-
>> >> ubuntu-xenia(9.09%)
>> >> > gate-heat-dsvm-functional-orig-mysql-lbaasv2-ubuntu-xenial(8.47%)
>> >> > gate-heat-dsvm-functional-convg-mysql-lbaasv2-py35-ubuntu-xenial(6.00%)
>> >>
>> >> > We still try to find out what's the cause but (IMO,) seems it might be
>> >> some
>> >> > thing wrong with our infra. We need some help from infra team, to know
>> >> if
>> >> > any clue on this failure rate?
>> >>
>> >> The reality is you're just going to have to triage this and be a *lot*
>> >> more specific with issues.
>> >
>> >
>> > One of the issues we see recently is that, many jobs killed mid way
>> > through the tests as the job times out(120 mins).  It seems jobs are many
>> > times scheduled to very slow nodes, where setting up devstack takes more
>> > than 80 mins[1].
>> >
>> > [1] http://logs.openstack.org/49/492149/2/check/gate-heat-dsvm-
>> > functional-orig-mysql-lbaasv2-ubuntu-xenial/03b05dd/console.
>> > html#_2017-08-10_05_55_49_035693
>> >
>> > We download an image from a fedora mirror and it seems to take more than
>> 1hr.
>>
>> http://logs.openstack.org/41/484741/7/check/gate-heat-dsvm-functional-convg-mysql-lbaasv2-py35-ubuntu-xenial/a797010/logs/devstacklog.txt.gz#_2017-08-10_04_13_14_400
>>
>> Probably an issue with the specific mirror or some infra network bandwidth
>> issue. I've submitted a patch to change the mirror to see if that helps.
>>
> Today we mirror both fedora-26[1] and fedora-25 (to be removed shortly). So if
> you want to consider bumping your image for testing, you can fetch it from our
> AFS mirrors.
>
> You can source /etc/ci/mirror_info.sh to get information about things we 
> mirror.
>
> [1] 
> http://mirror.regionone.infracloud-vanilla.openstack.org/fedora/releases/26/CloudImages/x86_64/images/

In order to make the gate happy, I've taken the time to submit this
patch, appreciate if it can be reviewed so we can reduce the churn on
our instances:

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

>>
>> > I find opening an etherpad and going
>> >> through the failures one-by-one helpful (e.g. I keep [2] for centos
>> >> jobs I'm interested in).
>> >>
>> >> Looking at the top of the console.html log you'll have the host and
>> >> provider/region stamped in there.  If it's timeouts or network issues,
>> >> reporting to infra the time, provider and region of failing jobs will
>> >> help.  If it's network issues similar will help.  Finding patterns is
>> >> the first step to understanding what needs fixing.
>> >>
>> >> If it's due to issues with remote transfers, we can look at either
>> >> adding specific things to mirrors (containers, images, packages are
>> >> all things we've added recently) or adding a caching reverse-proxy for
>> >> them ([3],[4] some examples).
>> >>
>> >> Questions in #openstack-infra will usually get a helpful response too
>> >>
>> >> Good luck :)
>> >>
>> >> -i
>> >>
>> >> [1] https://bugs.launchpad.net/openstack-gate/+bug/1708707/
>> >> [2] https://etherpad.openstack.org/p/centos7-dsvm-triage
>> >> [3] https://review.openstack.org/491800
>> >> [4] https://review.openstack.org/491466
>> >>
>> >> 
>> >> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> >> e
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Rabi Misra
>> >
>> >
>>
>>
>> --
>> Regards,
>> Rabi Mishra
>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> 

[openstack-dev] [all][api] POST /api-wg/news

[Chris Dent]

308 Permanent Redirect
Location: /api-sig/news

Greetings OpenStack community,

As with last week, today's meeting started off with continued discussion about 
the Guided Review process that we are trying to create ahead of the Denver PTG. 
elmiko continues to shape the proposal in a review [0]. For the most part we're 
all pretty happy with it.

We then moved on to discussing the API-WG becoming API-SIG. Continued email 
discussion [4] has left us feeling like it's a good idea, so we voted to go for 
it. There were some concerns about how this might impact repository and bug 
tracking names, but we felt that we could leave those questions to be addressed 
when they become problems. Over the next few weeks you may see some changes in 
how things are named, but existing behaviors (making guidelines, sending this 
newsletter, having a weekly IRC meeting) will remain.

On the topic of guidance, there's one new work in progress [5] discouraging the 
use of extensions which add URLs to APIs or change the shape of 
representations. As the comments there indicate, this is a tricky topic when 
functionality is impacted either by policy or by the presence of different 
drivers. We haven't fully decided how we're going to explain these issues, but 
we do want to make sure that it is well known that if you are trying to create 
an interoperable API, optional URIs are a bad idea.

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* Explain, simply, why extensions are bad
  https://review.openstack.org/#/c/491611/

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag "[api]" in the 
subject. In your email, you should include any relevant reviews, links, and comments to 
help guide the discussion of the specific challenge you are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[0] https://review.openstack.org/#/c/487847/
[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] http://lists.openstack.org/pipermail/openstack-sigs/2017-August/35.html
[5] https://review.openstack.org/#/c/491611/


Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
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] [neutron][infra] Functional job failure rate at 100%

[Mooney, Sean K]

From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
Sent: Thursday, August 10, 2017 8:55 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron][infra] Functional job failure rate at 
100%

Good (amazing) job folks. :)

El 10 ago. 2017 9:43, "Thierry Carrez" 
> escribió:
Oh, that's good for us. Should still be fixed, if only so that we can
test properly :)

Kevin Benton wrote:
> This is just the code simulating the conntrack entries that would be
> created by real traffic in a production system, right?
>
> On Wed, Aug 9, 2017 at 11:46 AM, Jakub Libosvar 
> 
> >> wrote:
>
> On 09/08/2017 18:23, Jeremy Stanley wrote:
> > On 2017-08-09 15:29:04 +0200 (+0200), Jakub Libosvar wrote:
> > [...]
> >> Is it possible to switch used image for jenkins machines to use
> >> back the older version? Any other ideas how to deal with the
> >> kernel bug?
> >
> > Making our images use non-current kernel packages isn't trivial, but
[Mooney, Sean K]  so on that it would bre quite trivial to have disk image 
builder install
The linux-image-virtual-hwe-16.04 linux-image-virtual-hwe-16.04-edge to pull in 
a 4.10 or
4.11 kernel respctivly if the default 4.4 is broken. We just need a new dib 
element to install the package
And modify the  nodepool config to include it when it rebuildes the image every 
night. Alternitivly
You can pull a vanilla kernel form 
http://kernel.ubuntu.com/~kernel-ppa/mainline/
Follow the process documented here https://wiki.ubuntu.com/Kernel/MainlineBuilds
If you want to maintain testing with 4.4.x

> > as Thierry points out in his reply this is not just a problem for
> > our CI system. Basically Ubuntu has broken OpenStack (and probably a
> > variety of other uses of conntrack) for a lot of people following
> > kernel updates in 16.04 LTS so the fix needs to happen there
> > regardless. Right now, basically, Ubuntu Xenial is not a good
> > platform to be running OpenStack on until they get the kernel
> > regression addressed.
>
> True. Fortunately, the impact is not that catastrophic for Neutron as it
> might seem on the first look. Not sure about the other projects, though.
> Neutron doesn't create conntrack entries in production code - only in
> testing. That said, agents should work just fine even with the
> kernel bug.

--
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] [tripleo][puppet] Hold off on approving patches until further notice

[Paul Belanger]

On Thu, Aug 10, 2017 at 07:03:32AM -0600, Alex Schultz wrote:
> FYI,
> 
> The gates are hosed for a variety of reasons[0][1] and we can't get
> critical patches merged. Please hold off on rechecking or approving
> anything new until further notice.   We're hoping to get some of the
> fixes for this merged today.  I will send a note when it's OK to merge
> again.
> 
> [0] https://bugs.launchpad.net/tripleo/+bug/1709428
> [1] https://bugs.launchpad.net/tripleo/+bug/1709327
> 
So far, these are the 3 patches we need to land today:

  Exclude networking-bagpipe from dlrn
- https://review.openstack.org/491878

  Disable existing repositories in tripleo-ci
- https://review.openstack.org/492289

  Stop trying to build networking-bagpipe with DLRN
- https://review.openstack.org/492339

These 3 fixes will take care of the large amount of gate resets tripleo is
currently seeing. Like Alex says, please try not to approve / recheck anything
until we land these.

Thanks,
PB

__
OpenStack Development Mailing 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-Infra] citycloud lon1 mirror postmortem

[Paul Belanger]

On Thu, Aug 10, 2017 at 10:34:56PM +1000, Ian Wienand wrote:
> Hi,
> 
> In response to sdague reporting that citycloud jobs were timing out, I
> investigated the mirror, suspecting it was not providing data fast enough.
> 
> There were some 170 htcacheclean jobs running, and the host had a load
> over 100.  I killed all these, but performance was still unacceptable.
> 
> I suspected networking, but since the host was in such a bad state I
> decided to reboot it.  Unfortunately it would get an address from DHCP
> but seemed to have DNS issues ... eventually it would ping but nothing
> else was working.
> 
> nodepool.o.o was placed in the emergency file and I removed lon1 to
> avoid jobs going there.
> 
> I used the citycloud live chat, and Kim helpfully investigated and
> ended up migrating mirror.lon1.citycloud.openstack.org to a new
> compute node.  This appeared to fix things, for us at least.
> 
> nodepool.o.o is removed from the emergency file and original config
> restored.
> 
> With hindsight, clearly the excessive htcacheclean processes were due
> to negative feedback of slow processes due to the network/dns issues
> all starting to bunch up over time.  However, I still think we could
> minimise further issues running it under a lock [1].  Other than that,
> not sure there is much else we can do, I think this was largely an
> upstream issue.
> 
> Cheers,
> 
> -i
> 
> [1] https://review.openstack.org/#/c/492481/
> 
Thanks, I also noticed a job fail to download a package from
mirror.iad.rax.openstack.org. When I SSH'd to the server I too see high load
(6.0+) and multiple htcacheclean processes running. 

I did an audit on the other mirrors and they too had the same, so I killed all
the processes there.  I can confirm the lock patch merged but will keep an eye
on it.

I did notice that mirror.lon1.citycloud.openstack.org wass still slow to react
to shell commands. I still think we have an IO bottleneck some where, possible
the compute host is throttling something.  We should keep an eye on it.

-PB

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[openstack-dev] [murano] murano-dashboard 4.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for murano-dashboard for the end of the Pike
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 Pike release. You are therefore strongly
encouraged to test and validate this tarball!

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

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

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] murano 4.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for murano for the end of the Pike
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 Pike release. You are therefore strongly
encouraged to test and validate this tarball!

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

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

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] [heat][infra] Help needed! high gate failure rate

[Paul Belanger]

On Thu, Aug 10, 2017 at 07:22:42PM +0530, Rabi Mishra wrote:
> On Thu, Aug 10, 2017 at 4:34 PM, Rabi Mishra  wrote:
> 
> > On Thu, Aug 10, 2017 at 2:51 PM, Ian Wienand  wrote:
> >
> >> On 08/10/2017 06:18 PM, Rico Lin wrote:
> >> > We're facing a high failure rate in Heat's gates [1], four of our gate
> >> > suffering with fail rate from 6 to near 20% in 14 days. which makes
> >> most of
> >> > our patch stuck with the gate.
> >>
> >> There have been a confluence of things causing some problems recently.
> >> The loss of OSIC has distributed more load over everything else, and
> >> we have seen an increase in job timeouts and intermittent networking
> >> issues (especially if you're downloading large things from remote
> >> sites).  There have also been some issues with the mirror in rax-ord
> >> [1]
> >>
> >> > gate-heat-dsvm-functional-convg-mysql-lbaasv2-ubuntu-xenial(19.67%)
> >> > gate-heat-dsvm-functional-convg-mysql-lbaasv2-non-apache-
> >> ubuntu-xenia(9.09%)
> >> > gate-heat-dsvm-functional-orig-mysql-lbaasv2-ubuntu-xenial(8.47%)
> >> > gate-heat-dsvm-functional-convg-mysql-lbaasv2-py35-ubuntu-xenial(6.00%)
> >>
> >> > We still try to find out what's the cause but (IMO,) seems it might be
> >> some
> >> > thing wrong with our infra. We need some help from infra team, to know
> >> if
> >> > any clue on this failure rate?
> >>
> >> The reality is you're just going to have to triage this and be a *lot*
> >> more specific with issues.
> >
> >
> > One of the issues we see recently is that, many jobs killed mid way
> > through the tests as the job times out(120 mins).  It seems jobs are many
> > times scheduled to very slow nodes, where setting up devstack takes more
> > than 80 mins[1].
> >
> > [1] http://logs.openstack.org/49/492149/2/check/gate-heat-dsvm-
> > functional-orig-mysql-lbaasv2-ubuntu-xenial/03b05dd/console.
> > html#_2017-08-10_05_55_49_035693
> >
> > We download an image from a fedora mirror and it seems to take more than
> 1hr.
> 
> http://logs.openstack.org/41/484741/7/check/gate-heat-dsvm-functional-convg-mysql-lbaasv2-py35-ubuntu-xenial/a797010/logs/devstacklog.txt.gz#_2017-08-10_04_13_14_400
> 
> Probably an issue with the specific mirror or some infra network bandwidth
> issue. I've submitted a patch to change the mirror to see if that helps.
> 
Today we mirror both fedora-26[1] and fedora-25 (to be removed shortly). So if
you want to consider bumping your image for testing, you can fetch it from our
AFS mirrors.

You can source /etc/ci/mirror_info.sh to get information about things we mirror.

[1] 
http://mirror.regionone.infracloud-vanilla.openstack.org/fedora/releases/26/CloudImages/x86_64/images/
> 
> > I find opening an etherpad and going
> >> through the failures one-by-one helpful (e.g. I keep [2] for centos
> >> jobs I'm interested in).
> >>
> >> Looking at the top of the console.html log you'll have the host and
> >> provider/region stamped in there.  If it's timeouts or network issues,
> >> reporting to infra the time, provider and region of failing jobs will
> >> help.  If it's network issues similar will help.  Finding patterns is
> >> the first step to understanding what needs fixing.
> >>
> >> If it's due to issues with remote transfers, we can look at either
> >> adding specific things to mirrors (containers, images, packages are
> >> all things we've added recently) or adding a caching reverse-proxy for
> >> them ([3],[4] some examples).
> >>
> >> Questions in #openstack-infra will usually get a helpful response too
> >>
> >> Good luck :)
> >>
> >> -i
> >>
> >> [1] https://bugs.launchpad.net/openstack-gate/+bug/1708707/
> >> [2] https://etherpad.openstack.org/p/centos7-dsvm-triage
> >> [3] https://review.openstack.org/491800
> >> [4] https://review.openstack.org/491466
> >>
> >> 
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
> >> e
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> > --
> > Regards,
> > Rabi Misra
> >
> >
> 
> 
> -- 
> Regards,
> Rabi Mishra

> __
> OpenStack Development Mailing 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] [freezer] freezer-dr 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for freezer-dr for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/freezer-dr/

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

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

http://git.openstack.org/cgit/openstack/freezer-dr/log/?h=stable/pike

Release notes for freezer-dr can be found at:

http://docs.openstack.org/releasenotes/freezer-dr/




__
OpenStack Development Mailing 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] [freezer] freezer 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/freezer/

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

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

http://git.openstack.org/cgit/openstack/freezer/log/?h=stable/pike

Release notes for freezer can be found at:

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




__
OpenStack Development Mailing 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] [freezer] freezer-api 5.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for freezer-api for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/freezer-api/

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

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

http://git.openstack.org/cgit/openstack/freezer-api/log/?h=stable/pike

Release notes for freezer-api can be found at:

http://docs.openstack.org/releasenotes/freezer-api/




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

Re: [openstack-dev] [mistral][core] Proposing Andras Kovi to the Mistral core team

[Gershenzon, Michal (Nokia - IL/Kfar Sava)]

+1 from me. Andras will be a great addition to the core team.


 Original Message 
From: Lingxian Kong 
Sent: Thursday, August 10, 2017 02:59 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [mistral][core] Proposing Andras Kovi to the 
Mistral core team

+1, It will be great to have him!


Cheers,
Lingxian Kong (Larry)

On Thu, Aug 10, 2017 at 5:34 PM, Renat Akhmerov 
> wrote:
Hi,

I’d like to propose Andras Kovi to the Mistral core team.

The current statistics of Andras can be seen at [1].
Andras has been contributing for about 1.5 years and in Pike he increased his 
activity significantly, primarily reviewing. His reviews are always thorough 
and insightful. He cares about code quality. He knows both OpenStack ecosystem 
and Mistral architecture and codebase well. Adding Andras to the core team 
would be also very useful for us because he is a very active user of Mistral, 
he implemented or participated in implementation of lots of Nokia CBAM use 
cases based on Mistral.
Andras also gave an excellent presentation about Mistral performance in Boston, 
[2]. I’d really recommend to watch it if you work with Mistral as a contributor 
or as a user.
Speaking less formally, Andras is a very good guy, deep thinker with a great 
experience in software programming. Every time I have a chance to meet him 
personally it’s a lot of fun to talk to him and learn from him.

So I’m asking you to support me in this promotion. I really believe that Andras 
will be an invaluable addition to our team.

[1] http://stackalytics.com/?module=mistral-group_id=akovi
[2] https://www.openstack.org/videos/boston-2017/mistral-performance-in-numbers

Thanks

Renat Akhmerov
@Nokia

__
OpenStack Development Mailing 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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Ian Y. Choi]

Akihiro Motoki wrote on 8/10/2017 7:22 PM:

Tony,

Thanks for taking care.






i18n   I18n

At now, i18n repo is a part of governance but this is a project which
has no need to cut a release,
so it always follows the master branch of the requirements repo.
It is not a blocker for opening the master branch in the requirements repo.




Right - i18n repository has I18n contributor guide, translation 
glossary, and useful scripts with translate.openstack.org

which all do not need to have stable branches to be maintained.

I am not pretty sure but it seems that some project repositories which 
are affected by requirements.txt in stable branches

need to follow "stable:follows-policy" [1] for official projects?

And also thanks a lot - since I also keep on eyes for having stable 
branches from translation target repositories in Pike release cycle [2].



With many thanks,

/Ian

[1] 
https://governance.openstack.org/tc/reference/tags/stable_follows-policy.html

[2] http://git.openstack.org/cgit/openstack/releases/tree/PROCESS.rst#n214

__
OpenStack Development Mailing 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] possible race condition with nova instance and neutron ports

[Saverio Proto]

Thank you.
It worked with the new settings. Now the instances are correctly in
ERROR state of network is not functional.

To solve the performance problem and have 0 instances in ERROR state I
had to enable the neutron-rootwrap-daemon. Without it the dhcp agents
were not fast enough to consume the rabbit queues.

thanks

Saverio


On 09/08/17 14:40, Sławomir Kapłoński wrote:
> With such settings nova is not waiting for info from neutron and that is why 
> Your instances starting without network ready.
> If You will change this timeout to some value higher than 0 then instance 
> will be paused and nova will wait for info from neutron that port is active 
> (You should also check credentials config in neutron server)
> If You will set also vif_plugging_is_fatal=True then nova will put instance 
> in ERROR state if port will not be active after timeout time.
> 


-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
OpenStack Development Mailing 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] [monasca] Mid-cycle project team meeting

[witold.be...@est.fujitsu.com]

Hello everyone,

as discussed yesterday in the Team Meeting there will be no Monasca planning 
session during the PTG. Instead we will hold a video conference one week later. 
The goal is to discuss the priorities and coordinate the work in the next 
release cycle. Please mark the dates which would work for you in the attached 
doodle [1]. We would like to meet from 2pm to 6pm UTC on one or two days 
depending on how full the agenda will be.
After the dates are set I will create an etherpad where we can work on agenda.


Best greetings
Witek

[1] http://doodle.com/poll/bca7tsz484faefn8

__
OpenStack Development Mailing 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] [docs] Doc meeting Thursday

[Alexandra Settle]

Reminder: Docs meeting as normally scheduled in #openstack-meeting today at 
16:00UTC.

Agenda: https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Thanks,

Alex

From: Alexandra Settle 
Date: Tuesday, August 8, 2017 at 11:13 AM
To: openstack-docs , "OpenStack Development 
Mailing List (not for usage questions)" 
Subject: [docs] Doc meeting Thursday

Hi everyone,

With the upcoming PTG and all of the big changes with the migration, I will be 
hosting the docs meeting as normally scheduled in #openstack-meeting on 
Thursday, 10th of August at 16:00UTC.

I will send out the agenda closer to the day. I *strongly* urge all to attend. 
I know it’s not the best time in the world, but we’re closing in on the first 
release for the doc team with the new release format.

The meeting chair will be me – although I’ll be juggling my regular conflict at 
the same time! Hope you can all make it :)

Thanks,

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] [openstack][oslo.policy] A new Keystone-Oslo hook for external PDP

[Davanum Srinivas]

Ruan,

The hook is the easy part, having the data you need for making the
decision is harder.

-- Dims

On Thu, Aug 10, 2017 at 10:51 AM,   wrote:
> Dims,
> There is a similar prototype  https://review.openstack.org/#/c/237521/.
> Our idea is to provide a more generic one instead of Fortress.
> Ruan
>
>
> -Original Message-
> From: Davanum Srinivas [mailto:dava...@gmail.com]
> Sent: jeudi 10 août 2017 16:32
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: DUVAL Thomas OBS/OAB
> Subject: Re: [openstack-dev] [openstack][oslo.policy] A new Keystone-Oslo 
> hook for external PDP
>
> Ruan,
>
> Have you prototyped to see if you have all the information you need is 
> available in the context (or can be gathered from Nova)?
> ( quickly check what the existing HttpCheck mechanism sends over the wire )
>
> Thanks,
> Dims
>
> On Thu, Aug 10, 2017 at 10:17 AM,   wrote:
>> Hello,
>>
>> We would like to have an external and centralized security policy
>> engine
>> (PDP) that can pilot both OpenStack and SDN controllers. For this
>> reason, we have developed and upstreamed a hook for the new
>> OpenDaylight release Carbon
>> (https://git.opendaylight.org/gerrit/#/c/46146/), and we’d like to develop a 
>> similar hook for the OpenStack/Oslo-policy.
>>
>>
>>
>> A blueprint was submitted to
>> https://blueprints.launchpad.net/pbr/+spec/external-pdp-for-oslo-polic
>> y, and the spec is submitted to https://review.openstack.org/#/c/492543/.
>>
>> We hope that this topic can be discussed in the next oslo meeting.
>>
>> Thank you,
>>
>> Ruan HE
>>
>>
>>
>> __
>> ___
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>> que les pieces jointes. Les messages electroniques etant susceptibles
>> d'alteration, Orange decline toute responsabilite si ce message a ete
>> altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not
>> be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have
>> been modified, changed or falsified.
>> Thank you.
>>
>>
>> __
>>  OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] [openstack][oslo.policy] A new Keystone-Oslo hook for external PDP

[ruan.he]

Dims,
There is a similar prototype  https://review.openstack.org/#/c/237521/. 
Our idea is to provide a more generic one instead of Fortress. 
Ruan


-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: jeudi 10 août 2017 16:32
To: OpenStack Development Mailing List (not for usage questions)
Cc: DUVAL Thomas OBS/OAB
Subject: Re: [openstack-dev] [openstack][oslo.policy] A new Keystone-Oslo hook 
for external PDP

Ruan,

Have you prototyped to see if you have all the information you need is 
available in the context (or can be gathered from Nova)?
( quickly check what the existing HttpCheck mechanism sends over the wire )

Thanks,
Dims

On Thu, Aug 10, 2017 at 10:17 AM,   wrote:
> Hello,
>
> We would like to have an external and centralized security policy 
> engine
> (PDP) that can pilot both OpenStack and SDN controllers. For this 
> reason, we have developed and upstreamed a hook for the new 
> OpenDaylight release Carbon 
> (https://git.opendaylight.org/gerrit/#/c/46146/), and we’d like to develop a 
> similar hook for the OpenStack/Oslo-policy.
>
>
>
> A blueprint was submitted to
> https://blueprints.launchpad.net/pbr/+spec/external-pdp-for-oslo-polic
> y, and the spec is submitted to https://review.openstack.org/#/c/492543/.
>
> We hope that this topic can be discussed in the next oslo meeting.
>
> Thank you,
>
> Ruan HE
>
>
>
> __
> ___
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi 
> que les pieces jointes. Les messages electroniques etant susceptibles 
> d'alteration, Orange decline toute responsabilite si ce message a ete 
> altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not 
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
> Thank you.
>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[Openstack] How to send an email using openstack

[Sihem Chouache]

Hi all,

I need your help on how to send an email using openstack api.

Thanks and Regards
[cid:image001.gif@01D1319B.3054A2C0]

Sihem Chouache
Conseillère - Spécialiste en automatisation et orchestration - Expert CloudForms

Direction Infonuagique et technologies émergentes


   Montréal

   514 787-1313 ext 4029



Faites bonne impression et imprimez seulement au besoin!

Ce courriel est confidentiel, peut être protégé par le secret professionnel et 
est adressé exclusivement au destinataire. Il est strictement interdit à toute 
autre personne de diffuser, distribuer ou reproduire ce message. Si vous l'avez 
reçu par erreur, veuillez immédiatement le détruire et aviser l'expéditeur. 
Merci.



___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [openstack][oslo.policy] A new Keystone-Oslo hook for external PDP

[Davanum Srinivas]

Ruan,

Have you prototyped to see if you have all the information you need is
available in the context (or can be gathered from Nova)?
( quickly check what the existing HttpCheck mechanism sends over the wire )

Thanks,
Dims

On Thu, Aug 10, 2017 at 10:17 AM,   wrote:
> Hello,
>
> We would like to have an external and centralized security policy engine
> (PDP) that can pilot both OpenStack and SDN controllers. For this reason, we
> have developed and upstreamed a hook for the new OpenDaylight release Carbon
> (https://git.opendaylight.org/gerrit/#/c/46146/), and we’d like to develop a
> similar hook for the OpenStack/Oslo-policy.
>
>
>
> A blueprint was submitted to
> https://blueprints.launchpad.net/pbr/+spec/external-pdp-for-oslo-policy, and
> the spec is submitted to https://review.openstack.org/#/c/492543/.
>
> We hope that this topic can be discussed in the next oslo meeting.
>
> Thank you,
>
> Ruan HE
>
>
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

[openstack-dev] [Tripleo] FFE to add Dell EMC Cinder and Manila Drivers to Triple-o

[Rajini.Karthik]

I would like to request a feature freeze exception to Dell EMC storage products 
support for  Triple-o. This work is done and pending verification Jenkins, 
there seems to be some gate issues that is delaying the process. The 
puppet-cinder and puppet-manila work is already merged.



Pending reviews



Isilon Driver

https://review.openstack.org/49

https://review.openstack.org/488896



Unity Cinder and Manila Driver

https://review.openstack.org/487599

https://review.openstack.org/490581

https://review.openstack.org/491078



VMAX Cinder and Manila Driver

https://review.openstack.org/489393

https://review.openstack.org/489624

https://review.openstack.org/490949

https://review.openstack.org/491094



VNX Driver

https://review.openstack.org/490642

https://review.openstack.org/491088



Thank you and appreciate your attention,

Rajini

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

[openstack-dev] [openstack][oslo.policy] A new Keystone-Oslo hook for external PDP

[ruan.he]

Hello,
We would like to have an external and centralized security policy engine (PDP) 
that can pilot both OpenStack and SDN controllers. For this reason, we have 
developed and upstreamed a hook for the new OpenDaylight release Carbon 
(https://git.opendaylight.org/gerrit/#/c/46146/), and we'd like to develop a 
similar hook for the OpenStack/Oslo-policy.

A blueprint was submitted to 
https://blueprints.launchpad.net/pbr/+spec/external-pdp-for-oslo-policy, and 
the spec is submitted to https://review.openstack.org/#/c/492543/.
We hope that this topic can be discussed in the next oslo meeting.
Thank you,
Ruan HE


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Matthew Treinish]

On Thu, Aug 10, 2017 at 03:46:32PM +1000, Tony Breeds wrote:
> 
> Hi All,
> In an effort to qualify which projects are likley to be affected if
> when we open the requirements repo I generated a list of all repos that:
> 
> 1. Subscribe to requirements management
> 2. Do not already have a stable/pike branch
> 3. Do not follow the cycle-with-milestones, cycle-trailing or
>independent release models
> 4. Are not a 'branchless' project (tempest or tempest-plugin)
> 
> These repos I believe *should* have a stable/pike branch or will see
> problems when we open openstack/requirements.  Those issues were
> described in [1]
> 
> It turns out close to 1/3rd of projects that subscribe to requirements
> management are not ready for us to re-open for master.  So we need you
> help to get that number down to a much more acceptable number.
> 
> The good news is it's pretty easy to fix this with the cool tools and
> workflow in the releases repo[2].  I suspect that the 'service' will
> take care of themselves, and the horizon-plugins are waiting to horizon
> to cut RC1.
> 
> Repos with type: horizon-plugin
> ironic-ui  ironic  
> manila-ui  manila  
> monasca-ui monasca 
> neutron-fwaas-dashboardneutron 
> solum-dashboardsolum   
> tacker-horizon tacker  
> watcher-dashboard  watcher 
> zun-ui zun 
> 
> Repos with type: other
> python-openstackclient OpenStackClient 
> patroleQuality Assurance

Fwiw, patrole is also a tempest plugin. [1] So it should also fall into the
branchless category and you don't need to worry about it branching before
unfreezing requirements.

-Matt Treinish

[1] 
https://github.com/openstack/patrole/blob/master/README.rst#release-versioning

> heat-agentsheat
> ironic-inspector   ironic  
> ironic-python-agentironic  
> kuryr-kubernetes   kuryr   
> monasca-common monasca 
> monasca-notification   monasca 
> monasca-persister  monasca 
> monasca-transform  monasca 
> 
> Repos with type: service
> ironic ironic  
> monasca-apimonasca 
> monasca-log-apimonasca 
> swift  swift   
> tricircle  tricircle   
> vitragevitrage 
> watcherwatcher 
> zunzun
> 
> Those are the easy items.
> 
> The following repos don't seem to use the openstack/releases repo so I
> have less information there.
> 
> i18n   I18n
> almanach   
> blazar 
> blazar-nova
> compute-hyperv 
> ekko   
> gce-api
> glare  
> ironic-staging-drivers 
> kosmos 
> masakari   
> masakari-monitors  
> mixmatch   
> mogan  
> nemesis
> networking-dpm 
> networking-fujitsu 
> networking-generic-switch  
> networking-l2gw
> networking-powervm 
> neutron-vpnaas   

Re: [openstack-dev] [heat][infra] Help needed! high gate failure rate

[Rabi Mishra]

On Thu, Aug 10, 2017 at 4:34 PM, Rabi Mishra  wrote:

> On Thu, Aug 10, 2017 at 2:51 PM, Ian Wienand  wrote:
>
>> On 08/10/2017 06:18 PM, Rico Lin wrote:
>> > We're facing a high failure rate in Heat's gates [1], four of our gate
>> > suffering with fail rate from 6 to near 20% in 14 days. which makes
>> most of
>> > our patch stuck with the gate.
>>
>> There have been a confluence of things causing some problems recently.
>> The loss of OSIC has distributed more load over everything else, and
>> we have seen an increase in job timeouts and intermittent networking
>> issues (especially if you're downloading large things from remote
>> sites).  There have also been some issues with the mirror in rax-ord
>> [1]
>>
>> > gate-heat-dsvm-functional-convg-mysql-lbaasv2-ubuntu-xenial(19.67%)
>> > gate-heat-dsvm-functional-convg-mysql-lbaasv2-non-apache-
>> ubuntu-xenia(9.09%)
>> > gate-heat-dsvm-functional-orig-mysql-lbaasv2-ubuntu-xenial(8.47%)
>> > gate-heat-dsvm-functional-convg-mysql-lbaasv2-py35-ubuntu-xenial(6.00%)
>>
>> > We still try to find out what's the cause but (IMO,) seems it might be
>> some
>> > thing wrong with our infra. We need some help from infra team, to know
>> if
>> > any clue on this failure rate?
>>
>> The reality is you're just going to have to triage this and be a *lot*
>> more specific with issues.
>
>
> One of the issues we see recently is that, many jobs killed mid way
> through the tests as the job times out(120 mins).  It seems jobs are many
> times scheduled to very slow nodes, where setting up devstack takes more
> than 80 mins[1].
>
> [1] http://logs.openstack.org/49/492149/2/check/gate-heat-dsvm-
> functional-orig-mysql-lbaasv2-ubuntu-xenial/03b05dd/console.
> html#_2017-08-10_05_55_49_035693
>
> We download an image from a fedora mirror and it seems to take more than
1hr.

http://logs.openstack.org/41/484741/7/check/gate-heat-dsvm-functional-convg-mysql-lbaasv2-py35-ubuntu-xenial/a797010/logs/devstacklog.txt.gz#_2017-08-10_04_13_14_400

Probably an issue with the specific mirror or some infra network bandwidth
issue. I've submitted a patch to change the mirror to see if that helps.


> I find opening an etherpad and going
>> through the failures one-by-one helpful (e.g. I keep [2] for centos
>> jobs I'm interested in).
>>
>> Looking at the top of the console.html log you'll have the host and
>> provider/region stamped in there.  If it's timeouts or network issues,
>> reporting to infra the time, provider and region of failing jobs will
>> help.  If it's network issues similar will help.  Finding patterns is
>> the first step to understanding what needs fixing.
>>
>> If it's due to issues with remote transfers, we can look at either
>> adding specific things to mirrors (containers, images, packages are
>> all things we've added recently) or adding a caching reverse-proxy for
>> them ([3],[4] some examples).
>>
>> Questions in #openstack-infra will usually get a helpful response too
>>
>> Good luck :)
>>
>> -i
>>
>> [1] https://bugs.launchpad.net/openstack-gate/+bug/1708707/
>> [2] https://etherpad.openstack.org/p/centos7-dsvm-triage
>> [3] https://review.openstack.org/491800
>> [4] https://review.openstack.org/491466
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Regards,
> Rabi Misra
>
>


-- 
Regards,
Rabi Mishra
__
OpenStack Development Mailing 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] [openstack-dev] package gluster-swift with Openstack swift repository

[Haïkel]

2017-08-10 9:52 GMT+02:00 Venkata R Edara :
> Hello All,
>
> we are from Red Hat and we have product called Gluster which is distributed
> file system. we have integrated Gluster with openstack-swift , the product
> is called
>
> gluster-swift . gluster-swift allows users to have SWIFT/S3 APIs with
> Gluster filesystem as back-end. we did re-base of gluster-swift with
> openstack-swift Newton release.
>
> As gluster-swift is dependent on openstack-swift we would like to have it
> packaged in openstack-swift newton repository.
>
> Is it possible to package gluster-swift project in openstack repository?.
>
> we would like to know the process of packaging with openstack repo if
> openstack community agrees for that.
>
> -Thanks
>
> Venkata R Edara.
>
>

Hi,

AFAIK, shipping binary packages is the responsibility of downstream
distributions of OpenStack, though
there are efforts to collaborate on packaging within OpenStack.
I'm one of the RDO Release Engineer, RDO community would be happy to
help you packaging gluster-swift.
Please contact the RDO mailing list or join RDO weekly irc meetings.

Regards,
H.


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

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [sahara] No meeting today

[Telles Nobrega]

Sorry for the last minute notice, but we are not having Sahara team meeting
today.

Thanks
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I 

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
__
OpenStack Development Mailing 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] package gluster-swift with Openstack swift repository

[Haïkel]

2017-08-10 9:52 GMT+02:00 Venkata R Edara :
> Hello All,
>
> we are from Red Hat and we have product called Gluster which is distributed
> file system. we have integrated Gluster with openstack-swift , the product
> is called
>
> gluster-swift . gluster-swift allows users to have SWIFT/S3 APIs with
> Gluster filesystem as back-end. we did re-base of gluster-swift with
> openstack-swift Newton release.
>
> As gluster-swift is dependent on openstack-swift we would like to have it
> packaged in openstack-swift newton repository.
>
> Is it possible to package gluster-swift project in openstack repository?.
>
> we would like to know the process of packaging with openstack repo if
> openstack community agrees for that.
>
> -Thanks
>
> Venkata R Edara.
>
>

Hi,

AFAIK, shipping binary packages is the responsibility of downstream
distributions of OpenStack, though
there are efforts to collaborate on packaging within OpenStack.
I'm one of the RDO Release Engineer, RDO community would be happy to
help you packaging gluster-swift.
Please contact the RDO mailing list or join RDO weekly irc meetings.

Regards,
H.


> __
> OpenStack Development Mailing 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-operators] [OpenStack-docs] [doc] Operations Guide removal

[Doug Hellmann]

Excerpts from Morgenstern, Chad's message of 2017-08-10 13:01:47 +:
> I tried to convert all docs to rst using pandoc as the following example shows
> pandoc -f docbook -t rst -s section_cinder-deployment-choices.xml -o 
> section_cinder-deployment-choices.rst
> 
> There were no errors thrown, however we are missing things such as section 
> headers, and the internal links did not convert either.
> 
> Please advise how to address this issue?

Yuki Kasuya is also working on this (see the thread "Operations Guide
removal" on this list. Maybe you can collaborate?

Doug

> 
> P.S.
> By way of example: 
> 
> 
> For example, in the rst doc these are this is what we have
> debian@debian-1:~/openstack-repo/openstack-deploy-ops-guide/cinder$ egrep -B 
> 1 "^\*\*|^\-\-|^==" section_cinder-deployment-choices.rst | egrep -v '^-'  | 
> grep -v "^$"
> Theory of Operation & Deployment Choices
> 
> **Cinder Backends and Storage Virtual Machines.**
> **Cinder volumes and FlexVol volumes.**
> **Cinder volume representation within a FlexVol volume.**
> **Cinder Scheduling and resource pool selection.**
> **Cinder snapshots versus NetApp Snapshots.**
> **E-Series snapshots.**
> **CDOT and 7-mode consistency groups.**
> **E-Series consistency groups.**
> **SANtricity Web Services Proxy.**
> **FAS.**
> **E-Series.**
> **iSCSI.**
> **NFS.**
> **Volume Groups.**
> **Dynamic Disk Pools (DDP).**
> **Options.**
> **Setup.**
> **Filer Side Setup.**
> **OpenStack Setup.**
> **Data ONTAP Thin Provisioning.**
> **E-Series Thin Provisioning.**
> **Establishing an iSCSI Session.**
> **iSCSI Session Scope.**
> **Configuration Options.**
> 
> Where as in the original xml file:
> debian@debian-1:~/openstack-repo/openstack-deploy-ops-guide/cinder$ grep -i 
> title section_cinder-deployment-choices.xml
> Theory of Operation  Deployment Choices
> Construct Mappings between Cinder and Data ONTAP
> Cinder Backends and Storage Virtual Machines
> Cinder volumes and FlexVol volumes
> Cinder volume representation within a FlexVol 
> volume
> Cinder Scheduling and resource pool selection
> Cinder snapshots versus NetApp Snapshots
> E-Series snapshots
> CDOT and 7-mode consistency groups
> E-Series consistency groups
> SANtricity Web 
> Services Proxy
> SANtricity Web 
> Services Proxy
> Mitaka Support
> Recommendation
> Deployment Choice: FAS vs E-Series
> FAS
> E-Series
> Deployment Choice: Clustered Data ONTAP vs Data ONTAP 
> operating in 7-Mode
> Recommendation
> Deployment Choice: NFS versus iSCSI
> iSCSI
> NFS
> Recommendation
> Recommendation
> Deployment Choice: Volume Groups vs Dynamic Disk Pools 
> (E-Series)
> Volume Groups
> Dynamic Disk Pools (DDP)
> Recommendation
> Deployment Choice: NFS Security
> Options
>   Setup
>   Filer Side Setup
>   OpenStack Setup
> Fibre Channel Switch Fabric With Cinder
> Using Cinder Volume Types to Create a Storage Service 
> Catalog
> Over-Subscription and Thin-Provisioning
>   Data ONTAP Thin Provisioning
>   E-Series Thin Provisioning
> Unidirectional CHAP Authentication
>   Establishing an iSCSI Session
>   iSCSI Session Scope
>   Configuration Options
> 
> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com] 
> Sent: Thursday, August 10, 2017 8:37 AM
> To: openstack-operators 
> Subject: Re: [Openstack-operators] [OpenStack-docs] [doc] Operations Guide 
> removal
> 
> Excerpts from Yuki Kasuya's message of 2017-08-10 17:09:48 +0900:
> 
> > 
> > I tried to convert all docs under ops-guide dir using pandoc. Like 
> > below, toctree,term and some directives doesn't work after converting.
> > But, at glance, almost fine after converting.
> > If you don't mind, I'll able to create wiki pages of ops-guide.
> > 
> > xxx@devstack02:~/work/openstack-manuals/doc/ops-guide/source$ pandoc 
> > index.rst -t mediawiki -o index .wiki
> > pandoc: ignoring unknown directive: toctree "source" (line 58, column 
> > 1)
> > pandoc: ignoring unknown role :term: in "source" (line 20, column 13)
> > pandoc: ignoring unknown role :term: in "source" (line 19, column 59)
> 
> It should be safe to ignore the toctree directives. If you want to keep the 
> same structure between the wiki pages and the original source document, you 
> might want to replace those with lists of links.
> 
> The term role automatically links to the glossary. As long as the text 
> highlighted by the role is present in the output, it is fine to ignore that 
> warning, too.
> 
> Doug
> 
> 

Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[joehuang]

Features for tricircle pike has been freezed, and 
no exception was asked until now, as you
proposed, If neutron can have branch this
week, we can cut branch earlier.

Thank you, TTX.


From: Thierry Carrez [thie...@openstack.org]
Sent: 10 August 2017 20:39
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality 
Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst...

joehuang wrote:
> Tricircle plans to cut stable/pike branch on August 22nd, it has dependency 
> on Neutron stable/pike creation.

That sounds a bit late to create your release branch. It doesn't give
you a lot of time to react to critical issues discovered in that
release, as August 24 is the final date to submit new releases for
inclusion before Pike is formally declared released.

My advice would be to do a X.Y.0 release as soon as you can freeze
features (neutron should have their branch this week), and have some
time to produce a X.Y.1 bugfix release if you detect critical issues in
testing.

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

[Openstack-operators] [OpenStack-docs] [doc] Operations Guide removal

[Morgenstern, Chad]

I tried to convert all docs to rst using pandoc as the following example shows
pandoc -f docbook -t rst -s section_cinder-deployment-choices.xml -o 
section_cinder-deployment-choices.rst

There were no errors thrown, however we are missing things such as section 
headers, and the internal links did not convert either.

Please advise how to address this issue?

P.S.
By way of example: 


For example, in the rst doc these are this is what we have
debian@debian-1:~/openstack-repo/openstack-deploy-ops-guide/cinder$ egrep -B 1 
"^\*\*|^\-\-|^==" section_cinder-deployment-choices.rst | egrep -v '^-'  | grep 
-v "^$"
Theory of Operation & Deployment Choices

**Cinder Backends and Storage Virtual Machines.**
**Cinder volumes and FlexVol volumes.**
**Cinder volume representation within a FlexVol volume.**
**Cinder Scheduling and resource pool selection.**
**Cinder snapshots versus NetApp Snapshots.**
**E-Series snapshots.**
**CDOT and 7-mode consistency groups.**
**E-Series consistency groups.**
**SANtricity Web Services Proxy.**
**FAS.**
**E-Series.**
**iSCSI.**
**NFS.**
**Volume Groups.**
**Dynamic Disk Pools (DDP).**
**Options.**
**Setup.**
**Filer Side Setup.**
**OpenStack Setup.**
**Data ONTAP Thin Provisioning.**
**E-Series Thin Provisioning.**
**Establishing an iSCSI Session.**
**iSCSI Session Scope.**
**Configuration Options.**

Where as in the original xml file:
debian@debian-1:~/openstack-repo/openstack-deploy-ops-guide/cinder$ grep -i 
title section_cinder-deployment-choices.xml
Theory of Operation  Deployment Choices
Construct Mappings between Cinder and Data ONTAP
Cinder Backends and Storage Virtual Machines
Cinder volumes and FlexVol volumes
Cinder volume representation within a FlexVol volume
Cinder Scheduling and resource pool selection
Cinder snapshots versus NetApp Snapshots
E-Series snapshots
CDOT and 7-mode consistency groups
E-Series consistency groups
SANtricity Web 
Services Proxy
SANtricity Web 
Services Proxy
Mitaka Support
Recommendation
Deployment Choice: FAS vs E-Series
FAS
E-Series
Deployment Choice: Clustered Data ONTAP vs Data ONTAP operating 
in 7-Mode
Recommendation
Deployment Choice: NFS versus iSCSI
iSCSI
NFS
Recommendation
Recommendation
Deployment Choice: Volume Groups vs Dynamic Disk Pools 
(E-Series)
Volume Groups
Dynamic Disk Pools (DDP)
Recommendation
Deployment Choice: NFS Security
Options
  Setup
  Filer Side Setup
  OpenStack Setup
Fibre Channel Switch Fabric With Cinder
Using Cinder Volume Types to Create a Storage Service 
Catalog
Over-Subscription and Thin-Provisioning
  Data ONTAP Thin Provisioning
  E-Series Thin Provisioning
Unidirectional CHAP Authentication
  Establishing an iSCSI Session
  iSCSI Session Scope
  Configuration Options

-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com] 
Sent: Thursday, August 10, 2017 8:37 AM
To: openstack-operators 
Subject: Re: [Openstack-operators] [OpenStack-docs] [doc] Operations Guide 
removal

Excerpts from Yuki Kasuya's message of 2017-08-10 17:09:48 +0900:

> 
> I tried to convert all docs under ops-guide dir using pandoc. Like 
> below, toctree,term and some directives doesn't work after converting.
> But, at glance, almost fine after converting.
> If you don't mind, I'll able to create wiki pages of ops-guide.
> 
> xxx@devstack02:~/work/openstack-manuals/doc/ops-guide/source$ pandoc 
> index.rst -t mediawiki -o index .wiki
> pandoc: ignoring unknown directive: toctree "source" (line 58, column 
> 1)
> pandoc: ignoring unknown role :term: in "source" (line 20, column 13)
> pandoc: ignoring unknown role :term: in "source" (line 19, column 59)

It should be safe to ignore the toctree directives. If you want to keep the 
same structure between the wiki pages and the original source document, you 
might want to replace those with lists of links.

The term role automatically links to the glossary. As long as the text 
highlighted by the role is present in the output, it is fine to ignore that 
warning, too.

Doug

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [heat][infra] Help needed! high gate failure rate

[Rico Lin]

> The reality is you're just going to have to triage this and be a *lot*
> more specific with issues.  I find opening an etherpad and going
> through the failures one-by-one helpful (e.g. I keep [2] for centos
> jobs I'm interested in).
>
> Looking at the top of the console.html log you'll have the host and
> provider/region stamped in there.  If it's timeouts or network issues,
> reporting to infra the time, provider and region of failing jobs will
> help.  If it's network issues similar will help.  Finding patterns is
> the first step to understanding what needs fixing.
>
Here [1] I collect some fail records from gate
As we can tell, most of environments set-up becomes really slow and failed
at some point with time out error.
In [1] I collect information for failed node. Hope you can find any clue
from it.


[1] https://etherpad.openstack.org/p/heat-gate-fail-2017-08

> If it's due to issues with remote transfers, we can look at either
> adding specific things to mirrors (containers, images, packages are
> all things we've added recently) or adding a caching reverse-proxy for
> them ([3],[4] some examples).
>
> Questions in #openstack-infra will usually get a helpful response too
>
> Good luck :)
>
> -i
>
> [1] https://bugs.launchpad.net/openstack-gate/+bug/1708707/
> [2] https://etherpad.openstack.org/p/centos7-dsvm-triage
> [3] https://review.openstack.org/491800
> [4] https://review.openstack.org/491466
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo][puppet] Hold off on approving patches until further notice

[Alex Schultz]

FYI,

The gates are hosed for a variety of reasons[0][1] and we can't get
critical patches merged. Please hold off on rechecking or approving
anything new until further notice.   We're hoping to get some of the
fixes for this merged today.  I will send a note when it's OK to merge
again.

[0] https://bugs.launchpad.net/tripleo/+bug/1709428
[1] https://bugs.launchpad.net/tripleo/+bug/1709327

Thanks,
-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] [python-openstackclient][python-openstacksdk][neutron] supporting resource extensions with our CLI

[Akihiro Motoki]

I think this discussion has several aspects from general direction to
implementation details.

TL;DR
My suggestion as a main maintainer of python-neutronclient is to
upstream all out-of-tree APIs, support all features in OSC and push
away 'neutron' CLI.

The long version;

In my basic understanding, OpenStack in general has chosen the way
that we don't accept vendor extensions in API from the POV of inter
operability. neutron still supports to load out-of-tree API
definitions but I think neutron is just behind it. Nova drops
out-of-tree extension support in the API in Pike as Matt mentioned,
and if we move the (micro-)versioning forward out-of-tree API
definition will have more difficulties. IMHO I would like to see all
APIs are upstreamed as others commented. I believe this point is most
important and we all needs to be in a same page. Hopefully all
out-of-tree APIs will be upstreamed.

My understanding is the current OSC and openstacksdk (in addition to
shade) adopts this position.

On the other hand, we also need to take care of existing users on the
'neutron' CLI side.
I think there are several options on python-neutronclient.
(a) keep the current deprecation and recommend out-of-tree API to be upstreamed
(b) no deprecation warning from neutron CLI but keep the deprecation
policy on 'neutron' CLI (which means no new feature and positive
maintenance is provided)
(c) changing the current deprecation policy and continue to add new
features to 'neutron' CLI

I think (a) or (b) is realistic.
(c) needs more developers and reviewers. (I personally supports OSC,
openstacksdk and shade.)

The deprecation means no features will be coming for 'neutron' CLI and
all new features are suggested to go to OSC. I believe this is the
future we agreed. We can keep 'neutron' CLI only for existing
features, even though no neutron (and stadium projects) need to
implement new features in 'neutron' CLI. neutron CLI will be gone even
if there is no deprecation notice. At some point, we can split out
*CLI* part of neutronclient to a hosted project if someone wants to
keep 'neutron' CLI.

There is another background which makes neutron CLI difficult to keep
backward compatibility. The neutron option parsing is ugly enough and
it is hard to be maintained. It breaks backward compatibility so
easily and prevents from changing option formats or introducing new
options which are considered better. Thus, as a main maintainer of
python-neutronclient, I would like to push away this feature
completely, but perhaps this is the feature which out-of-tree API
would like to leverage. Does anyone want to support the extra argument
mechanism in neutron CLI ([1] and [2] for more detail)?

[1] 
https://docs.openstack.org/python-neutronclient/latest/cli/neutron.html#extra-arguments-for-create-update-operation
[2] 
https://docs.openstack.org/python-neutronclient/latest/contributor/cli_option_guideline.html

Thanks,
Akihiro

2017-08-09 2:46 GMT+09:00 Boden Russell :
>
> On 8/8/17 10:29 AM, Akihiro Motoki wrote:
>> My reply applies to 'resource' extension but does not apply to
>> 'attribute extension'
>
> My apologies for using confusing terminology; as you pointed out we
> don't currently have a good solution for attribute extensions with OSC
> and I've tried to outline the technicals in the RFE style bug [1] where
> I hope we can continue this discussion.
>
> python-neutronclient does support these attribute extensions, but as of
> today neutronclient gives deprecation warnings when used; so users are
> "concerned" when they see this and we don't have a complete story for
> OSC. Perhaps we can suppress those deprecations until we figure out a
> path forward?
>
> Thanks
>
>
> [1] https://bugs.launchpad.net/neutron/+bug/1705755
>
> __
> OpenStack Development Mailing 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-operators] [OpenStack-docs] [doc] Operations Guide removal

[Anne Gentle]

On Thu, Aug 10, 2017 at 3:09 AM, Yuki Kasuya  wrote:
> Hi,
>
>
> On 7/19/17 23:51, Anne Gentle wrote:
>>
>> On Wed, Jul 19, 2017 at 5:51 AM, Doug Hellmann 
>> wrote:
>>>
>>> Excerpts from Blair Bethwaite's message of 2017-07-19 20:40:25 +1000:

 Hi Alex,

 I just managed to take a half hour to look at this and have a few
 questions/comments towards making a plan for how to proceed with
 moving the Ops Guide content to the wiki...

 1) Need to define wiki location and structure. Curiously at the moment
 there is already meta content at
 https://wiki.openstack.org/wiki/Documentation/OpsGuide, Maybe the
 content could live at https://wiki.openstack.org/wiki/OpsGuide? I
 think it makes sense to follow the existing structure with possible
 exception of culling wrong / very-out-of-date content (but perhaps
 anything like that should be done as a later step and keep it simple
 aiming for a "like-for-like" migration to start with)...?
>>>
>>>
>>> Yes, I would recommend moving the existing content and then making any
>>> major changes to it.
>>>
 2) Getting the content into the wiki. Looks like there is no obvious
 up-to-date RST import functionality for MediaWiki. Pandoc seems as
 though it might support some useful conversions but I didn't try this
 yet and don't have any experience with it - can anyone say with
 authority whether it is worth pursuing?
>>>
>>>
>>> I can't say with authority myself, but I can refer to Anne as an
>>> authority. :-)
>>
>>
>> Ha, well, I think Pandoc is the one to try first, let's say that for
>> starters.
>>
>> Here's what I was thinking:
>> If you're interested in the export, run an experiment with Pandoc to
>> convert from RST to Mediawiki.
>>
>> http://pandoc.org/demos.html
>>
>> You'll likely still have cleanup but it's a start. Only convert
>> troubleshooting to start, which gets the most hits: docs.openstack.org/
>> ops-guide/ops-network-troubleshooting.html
>> Then see how much you get from Pandoc.
>>
>
> I tried to convert all docs under ops-guide dir using pandoc. Like below,
> toctree,term and some directives doesn't work after converting. But, at
> glance, almost fine after converting.
> If you don't mind, I'll able to create wiki pages of ops-guide.
>
> xxx@devstack02:~/work/openstack-manuals/doc/ops-guide/source$ pandoc
> index.rst -t mediawiki -o index
> .wiki
> pandoc: ignoring unknown directive: toctree "source" (line 58, column 1)
> pandoc: ignoring unknown role :term: in "source" (line 20, column 13)
> pandoc: ignoring unknown role :term: in "source" (line 19, column 59)
>

Fantastic! That's better that I thought it would do, I'll admit. :)
You may have figured this out, but :term: [1] is for glossary entries,
and a toctree directive [2] is for a table of contents insertion.

Thanks for testing the theory and making it practical.

Anne

1. http://www.sphinx-doc.org/en/stable/markup/inline.html
2. http://www.sphinx-doc.org/en/stable/markup/toctree.html



>>
>> Hope this helps -
>> Anne
>>
>>>
 3) Future management - obvious can of worms given this is much better
 addressed by all the tooling and scaffolding the docs team already
 provides around the repos... but nonetheless some expectations may
 need to be set upfront to avoid future pain.
>>>
>>>
>>> What sort of issues do you foresee?
>>>
>>> Doug
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>>
>
> --
> -
> KDDI Research, Inc.
> Integrated Core Network Control
> And Management Laboratory
> Yuki Kasuya
> yu-kas...@kddilabs.jp
> +81 80 9048 8405



-- 

Read my blog: justwrite.click
Subscribe to Docs|Code: docslikecode.com

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [OpenStack-docs] [doc] Operations Guide removal

[Doug Hellmann]

Excerpts from Yuki Kasuya's message of 2017-08-10 17:09:48 +0900:

> 
> I tried to convert all docs under ops-guide dir using pandoc. Like 
> below, toctree,term and some directives doesn't work after converting. 
> But, at glance, almost fine after converting.
> If you don't mind, I'll able to create wiki pages of ops-guide.
> 
> xxx@devstack02:~/work/openstack-manuals/doc/ops-guide/source$ pandoc 
> index.rst -t mediawiki -o index
> .wiki
> pandoc: ignoring unknown directive: toctree "source" (line 58, column 1)
> pandoc: ignoring unknown role :term: in "source" (line 20, column 13)
> pandoc: ignoring unknown role :term: in "source" (line 19, column 59)

It should be safe to ignore the toctree directives. If you want to keep
the same structure between the wiki pages and the original source
document, you might want to replace those with lists of links.

The term role automatically links to the glossary. As long as the text
highlighted by the role is present in the output, it is fine to ignore
that warning, too.

Doug

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Thierry Carrez]

joehuang wrote:
> Tricircle plans to cut stable/pike branch on August 22nd, it has dependency 
> on Neutron stable/pike creation.

That sounds a bit late to create your release branch. It doesn't give
you a lot of time to react to critical issues discovered in that
release, as August 24 is the final date to submit new releases for
inclusion before Pike is formally declared released.

My advice would be to do a X.Y.0 release as soon as you can freeze
features (neutron should have their branch this week), and have some
time to produce a X.Y.1 bugfix release if you detect critical issues in
testing.

-- 
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-Infra] citycloud lon1 mirror postmortem

[Ian Wienand]

Hi,

In response to sdague reporting that citycloud jobs were timing out, I
investigated the mirror, suspecting it was not providing data fast enough.

There were some 170 htcacheclean jobs running, and the host had a load
over 100.  I killed all these, but performance was still unacceptable.

I suspected networking, but since the host was in such a bad state I
decided to reboot it.  Unfortunately it would get an address from DHCP
but seemed to have DNS issues ... eventually it would ping but nothing
else was working.

nodepool.o.o was placed in the emergency file and I removed lon1 to
avoid jobs going there.

I used the citycloud live chat, and Kim helpfully investigated and
ended up migrating mirror.lon1.citycloud.openstack.org to a new
compute node.  This appeared to fix things, for us at least.

nodepool.o.o is removed from the emergency file and original config
restored.

With hindsight, clearly the excessive htcacheclean processes were due
to negative feedback of slow processes due to the network/dns issues
all starting to bunch up over time.  However, I still think we could
minimise further issues running it under a lock [1].  Other than that,
not sure there is much else we can do, I think this was largely an
upstream issue.

Cheers,

-i

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

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[openstack-dev] [charms] PTL cover for the next two weeks

[James Page]

Hi All

As I'm off in the backwaters of Scotland with zero chance of any internet
access for the next two weeks, I'm delegating my PTL responsibilities to
the capable Ryan Beisner until my return.

I'll be back just after the charms final freeze in the leadup to the charms
release at the start of September.

Have fun

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

Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

[Mohan Kumar]

Hi Rajeev,

No , We haven't started any design .

Let me know If I can help you anywhere . We can collaborate on this :)

Thanks.,
Mohankumar.N



On Tue, Aug 8, 2017 at 12:15 PM, rajeev.satyanaray...@wipro.com <
rajeev.satyanaray...@wipro.com> wrote:

> Hi MohanKumar,
>
>
>
> Thanks for the reply.
>
>
>
> Is the design part for the “OAM Operation Manager for SFC” done? What is
> the approach being used to monitor the SFC? If the design is already done,
> I would like to contribute in implementing it. Please provide your comments.
>
>
>
> Thanks and Regards,
>
> Rajeev
>
>
>
> *From:* Mohan Kumar [mailto:nmohankumar1...@gmail.com]
> *Sent:* Friday, July 28, 2017 1:32 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Cc:* Rajeev Satyanarayana (MFG & Tech) 
> *Subject:* ** Newsletter/Marketing email** Re: [openstack-dev]
> [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC
>
>
>
> ** This mail has been sent from an external source. Treat hyperlinks and
> attachments in this email with caution**
>
> Hi Rajeev,
>
>
>
> The Chain Monitoring is the missing piece in networking-sfc . Vikram and
> myself were discussed to introduce "SFC Manager" [1] (basically OAM tool )
> few cycle before.
>
>
>
> It'll continuously monitor an existing SFC chain,  when any SF VM goes
> down or any packet drop. It'll trigger alert and capture corresponding logs
> . But we haven't started any implementation on this. Feel free to discuss
> with community, IMO  this feature will be great addition to networking-sfc
>
>
>
> [1]  https://bugs.launchpad.net/networking-sfc/+bug/1513368
>
> 
>
>
>
> IRC: #networking-sfc
>
> Weekly Meeting:  https://wiki.openstack.org/wiki/Meetings/
> ServiceFunctionChainingMeeting
> 
>
>
>
> Thanks.,
>
> Mohankumar.N
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jul 27, 2017 at 11:30 AM, rajeev.satyanaray...@wipro.com <
> rajeev.satyanaray...@wipro.com> wrote:
>
> Hi Igor/Cathy/Gord,
>
>
>
> Sorry for the delay in replying.
>
>
>
> As part of monitoring the SFC, I think maintaining the details of “Number
> of flows assigned to a given SFC”, “Number of packets/bytes dropped/hit due
> to the policies at each Service Function entry/exit points or for the
> entire SFC” would be good to start with. I feel based on some of these
> details, an operator can know how much the virtual switch is loaded and
> take a call on whether to add a new SFC, or it could even help during
> debugging which service function has exactly caused the disruption to SFC.
>
> As a first step, I think it would be good to add meters to provide “number
> of packets/bytes hit due to policy at the ingress and egress of the entire
> SFC” and to realize that, we would need to add specific pollsters. We can
> use neutron_client API to fetch the ingress and egress port details and
> fetch the corresponding flows for those specific ports(also get flow_infos
> from flow_classifier and then use them to dump_flows matching those
> flow_infos) and fetch the no.of packets hit due to policy from them.
>
>
>
> I have just mentioned my idea on this. Can I please know your opinion on
> this and provide your comments?
>
>
>
> Thanks and Regards,
>
> Rajeev.
>
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer 

Re: [openstack-dev] [mistral][core] Proposing Andras Kovi to the Mistral core team

[Lingxian Kong]

+1, It will be great to have him!


Cheers,
Lingxian Kong (Larry)

On Thu, Aug 10, 2017 at 5:34 PM, Renat Akhmerov 
wrote:

> Hi,
>
> I’d like to propose Andras Kovi to the Mistral core team.
>
> The current statistics of Andras can be seen at [1].
> Andras has been contributing for about 1.5 years and in Pike he increased
> his activity significantly, primarily reviewing. His reviews are always
> thorough and insightful. He cares about code quality. He knows both
> OpenStack ecosystem and Mistral architecture and codebase well. Adding
> Andras to the core team would be also very useful for us because he is a
> very active user of Mistral, he implemented or participated in
> implementation of lots of Nokia CBAM use cases based on Mistral.
> Andras also gave an excellent presentation about Mistral performance in
> Boston, [2]. I’d really recommend to watch it if you work with Mistral as a
> contributor or as a user.
> Speaking less formally, Andras is a very good guy, deep thinker with a
> great experience in software programming. Every time I have a chance to
> meet him personally it’s a lot of fun to talk to him and learn from him.
>
> So I’m asking you to support me in this promotion. I really believe that
> Andras will be an invaluable addition to our team.
>
> [1] http://stackalytics.com/?module=mistral-group_id=akovi
> [2] https://www.openstack.org/videos/boston-2017/mistral-
> performance-in-numbers
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> __
> OpenStack Development Mailing 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] [heat][infra] Help needed! high gate failure rate

[Rabi Mishra]

On Thu, Aug 10, 2017 at 2:51 PM, Ian Wienand  wrote:

> On 08/10/2017 06:18 PM, Rico Lin wrote:
> > We're facing a high failure rate in Heat's gates [1], four of our gate
> > suffering with fail rate from 6 to near 20% in 14 days. which makes most
> of
> > our patch stuck with the gate.
>
> There have been a confluence of things causing some problems recently.
> The loss of OSIC has distributed more load over everything else, and
> we have seen an increase in job timeouts and intermittent networking
> issues (especially if you're downloading large things from remote
> sites).  There have also been some issues with the mirror in rax-ord
> [1]
>
> > gate-heat-dsvm-functional-convg-mysql-lbaasv2-ubuntu-xenial(19.67%)
> > gate-heat-dsvm-functional-convg-mysql-lbaasv2-non-
> apache-ubuntu-xenia(9.09%)
> > gate-heat-dsvm-functional-orig-mysql-lbaasv2-ubuntu-xenial(8.47%)
> > gate-heat-dsvm-functional-convg-mysql-lbaasv2-py35-ubuntu-xenial(6.00%)
>
> > We still try to find out what's the cause but (IMO,) seems it might be
> some
> > thing wrong with our infra. We need some help from infra team, to know if
> > any clue on this failure rate?
>
> The reality is you're just going to have to triage this and be a *lot*
> more specific with issues.


One of the issues we see recently is that, many jobs killed mid way through
the tests as the job times out(120 mins).  It seems jobs are many times
scheduled to very slow nodes, where setting up devstack takes more than 80
mins[1].

[1]
http://logs.openstack.org/49/492149/2/check/gate-heat-dsvm-functional-orig-mysql-lbaasv2-ubuntu-xenial/03b05dd/console.html#_2017-08-10_05_55_49_035693

I find opening an etherpad and going
> through the failures one-by-one helpful (e.g. I keep [2] for centos
> jobs I'm interested in).
>
> Looking at the top of the console.html log you'll have the host and
> provider/region stamped in there.  If it's timeouts or network issues,
> reporting to infra the time, provider and region of failing jobs will
> help.  If it's network issues similar will help.  Finding patterns is
> the first step to understanding what needs fixing.
>
> If it's due to issues with remote transfers, we can look at either
> adding specific things to mirrors (containers, images, packages are
> all things we've added recently) or adding a caching reverse-proxy for
> them ([3],[4] some examples).
>
> Questions in #openstack-infra will usually get a helpful response too
>
> Good luck :)
>
> -i
>
> [1] https://bugs.launchpad.net/openstack-gate/+bug/1708707/
> [2] https://etherpad.openstack.org/p/centos7-dsvm-triage
> [3] https://review.openstack.org/491800
> [4] https://review.openstack.org/491466
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [ironic] Countdown to Pike final

[Dmitry Tantsur]

Hi team!

I would like to finish our releases, or at least the most of them, by the middle 
of next week to leave some time for stabilization and to avoid problems with the 
requirements repo branching. We have released ironic-lib, ironic-ui, sushy and 
the clients already. Now we need to figure out what is left for the remaining 
projects.


On the line 113 of our whiteboard [1] I've started collecting things we 
absolutely must have in Pike for each project. Currently it mostly includes the 
doc migration and the resource classes work. Please add everything that is 
blocking us.


On the line 141 (will probably move soon, see "Review requests for 
non-blockers"), I've left some space for things that are ready to be included, 
and that are acceptable under the feature freeze (e.g. minor vendor patches). 
Please urgently add there what you need. We cannot promise to review everything, 
so prioritize accordingly please.


We will review this list on Monday's meeting to figure out our path forward.

Thanks,
Still your PTL, Dmitry :)

[1] https://etherpad.openstack.org/p/IronicWhiteBoard

__
OpenStack Development Mailing 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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Dmitry Tantsur]

Hi Tony!

I hope to finish releasing Ironic stuff next week. We still have a few critical 
things to land.


On 08/10/2017 07:46 AM, Tony Breeds wrote:


Hi All,
 In an effort to qualify which projects are likley to be affected if
when we open the requirements repo I generated a list of all repos that:

1. Subscribe to requirements management
2. Do not already have a stable/pike branch
3. Do not follow the cycle-with-milestones, cycle-trailing or
independent release models
4. Are not a 'branchless' project (tempest or tempest-plugin)

These repos I believe *should* have a stable/pike branch or will see
problems when we open openstack/requirements.  Those issues were
described in [1]

It turns out close to 1/3rd of projects that subscribe to requirements
management are not ready for us to re-open for master.  So we need you
help to get that number down to a much more acceptable number.

The good news is it's pretty easy to fix this with the cool tools and
workflow in the releases repo[2].  I suspect that the 'service' will
take care of themselves, and the horizon-plugins are waiting to horizon
to cut RC1.

Repos with type: horizon-plugin
ironic-ui  ironic


This was released already.


manila-ui  manila
monasca-ui monasca
neutron-fwaas-dashboardneutron
solum-dashboardsolum
tacker-horizon tacker
watcher-dashboard  watcher
zun-ui zun

Repos with type: other
python-openstackclient OpenStackClient
patroleQuality Assurance
heat-agentsheat
ironic-inspector   ironic


Hmm, this should be type:service too, will double-check.


ironic-python-agentironic
kuryr-kubernetes   kuryr
monasca-common monasca
monasca-notification   monasca
monasca-persister  monasca
monasca-transform  monasca

Repos with type: service
ironic ironic
monasca-apimonasca
monasca-log-apimonasca
swift  swift
tricircle  tricircle
vitragevitrage
watcherwatcher
zunzun

Those are the easy items.

The following repos don't seem to use the openstack/releases repo so I
have less information there.

i18n   I18n
almanach
blazar
blazar-nova
compute-hyperv
ekko
gce-api
glare
ironic-staging-drivers
kosmos
masakari
masakari-monitors
mixmatch
mogan
nemesis
networking-dpm
networking-fujitsu
networking-generic-switch
networking-l2gw
networking-powervm
neutron-vpnaas
neutron-vpnaas-dashboard
nova-dpm
nova-lxd
nova-powervm
os-xenapi
python-blazarclient
python-cratonclient
python-glareclient
python-kingbirdclient
python-masakariclient
python-moganclient
python-oneviewclient
python-openstacksdk
python-valenceclient
swauth
tap-as-a-service
trio2o
valence
vmware-nsx
vmware-nsxlib
openstackclientOpenStackClient
anchor Security
ceilometer-powervm Telemetry
ec2-apiec2-api
horizon-cisco-ui   horizon
bifrostironic
ironic-python-agent-builderironic
magnum magnum
magnum-ui  magnum
manila-image-elements  manila
murano-agent   murano
octavia-dashboard  octavia
senlin-dashboard   senlin
tacker tacker
networking-hyperv  winstackers

It'd be great to get some of these repos represented in
openstack/releases.  Having a confirmed release-model would go a long
way to clearing up the list. An alternate approach would be to remove
redundant items from projects.txt

Yours Tony.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120720.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120816.html



__
OpenStack Development Mailing List 

Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Akihiro Motoki]

Tony,

Thanks for taking care.

> The following repos don't seem to use the openstack/releases repo so I
> have less information there.

Most of them are projects not under the governance (so-called "hosted"
or "unofficial" projects),
so I am not sure there is a good way to handle them.

I can comment some of them which I am involved in deeply.

> i18n   I18n

At now, i18n repo is a part of governance but this is a project which
has no need to cut a release,
so it always follows the master branch of the requirements repo.
It is not a blocker for opening the master branch in the requirements repo.

> neutron-vpnaas
> neutron-vpnaas-dashboard

These projects are neutron related and horizon plugin.
We will do same things for other neutron stadium and horizon plugin projects.

IMHO we don't need to take care of them much.

> python-openstacksdk

python-openstackclient depends on this, so we need to cut stable/branch
from the latest release. The status of the project is being discussed
in the ML thread,
but I believe we need to cut a stable branch. On the other hand, I
think it does not
block the opening of the master of the requirements repo as the latest
release of
python-openstacksdk is enough for Pike release of OSC.

> It'd be great to get some of these repos represented in
> openstack/releases.  Having a confirmed release-model would go a long
> way to clearing up the list. An alternate approach would be to remove
> redundant items from projects.txt

I am not sure that projects not under the TC governance can use
openstack/releases repo.
Is the openstack/release repo for projects under the governance?

Thanks,
Akihiro

2017-08-10 14:46 GMT+09:00 Tony Breeds :
>
> Hi All,
> In an effort to qualify which projects are likley to be affected if
> when we open the requirements repo I generated a list of all repos that:
>
> 1. Subscribe to requirements management
> 2. Do not already have a stable/pike branch
> 3. Do not follow the cycle-with-milestones, cycle-trailing or
>independent release models
> 4. Are not a 'branchless' project (tempest or tempest-plugin)
>
> These repos I believe *should* have a stable/pike branch or will see
> problems when we open openstack/requirements.  Those issues were
> described in [1]
>
> It turns out close to 1/3rd of projects that subscribe to requirements
> management are not ready for us to re-open for master.  So we need you
> help to get that number down to a much more acceptable number.
>
> The good news is it's pretty easy to fix this with the cool tools and
> workflow in the releases repo[2].  I suspect that the 'service' will
> take care of themselves, and the horizon-plugins are waiting to horizon
> to cut RC1.
>
> Repos with type: horizon-plugin
> ironic-ui  ironic
> manila-ui  manila
> monasca-ui monasca
> neutron-fwaas-dashboardneutron
> solum-dashboardsolum
> tacker-horizon tacker
> watcher-dashboard  watcher
> zun-ui zun
>
> Repos with type: other
> python-openstackclient OpenStackClient
> patroleQuality Assurance
> heat-agentsheat
> ironic-inspector   ironic
> ironic-python-agentironic
> kuryr-kubernetes   kuryr
> monasca-common monasca
> monasca-notification   monasca
> monasca-persister  monasca
> monasca-transform  monasca
>
> Repos with type: service
> ironic ironic
> monasca-apimonasca
> monasca-log-apimonasca
> swift  swift
> tricircle  tricircle
> vitragevitrage
> watcherwatcher
> zunzun
>
> Those are the easy items.
>
> The following repos don't seem to use the openstack/releases repo so I
> have less information there.
>
> i18n   I18n
> almanach
> blazar
> blazar-nova
> compute-hyperv
> ekko
> gce-api
> glare
> ironic-staging-drivers
> kosmos
> masakari
> masakari-monitors
> mixmatch
> mogan
> nemesis
> networking-dpm
> networking-fujitsu
> networking-generic-switch
> networking-l2gw
> networking-powervm
> neutron-vpnaas
> neutron-vpnaas-dashboard
> nova-dpm
> nova-lxd
> 

Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Tony Breeds]

On Thu, Aug 10, 2017 at 08:41:40AM +, joehuang wrote:
> Hello,
> 
> Tricircle plans to cut stable/pike branch on August 22nd, it has
> dependency on Neutron stable/pike creation.

Okay in that case can you block any reviews from the proposal-bot until
you do branch.

Yours Tony.


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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Tony Breeds]

On Thu, Aug 10, 2017 at 07:29:22AM +, witold.be...@est.fujitsu.com wrote:
> Hi Tony,
> 
> stable/pike branches for Monasca repos are on the way
> 
> https://review.openstack.org/492101

Great!

next cycle we'll have to try and match against open reviews to reduce
the noise.

Yours Tony.


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] [all][elections] PTL Voting is now open

[Swapnil Kulkarni]

On Thu, Aug 10, 2017 at 1:57 PM, Dmitry Tantsur  wrote:
> On 08/10/2017 02:01 AM, Kendall Nelson wrote:
>>
>> Hello Again!
>>
>> Elections are underway and will remain open for you to cast your vote
>> until Aug 16th, 2017 23:45 UTC.
>>
>> We are having elections for Ironic and Documentation.
>
>
> By the way, why do I receive a poll, given that I'm one of candidates? :)

Since you are also the contributor :) So I think you already got
yourself a vote :-D
>
>>
>> If you are a Foundation individual member and had a commit in one of the
>> program's projects[0] over the Ocata-Pike timeframe (September, 2016 23:59
>> UTC to August 3rd , 2017 23:59 UTC) then you are eligible to vote. You
>> should find your email with a link to the Condorcet page to cast your vote
>> in the inbox of your gerrit preferred email[1].
>>
>> What to do if you don't see the email and have a commit in at least one of
>> the programs having an election:
>>* check the trash or spam folders of your gerrit Preferred Email
>> address, in case it went into trash or spam
>
>
> A warning: the email got into gmail spam folder for me!
>
>>* wait a bit and check again, in case your email server is a bit slow
>>* find the sha of at least one commit from the program project repos[0]
>> and email the election officials. If we can confirm that you are entitled to
>> vote, we will add you to the voters list for the appropriate election.
>>
>> Our democratic process is important to the health of OpenStack, please
>> exercise your right to vote!
>
>
> ++ please do!
>
>>
>> Candidate statements/platforms can be found linked to Candidate names on
>> this page: http://governance.openstack.org/election/#pike-ptl-candidates
>>
>> Happy voting,
>>
>> -Kendall Nelson (diablo_rojo)
>>
>> [0] The list of the program projects eligible for electoral status:
>> https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=aug-2017-elections
>>
>> [1] Sign into review.openstack.org :
>>  Go to Settings > Contact Information.
>>  Look at the email listed as your Preferred Email.
>>  That is where the ballot has been sent.
>>
>>
>>
>> __
>> OpenStack Development Mailing 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] [heat][infra] Help needed! high gate failure rate

[Ian Wienand]

On 08/10/2017 06:18 PM, Rico Lin wrote:
> We're facing a high failure rate in Heat's gates [1], four of our gate
> suffering with fail rate from 6 to near 20% in 14 days. which makes most of
> our patch stuck with the gate.

There have been a confluence of things causing some problems recently.
The loss of OSIC has distributed more load over everything else, and
we have seen an increase in job timeouts and intermittent networking
issues (especially if you're downloading large things from remote
sites).  There have also been some issues with the mirror in rax-ord
[1]

> gate-heat-dsvm-functional-convg-mysql-lbaasv2-ubuntu-xenial(19.67%)
> gate-heat-dsvm-functional-convg-mysql-lbaasv2-non-apache-ubuntu-xenia(9.09%)
> gate-heat-dsvm-functional-orig-mysql-lbaasv2-ubuntu-xenial(8.47%)
> gate-heat-dsvm-functional-convg-mysql-lbaasv2-py35-ubuntu-xenial(6.00%)

> We still try to find out what's the cause but (IMO,) seems it might be some
> thing wrong with our infra. We need some help from infra team, to know if
> any clue on this failure rate?

The reality is you're just going to have to triage this and be a *lot*
more specific with issues.  I find opening an etherpad and going
through the failures one-by-one helpful (e.g. I keep [2] for centos
jobs I'm interested in).

Looking at the top of the console.html log you'll have the host and
provider/region stamped in there.  If it's timeouts or network issues,
reporting to infra the time, provider and region of failing jobs will
help.  If it's network issues similar will help.  Finding patterns is
the first step to understanding what needs fixing.

If it's due to issues with remote transfers, we can look at either
adding specific things to mirrors (containers, images, packages are
all things we've added recently) or adding a caching reverse-proxy for
them ([3],[4] some examples).

Questions in #openstack-infra will usually get a helpful response too

Good luck :)

-i

[1] https://bugs.launchpad.net/openstack-gate/+bug/1708707/
[2] https://etherpad.openstack.org/p/centos7-dsvm-triage
[3] https://review.openstack.org/491800
[4] https://review.openstack.org/491466

__
OpenStack Development Mailing 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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[joehuang]

Hello,

Tricircle plans to cut stable/pike branch on August 22nd, it has dependency on 
Neutron stable/pike creation.

Best Regards
Chaoyi Huang (joehuang)


From: Tony Breeds [t...@bakeyournoodle.com]
Sent: 10 August 2017 13:46
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality 
Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst...

Hi All,
In an effort to qualify which projects are likley to be affected if
when we open the requirements repo I generated a list of all repos that:

1. Subscribe to requirements management
2. Do not already have a stable/pike branch
3. Do not follow the cycle-with-milestones, cycle-trailing or
   independent release models
4. Are not a 'branchless' project (tempest or tempest-plugin)

These repos I believe *should* have a stable/pike branch or will see
problems when we open openstack/requirements.  Those issues were
described in [1]

It turns out close to 1/3rd of projects that subscribe to requirements
management are not ready for us to re-open for master.  So we need you
help to get that number down to a much more acceptable number.

The good news is it's pretty easy to fix this with the cool tools and
workflow in the releases repo[2].  I suspect that the 'service' will
take care of themselves, and the horizon-plugins are waiting to horizon
to cut RC1.

Repos with type: horizon-plugin
ironic-ui  ironic
manila-ui  manila
monasca-ui monasca
neutron-fwaas-dashboardneutron
solum-dashboardsolum
tacker-horizon tacker
watcher-dashboard  watcher
zun-ui zun

Repos with type: other
python-openstackclient OpenStackClient
patroleQuality Assurance
heat-agentsheat
ironic-inspector   ironic
ironic-python-agentironic
kuryr-kubernetes   kuryr
monasca-common monasca
monasca-notification   monasca
monasca-persister  monasca
monasca-transform  monasca

Repos with type: service
ironic ironic
monasca-apimonasca
monasca-log-apimonasca
swift  swift
tricircle  tricircle
vitragevitrage
watcherwatcher
zunzun

Those are the easy items.

The following repos don't seem to use the openstack/releases repo so I
have less information there.

i18n   I18n
almanach
blazar
blazar-nova
compute-hyperv
ekko
gce-api
glare
ironic-staging-drivers
kosmos
masakari
masakari-monitors
mixmatch
mogan
nemesis
networking-dpm
networking-fujitsu
networking-generic-switch
networking-l2gw
networking-powervm
neutron-vpnaas
neutron-vpnaas-dashboard
nova-dpm
nova-lxd
nova-powervm
os-xenapi
python-blazarclient
python-cratonclient
python-glareclient
python-kingbirdclient
python-masakariclient
python-moganclient
python-oneviewclient
python-openstacksdk
python-valenceclient
swauth
tap-as-a-service
trio2o
valence
vmware-nsx
vmware-nsxlib
openstackclientOpenStackClient
anchor Security
ceilometer-powervm Telemetry
ec2-apiec2-api
horizon-cisco-ui   horizon
bifrostironic
ironic-python-agent-builderironic
magnum magnum
magnum-ui  magnum
manila-image-elements  manila
murano-agent   murano
octavia-dashboard  octavia
senlin-dashboard   senlin
tacker tacker
networking-hyperv  winstackers

It'd be great to get some of these repos represented in
openstack/releases.  Having a confirmed release-model would go a long
way to clearing up the list. An alternate approach would be to 

Re: [openstack-dev] [all][elections] PTL Voting is now open

[Dmitry Tantsur]

On 08/10/2017 02:01 AM, Kendall Nelson wrote:

Hello Again!

Elections are underway and will remain open for you to cast your vote until Aug 
16th, 2017 23:45 UTC.


We are having elections for Ironic and Documentation.


By the way, why do I receive a poll, given that I'm one of candidates? :)



If you are a Foundation individual member and had a commit in one of the 
program's projects[0] over the Ocata-Pike timeframe (September, 2016 23:59 UTC 
to August 3rd , 2017 23:59 UTC) then you are eligible to vote. You should find 
your email with a link to the Condorcet page to cast your vote in the inbox of 
your gerrit preferred email[1].


What to do if you don't see the email and have a commit in at least one of the 
programs having an election:
   * check the trash or spam folders of your gerrit Preferred Email address, in 
case it went into trash or spam


A warning: the email got into gmail spam folder for me!


   * wait a bit and check again, in case your email server is a bit slow
   * find the sha of at least one commit from the program project repos[0] and 
email the election officials. If we can confirm that you are entitled to vote, 
we will add you to the voters list for the appropriate election.


Our democratic process is important to the health of OpenStack, please exercise 
your right to vote!


++ please do!



Candidate statements/platforms can be found linked to Candidate names on this 
page: http://governance.openstack.org/election/#pike-ptl-candidates


Happy voting,

-Kendall Nelson (diablo_rojo)

[0] The list of the program projects eligible for electoral status: 
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=aug-2017-elections


[1] Sign into review.openstack.org :
 Go to Settings > Contact Information.
 Look at the email listed as your Preferred Email.
 That is where the ballot has been sent.



__
OpenStack Development Mailing 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] [mistral][core] Proposing Andras Kovi to the Mistral core team

[Csatari, Gergely (Nokia - HU/Budapest)]

Hi,

+1 (from an other Nokia guy, who knows Andras personally and agrees, that he is 
a good guy ☺)

Br,
Gerg0

From: Dougal Matthews [mailto:dou...@redhat.com]
Sent: Thursday, August 10, 2017 9:54 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [mistral][core] Proposing Andras Kovi to the 
Mistral core team



On 10 August 2017 at 06:34, Renat Akhmerov 
> wrote:
Hi,

I’d like to propose Andras Kovi to the Mistral core team.

The current statistics of Andras can be seen at [1].
Andras has been contributing for about 1.5 years and in Pike he increased his 
activity significantly, primarily reviewing. His reviews are always thorough 
and insightful. He cares about code quality. He knows both OpenStack ecosystem 
and Mistral architecture and codebase well. Adding Andras to the core team 
would be also very useful for us because he is a very active user of Mistral, 
he implemented or participated in implementation of lots of Nokia CBAM use 
cases based on Mistral.
Andras also gave an excellent presentation about Mistral performance in Boston, 
[2]. I’d really recommend to watch it if you work with Mistral as a contributor 
or as a user.
Speaking less formally, Andras is a very good guy, deep thinker with a great 
experience in software programming. Every time I have a chance to meet him 
personally it’s a lot of fun to talk to him and learn from him.

So I’m asking you to support me in this promotion. I really believe that Andras 
will be an invaluable addition to our team.

+1, from me. Andras has given some very useful reviews and I look forward to 
more :-)


[1] http://stackalytics.com/?module=mistral-group_id=akovi
[2] https://www.openstack.org/videos/boston-2017/mistral-performance-in-numbers

Thanks

Renat Akhmerov
@Nokia

__
OpenStack Development Mailing 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] [heat][infra] Help needed! high gate failure rate

[Rico Lin]

Hi all

We're facing a high failure rate in Heat's gates [1], four of our gate
suffering with fail rate from 6 to near 20% in 14 days. which makes most of
our patch stuck with the gate.

gate-heat-dsvm-functional-convg-mysql-lbaasv2-ubuntu-xenial(19.67%)
gate-heat-dsvm-functional-convg-mysql-lbaasv2-non-apache-ubuntu-xenia(9.09%)
gate-heat-dsvm-functional-orig-mysql-lbaasv2-ubuntu-xenial(8.47%)
gate-heat-dsvm-functional-convg-mysql-lbaasv2-py35-ubuntu-xenial(6.00%)

We still try to find out what's the cause but (IMO,) seems it might be some
thing wrong with our infra. We need some help from infra team, to know if
any clue on this failure rate? Maybe some change in heat or infra cause
this? Is this only happen in heat's gate? (Do see some fail from other
teams, but not as bad as heat's gate.)

Thanks for any kind of help


[1]
http://status.openstack.org/openstack-health/#/g/project/openstack~2Fheat?duration=P14D

-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
OpenStack Development Mailing 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] package gluster-swift with Openstack swift repository

[Venkata R Edara]

Hello All,

we are from Red Hat and we have product called Gluster which is 
distributed file system. we have integrated Gluster with openstack-swift 
, the product is called



gluster-swift  . gluster-swift 
allows users to have SWIFT/S3 APIs with Gluster filesystem as back-end. 
we did re-base of gluster-swift with openstack-swift Newton release.


As gluster-swift is dependent on openstack-swift we would like to have 
it packaged in openstack-swift newton repository.


Is it possible to package gluster-swift project in openstack repository?.

we would like to know the process of packaging with openstack repo if 
openstack community agrees for that.


-Thanks

Venkata R Edara.

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [mistral][core] Proposing Andras Kovi to the Mistral core team

[Dougal Matthews]

On 10 August 2017 at 06:34, Renat Akhmerov  wrote:

> Hi,
>
> I’d like to propose Andras Kovi to the Mistral core team.
>
> The current statistics of Andras can be seen at [1].
> Andras has been contributing for about 1.5 years and in Pike he increased
> his activity significantly, primarily reviewing. His reviews are always
> thorough and insightful. He cares about code quality. He knows both
> OpenStack ecosystem and Mistral architecture and codebase well. Adding
> Andras to the core team would be also very useful for us because he is a
> very active user of Mistral, he implemented or participated in
> implementation of lots of Nokia CBAM use cases based on Mistral.
> Andras also gave an excellent presentation about Mistral performance in
> Boston, [2]. I’d really recommend to watch it if you work with Mistral as a
> contributor or as a user.
> Speaking less formally, Andras is a very good guy, deep thinker with a
> great experience in software programming. Every time I have a chance to
> meet him personally it’s a lot of fun to talk to him and learn from him.
>
> So I’m asking you to support me in this promotion. I really believe that
> Andras will be an invaluable addition to our team.
>

+1, from me. Andras has given some very useful reviews and I look forward
to more :-)


>
> [1] http://stackalytics.com/?module=mistral-group_id=akovi
> [2] https://www.openstack.org/videos/boston-2017/mistral-
> performance-in-numbers
>
> Thanks
>
> Renat Akhmerov
> @Nokia
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][infra] Functional job failure rate at 100%

[Miguel Angel Ajo Pelayo]

Good (amazing) job folks. :)

El 10 ago. 2017 9:43, "Thierry Carrez"  escribió:

> Oh, that's good for us. Should still be fixed, if only so that we can
> test properly :)
>
> Kevin Benton wrote:
> > This is just the code simulating the conntrack entries that would be
> > created by real traffic in a production system, right?
> >
> > On Wed, Aug 9, 2017 at 11:46 AM, Jakub Libosvar  > > wrote:
> >
> > On 09/08/2017 18:23, Jeremy Stanley wrote:
> > > On 2017-08-09 15:29:04 +0200 (+0200), Jakub Libosvar wrote:
> > > [...]
> > >> Is it possible to switch used image for jenkins machines to use
> > >> back the older version? Any other ideas how to deal with the
> > >> kernel bug?
> > >
> > > Making our images use non-current kernel packages isn't trivial,
> but
> > > as Thierry points out in his reply this is not just a problem for
> > > our CI system. Basically Ubuntu has broken OpenStack (and probably
> a
> > > variety of other uses of conntrack) for a lot of people following
> > > kernel updates in 16.04 LTS so the fix needs to happen there
> > > regardless. Right now, basically, Ubuntu Xenial is not a good
> > > platform to be running OpenStack on until they get the kernel
> > > regression addressed.
> >
> > True. Fortunately, the impact is not that catastrophic for Neutron
> as it
> > might seem on the first look. Not sure about the other projects,
> though.
> > Neutron doesn't create conntrack entries in production code - only in
> > testing. That said, agents should work just fine even with the
> > kernel bug.
>
> --
> 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

[openstack-dev] package gluster-swift with Openstack swift repository

[Venkata R Edara]

Hello All,

we are from Red Hat and we have product called Gluster which is 
distributed file system. we have integrated Gluster with openstack-swift 
, the product is called



gluster-swift  . gluster-swift 
allows users to have SWIFT/S3 APIs with Gluster filesystem as back-end. 
we did re-base of gluster-swift with openstack-swift Newton release.


As gluster-swift is dependent on openstack-swift we would like to have 
it packaged in openstack-swift newton repository.


Is it possible to package gluster-swift project in openstack repository?.

we would like to know the process of packaging with openstack repo if 
openstack community agrees for that.


-Thanks

Venkata R Edara.

__
OpenStack Development Mailing 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][infra] Functional job failure rate at 100%

[Thierry Carrez]

Oh, that's good for us. Should still be fixed, if only so that we can
test properly :)

Kevin Benton wrote:
> This is just the code simulating the conntrack entries that would be
> created by real traffic in a production system, right?
> 
> On Wed, Aug 9, 2017 at 11:46 AM, Jakub Libosvar  > wrote:
> 
> On 09/08/2017 18:23, Jeremy Stanley wrote:
> > On 2017-08-09 15:29:04 +0200 (+0200), Jakub Libosvar wrote:
> > [...]
> >> Is it possible to switch used image for jenkins machines to use
> >> back the older version? Any other ideas how to deal with the
> >> kernel bug?
> >
> > Making our images use non-current kernel packages isn't trivial, but
> > as Thierry points out in his reply this is not just a problem for
> > our CI system. Basically Ubuntu has broken OpenStack (and probably a
> > variety of other uses of conntrack) for a lot of people following
> > kernel updates in 16.04 LTS so the fix needs to happen there
> > regardless. Right now, basically, Ubuntu Xenial is not a good
> > platform to be running OpenStack on until they get the kernel
> > regression addressed.
> 
> True. Fortunately, the impact is not that catastrophic for Neutron as it
> might seem on the first look. Not sure about the other projects, though.
> Neutron doesn't create conntrack entries in production code - only in
> testing. That said, agents should work just fine even with the
> kernel bug.

-- 
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][infra]Plan to support Python 3.6 ?

[ChangBo Guo]

2017-08-10 0:46 GMT+08:00 Jeremy Stanley :

> On 2017-08-09 09:31:37 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > One of the reasons we were able to move ahead with 3.5 was that it
> > would be available on the platforms for which we test deployments,
> > as defined in the CTI [5]. Are Ubuntu LTS and CentOS shipping
> > Python 3.6?
> [...]
>
> Yes, we ran early 3.3 testing on Ubuntu 12.04 LTS with the aid of
> some backported packages but this was far from ideal. Proper support
> for 3.4 testing came with Ubuntu 14.04 LTS which included it
> directly in the package archive, and then we switched to testing
> against 3.5 when Ubuntu 16.04 became available installing it by
> default. The Ubuntu python3.6 packages started appearing after 16.04
> was out the door, and so looks like it will be generally available
> to us once Ubuntu 18.04 LTS is released and we can start using it as
> a basis for CI jobs (likely in Q2 of next year, so probably during
> OpenStack's "Rocky" release cycle).
> --
>
 yeah, We can migrate to Python 3.6  in Q2 of next year when we have basic
CI jobs.

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


-- 
ChangBo Guo(gcb)
__
OpenStack Development Mailing 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][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[witold.be...@est.fujitsu.com]

Hi Tony,

stable/pike branches for Monasca repos are on the way

https://review.openstack.org/492101

Cheers
Witek



> -Original Message-
> From: Tony Breeds [mailto:t...@bakeyournoodle.com]
> Sent: Donnerstag, 10. August 2017 07:47
> To: OpenStack Development Mailing List  d...@lists.openstack.org>
> Subject: Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality
> Assurance][Security][Telemetry][ec2-
> api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neu
> tron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst
> ...
> 
> 
> Hi All,
> In an effort to qualify which projects are likley to be affected if when 
> we
> open the requirements repo I generated a list of all repos that:
> 
> 1. Subscribe to requirements management
> 2. Do not already have a stable/pike branch 3. Do not follow the cycle-with-
> milestones, cycle-trailing or
>independent release models
> 4. Are not a 'branchless' project (tempest or tempest-plugin)
> 
> These repos I believe *should* have a stable/pike branch or will see
> problems when we open openstack/requirements.  Those issues were
> described in [1]
> 
> It turns out close to 1/3rd of projects that subscribe to requirements
> management are not ready for us to re-open for master.  So we need you
> help to get that number down to a much more acceptable number.
> 
> The good news is it's pretty easy to fix this with the cool tools and workflow
> in the releases repo[2].  I suspect that the 'service' will take care of
> themselves, and the horizon-plugins are waiting to horizon to cut RC1.
> 
> Repos with type: horizon-plugin
> ironic-ui  ironic
> manila-ui  manila
> monasca-ui monasca
> neutron-fwaas-dashboardneutron
> solum-dashboardsolum
> tacker-horizon tacker
> watcher-dashboard  watcher
> zun-ui zun
> 
> Repos with type: other
> python-openstackclient OpenStackClient
> patroleQuality Assurance
> heat-agentsheat
> ironic-inspector   ironic
> ironic-python-agentironic
> kuryr-kubernetes   kuryr
> monasca-common monasca
> monasca-notification   monasca
> monasca-persister  monasca
> monasca-transform  monasca
> 
> Repos with type: service
> ironic ironic
> monasca-apimonasca
> monasca-log-apimonasca
> swift  swift
> tricircle  tricircle
> vitragevitrage
> watcherwatcher
> zunzun
> 
> Those are the easy items.
> 
> The following repos don't seem to use the openstack/releases repo so I have
> less information there.
> 
> i18n   I18n
> almanach
> blazar
> blazar-nova
> compute-hyperv
> ekko
> gce-api
> glare
> ironic-staging-drivers
> kosmos
> masakari
> masakari-monitors
> mixmatch
> mogan
> nemesis
> networking-dpm
> networking-fujitsu
> networking-generic-switch
> networking-l2gw
> networking-powervm
> neutron-vpnaas
> neutron-vpnaas-dashboard
> nova-dpm
> nova-lxd
> nova-powervm
> os-xenapi
> python-blazarclient
> python-cratonclient
> python-glareclient
> python-kingbirdclient
> python-masakariclient
> python-moganclient
> python-oneviewclient
> python-openstacksdk
> python-valenceclient
> swauth
> tap-as-a-service
> trio2o
> valence
> vmware-nsx
> vmware-nsxlib
> openstackclientOpenStackClient
> anchor Security
> ceilometer-powervm Telemetry
> ec2-apiec2-api
> horizon-cisco-ui   horizon
> bifrostironic
> ironic-python-agent-builderironic
> magnum magnum
> magnum-ui  magnum
> manila-image-elements  manila
> murano-agent   murano
> octavia-dashboard  octavia
> senlin-dashboard   senlin
> tacker tacker
> 

Re: [openstack-dev] [ironic] support for various glance image reference formats - do we need them all?

[Pavlo Shchelokovskyy]

HI Dmitry,

On Tue, Aug 8, 2017 at 7:13 PM, Dmitry Tantsur  wrote:

> Hi!
>
> Thanks for raising this.
>
> On 08/07/2017 02:47 PM, Pavlo Shchelokovskyy wrote:
>
>> Hi all,
>>
>> currently our GlanceImageService seems to support several ways of
>> defining a reference to glance image:
>>
>> 1) simple image UUID [0]
>> 2) image UUID prefixed with 'glance://' protocol [1] (well, actually
>> anything starting with 'glance://' and ending with '/')
>> 3) full REST path to the image (as in 
>> http:///v2/images/),
>> also used to extract the glance API address [2]
>>
>> Support for #3 must surely be removed, as we are moving to API endpoint
>> discovery from keystone catalog.
>> Besides I am pretty sure this code path can not actually be reached
>> currently, as the 'is_glance_image' will ignore such image refs and return
>> False for those [3], and 'get_image_service' would also not return the
>> GlanceImageService instance for such image refs [4].
>> Hence the question - if it is unusable anyway now, should we execute the
>> standard deprecation process when removing support for it or just remove
>> right away?
>>
>
> If unsure, always use the standard process ;) Unless somebody is ready to
> set up DevStack, and try it out, and prove that it's completely and
> hopelessly broken.


Did just that [0] - hacked up our tempest configuration so that the 'http'
url for whole disk image used for *HttpLink standalone tests leads to
/v2/images/ [1].
As I kind of expected, both *HttpLink standalone tests failed, right on
validating of the deploy interface when trying to do a HEAD on that URL
instead of 'glance image show', receiving 401 [2].
On a side note, it seems our logging is insufficient in this parts, as I
could not find any relevant logs in ironic-conductor even at debug level,
all that's there are final RPC processing error logs from api.

So I am quite confident that this code paths [3] in service_utils is a dead
end indeed :-/

[0] https://review.openstack.org/#/c/492184/
[1]
http://logs.openstack.org/84/492184/1/check/gate-ironic-dsvm-standalone-ubuntu-xenial/32ea5de/logs/tempest_conf.txt.gz
[2]
http://logs.openstack.org/84/492184/1/check/gate-ironic-dsvm-standalone-ubuntu-xenial/32ea5de/logs/testr_results.html.gz
[3]
https://github.com/openstack/ironic/blob/7e6ce7e78c4378f2f86d085df61a26507a410738/ironic/common/glance_service/service_utils.py#L159-L166


>
>
>> As for the #1 and #2 I do not see any big difference between those, and
>> proposed deprecating and eventually removing support for #2 ('glance://'
>> scheme) as part of [5]. Two people in review already raised a concern about
>> removing such support.
>>
>
> To be honest, I like glance:// more, as it makes it obvious where
> the image is coming from vs http://. I don't mind removing it too much,
> but I guess supporting it is not a lot of code, right?
>

That's not too much burden indeed, as long as we actually do only that - as
I said, right now it is more like "glance:///uuid"


>
>> Thus I'd like to ask a broader audience - do we need support for glance
>> image references in 'glance://*' form? Is it actually used somewhere?
>> What are the benefits of having it besides simple UUID?
>>
>> [0] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>> ommon/glance_service/service_utils.py#n149
>> [1] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>> ommon/glance_service/service_utils.py#n155
>> [2] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>> ommon/glance_service/service_utils.py#n160
>> [3] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>> ommon/glance_service/service_utils.py#n208
>> [4] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/c
>> ommon/image_service.py#n267
>> [5] https://review.openstack.org/#/c/467728
>>
>> Cheers,
>>
>> --
>> Dr. Pavlo Shchelokovskyy
>> Senior Software Engineer
>> Mirantis Inc
>> www.mirantis.com 
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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