Re: [openstack-dev] [oslo][oslo.service] looping.RetryDecorator behavior

[Renat Akhmerov]

Ok, thanks Josh. We switched to tenacity and it works very well for us )

Renat Akhmerov
@Nokia

On 23 Sep 2017, 11:51 +0700, Joshua Harlow , wrote:
> Hi Renat,
>
> I was more just saying that depending on your situation it might be
> better to switch to using tenacity (not that the retry decorator is
> deprecated, though I wouldn't personally use it).
>
> As you mentioned in
> https://bugs.launchpad.net/oslo.service/+bug/1718635/comments/1 this
> class and decorator is not thread safe so if that is a concern for you
> then that is also better in tenacity.
>
> I think a lot of usage of that decorator though is like the following:
>
> def main_func():
>
> @loopingcall.RetryDecorator
> def inner_func():
> 
>  inner_func()
> 
> So likely thread-safety was never a concern, though I can't quite say...
> I think (but I might be wrong) when that class/code was being proposed I
> recommended just using 'retrying' (the precursor to tenacity) but
> bygones be bygones...
>
> Renat Akhmerov wrote:
> > Thanks Josh,
> >
> > I’m not sure I fully understand your point though. You mean it’s a
> > legacy (deprecated?) code that we should never use in our code? Should
> > it be considered a private class of oslo_service?
> >
> > In our global requirements tenacity is configured as "tenacity>=3.2.1”,
> > should we bump it to 4.4.0?
> >
> > Renat Akhmerov
> > @Nokia
> >
> > On 21 Sep 2017, 22:42 +0700, Joshua Harlow , wrote:
> > > It does look like is sort of a bug,
> > >
> > > Though in all honesty I wouldn't be using oslo.service or that looping
> > > code in the future for doing retrying...
> > >
> > > https://pypi.python.org/pypi/tenacity is a much better library with more
> > > `natural` syntax and works more as one would expect (even under threaded
> > > situations).
> > >
> > > If I could of I would of never let 'loopingcall.py' become a file that
> > > exists, but the past is the past, ha.
> > >
> > > Renat Akhmerov wrote:
> > > > Hi Oslo team,
> > > >
> > > > Can you please check the bug [1]?
> > > >
> > > > There may be a problem with how looping.RetryDecorator works. Just
> > > > stumbled on it in Mistral. Not sure if it’s really a bug or made by
> > > > design. If it’s by design then maybe we need to have more accurate
> > > > documentation for it.
> > > >
> > > > FYI: We use this decorator in Mistral and it’s also used in Nova, [2].
> > > >
> > > > [1] https://bugs.launchpad.net/oslo.service/+bug/1718635
> > > > [2]
> > > > http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/disk/mount/api.py
> > > >
> > > > 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 Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder][nova]May I run iscsiadm --op show & update 100 times?

[Rikimaru Honjo]

Hello,

I'd like to discuss about the following bug of os-brick.

* os-brick's iscsi initiator unexpectedly reverts node.startup from "automatic" to 
"manual".
  https://bugs.launchpad.net/os-brick/+bug/1670237

The important point of this bug is:

When os-brick initializes iscsi connections:
1. os-brick will run "iscsiadm -m discovery" command if we use iscsi multipath.
2. os-brick will update node.startup values to "automatic" if we use iscsi.
3. "iscsiadm -m discovery" command will recreate iscsi node repositories.[1]
   As a result, node.startup values of already attached volumes will be revert
   to default(=manual).

Gorka Eguileor and I discussed how do I fix this bug[2].
Our idea is this:

1. Confirm node.startup values of all the iscsi targets before running 
discovery.
2. Re-update node.startup values of all the iscsi targets after running 
discovery.

But, I afraid that this operation will take a long time.
I ran showing & updating node.startup values 100 times for researching.
As a result, it took about 4 seconds.
When I ran 200 times, it took about 8 seconds.
I think this is a little long.

If we use multipath and attach 25 volumes, 100 targets will be created.
I think that updating 100 times is a possible use case.

How do you think about it?
Can I implement the above idea?

[1]This is correct behavior of iscsiadm.
   https://github.com/open-iscsi/open-iscsi/issues/58#issuecomment-325528315
[2]https://bugs.launchpad.net/os-brick/+bug/1670237
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikim...@po.ntt-tx.co.jp



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

[openstack-dev] [zun][neutron] About Notifier

[Hongbin Lu]

Hi Neutron team,

I saw neutron has a Nova notifier [1] that is able to notify Nova via REST API 
when a certain set of events happen. I think Zun would like to be notified as 
how Nova is. For example, we would like to receive notification whenever a port 
assigned to a container has been associated with a floating IP. If I propose a 
Zun notifier (preferably out-of-tree) for that, will you accept the patch? Or 
anyone has an alternative suggestion to stratify our use case.

[1] https://github.com/openstack/neutron/blob/master/neutron/notifiers/nova.py

Best regards,
Hongbin

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

Re: [openstack-dev] [kuryr] vPTG schedule

[Hongbin Lu]

Hi Toni,

The time of a few proposed sessions look inconsistent with the etherpad.
Could you double check?

On Thu, Sep 28, 2017 at 5:48 AM, Antoni Segura Puimedon 
wrote:

> Hi fellow Kuryrs!
>
> It's that time of the cycle again where we hold our virtual project team
> gathering[0]. The dates this time are:
>
> October 2nd, 3rd and 4th
>
> The proposed sessions are:
>
> October 2nd 13:00utc: Scale discussion
> In this session we'll talk about the recent scale testing we have
> performed
> in a 112 node cluster. From this starting point. We'll work on
> identifying
> and prioritizing several initiatives to improve the performance of the
> pod-in-VM and the baremetal scenarios.
>
> October 2nd 14:00utc: Scenario testing
> The September 27th's release of zuulv3 opens the gates for better
> scenario
> testing, specially regarding multinode scenarios. We'll discuss the
> tasks
> and outstanding challenges to achieve good scenario testing coverage
> and
> document well how to write these tests in our tempest plugin.
>
> October 3rd 13:00utc: Multi networks
> As the Kubernetes community Network SIG draws near to having a
> consensus on
> multi network implementations, we must elaborate a plan on a PoC that
> takes
> the upstream Kubernetes consensus and implements it with
> Kuryr-Kubernetes
> in a way that we can serve normal overlay and accelerated networking.
>
> October 4th 14:00utc: Network Policy
> Each cycle we aim to narrow the gap between Kubernetes networking
> entities
> and our translations. In this cycle, apart from the Loadbalancer
> service
> type support, we'll be tackling how we map Network Policy to Neutron
> networking. This session will first lay out Network Policy and its use
> and
> then discuss about one or more mappings.
>
> October 5th 13:00utc: Kuryr-libnetwork
>
This session is Oct 4th in the etherpad.

> We'll do the cycle planing for Kuryr-libnetwork. Blueprints and bugs
> and
> general discussion.
>
> October 6th 14:00utc: Fuxi
>
This session is Oct 4th in the etherpad.

> In this session we'll discuss everything related to storage, both in
> the
> Docker and in the Kubernetes worlds.
>
>
> I'll put the links to the bluejeans sessions in the etherpad[0].
>
>
> [0] https://etherpad.openstack.org/p/kuryr-queens-vPTG
>
> __
> OpenStack Development Mailing 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][elections] Candidate proposals for TC (Technical Committee) positions are now open

[Kendall Nelson]

Hello Again,

A few corrections from the kickoff email:

Candidates for the Technical Committee Positions: Any Foundation individual
member can propose their candidacy for an available, directly-elected TC
seat. (except the seven (7) TC members who were elected for a one-year seat
in April[3]).

The election will be held from September 29th through to 23:45 October 18th,
2017 UTC. PLEASE NOTE, we are discussing adding a few days to the
nomination period  thereby shortening the campaigning period due to the
lack of updates to the governance page and the delayed kickoff email.
Please keep an eye out for updates!

-Kendall Nelson(diablo_rojo)

On Sun, Oct 1, 2017 at 12:29 AM Kendall Nelson 
wrote:

> Hello Everyone :)
>
> Candidate proposals for the Technical Committee positions (6 positions)
> are now open and will remain open until 2017-10-08, 23:45 UTC
>
> All candidacies must be submitted as a text file to the openstack/election
> repository as explained on the election website[1].
> Please note that the name of the file has changed this cycle to be the
> candidates IRC nic *not* full-name.
>
> Also for TC candidates election officials refer to the community member
> profiles at [2] please take this opportunity to ensure that the you profile
> contains current information.
>
> Candidates for the Technical Committee Positions: Any Foundation
> individual member can propose their candidacy for an available,
> directly-elected TC seat. (except the six (6) TC members who were elected
> for a one-year seat in October[3]).
>
> The election will be held from March 30th through to 23:45 October 8th,
> 2017 UTC. The electorate are the Foundation individual members that are
> also committers for one of the official programs projects[4] over the 
> Ocata-Pike
> timeframe (September, 2016 23:59 UTC to August 3rd , 2017 23:59 UTC, as
> well as the extra-ATCs who are acknowledged by the TC[5].
>
> Please see the website[1] for additional details about this election.
> Please find below the timeline:
>
> TC nomination starts   @ 2017-09-29, 23:59 UTC
> TC nomination ends @ 2017-10-08, 23:45 UTC
> TC elections starts@ 2017-10-12, 23:59 UTC
> TC elections ends  @ 2017-10-18, 23:45 UTC
>
> If you have any questions please be sure to either voice them on the
> mailing list or to the elections officials[6].
>
> Thank you, and we look forward to reading your candidate proposals,
> -Kendall Nelson (diablo_rojo)
>
> [1] http://governance.openstack.org/election/#how-to-submit-your-candidacy
> [2] http://www.openstack.org/community/members/
> [3] https://governance.openstack.org/election/results/ocata/tc.html
> [4]
> https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=
> 
> oct
> 
> -2017-elections
> 
> [5] Look for the extra-atcs element in [4]
> [6] http://governance.openstack.org/election/#election-officials
>
__
OpenStack Development Mailing 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] [monasca] Stefano Canepa and Dobrosław Żybort in Monasca core team

[Stefano Canepa]

On Tue, Sep 26, 2017 at 11:26:55AM +, Bedyk, Witold wrote:
> Hello everyone,
> 
> I would like to nominate Stefano Canepa and Dobrosław Żybort to Monasca core 
> reviewers team.
> Welcome and thank you for your contribution to the project.
> 
> 
> Best regards
> Witek

Thanks Witek.

Bye
sc

-- 
Stefano Canepa

Three great virtues of a programmer: laziness, impatience, and hubris.
(Larry Wall)


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] [infra] pypi publishing

[Paul Belanger]

On Sun, Oct 01, 2017 at 05:02:00AM -0700, Clark Boylan wrote:
> On Sat, Sep 30, 2017, at 10:28 PM, Gary Kotton wrote:
> > Hi,
> > Any idea why latest packages are not being published to pypi.
> > Examples are:
> > vmware-nsxlib 10.0.2 (latest stable/ocata)
> > vmware-nsxlib 11.0.1 (latest stable/pike)
> > vmware-nsxlib 11.1.0 (latest queens)
> > Did we miss a configuration that we needed to do in the infra projects?
> > Thanks
> > Gary
> 
> Looks like these are all new tags pushed within the last day. Looking at
> logs for 11.1.1 we see the tarball artifact creation failed [0] due to
> what is likely a bug in the new zuulv3 jobs.
> 
> [0]
> http://logs.openstack.org/e5/e5a2189276396201ad88a6c47360c90447c91589/release/publish-openstack-python-tarball/2bdd521/ara/result/6ec8ae45-7266-40a9-8fd5-3fb4abcde677/
> 
> We'll need to get the jobs debugged.
> 
This is broken because of: https://review.openstack.org/508563/

__
OpenStack Development Mailing 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] [infra] Zull retry limit

[Gary Kotton]

Thanks!

On 10/1/17, 8:23 PM, "Clark Boylan"  wrote:

On Sun, Oct 1, 2017, at 10:19 AM, Gary Kotton wrote:
> Hi,
> Is this an example of the solution that you are proposing -
> https://review.openstack.org/#/c/508775/. I also read that we should
> create a .zuul.yaml file. Not sure what the correct thing to do is.
> Please advise.
> Thanks
> Gary
> 

Yes 508775 is an example of what you should do. Adding a .zuul.yaml file
is something you can do but not necessary to correct this problem. You
would use a repo local .zuul.yaml file to add new jobs to your project.

Clark

__
OpenStack Development Mailing 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] [infra] Zull retry limit

[Clark Boylan]

On Sun, Oct 1, 2017, at 10:19 AM, Gary Kotton wrote:
> Hi,
> Is this an example of the solution that you are proposing -
> https://review.openstack.org/#/c/508775/. I also read that we should
> create a .zuul.yaml file. Not sure what the correct thing to do is.
> Please advise.
> Thanks
> Gary
> 

Yes 508775 is an example of what you should do. Adding a .zuul.yaml file
is something you can do but not necessary to correct this problem. You
would use a repo local .zuul.yaml file to add new jobs to your project.

Clark

__
OpenStack Development Mailing 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] [infra] Zull retry limit

[Gary Kotton]

Hi,
Is this an example of the solution that you are proposing - 
https://review.openstack.org/#/c/508775/. I also read that we should create a 
.zuul.yaml file. Not sure what the correct thing to do is.
Please advise.
Thanks
Gary

On 10/1/17, 3:10 PM, "Clark Boylan"  wrote:

On Sat, Sep 30, 2017, at 11:23 PM, Gary Kotton wrote:
> Hi,
> It seems like all patches are hitting this issue – “RETRY_LIMIT in 5m
> 35s”. Any idea? Is this specific to vmware-nsx or all projects?
> Did we miss doing an update for zuulv3?
>

This is specific to certain jobs. You can see general live status to
compare against global state at http://status.openstack.org/zuul. In
this particular case the job has attempted to provide a helpful error
message [0]. You should be able to create an openstack-tox-pep8 job
variant for vmware-nsx that includes neutron as a required project.
Documentation for how to go about that can be found at [1].

This does raise the question of why vmware-nsx needs to install neutron
to run pep8 though.

[0]

http://logs.openstack.org/30/508130/3/check/openstack-tox-pep8/7cb51cb/job-output.txt.gz#_2017-10-01_07_24_29_980352
[1] https://docs.openstack.org/infra/manual/zuulv3.html

Hope this helps,
Clark

__
OpenStack Development Mailing 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] [puppet] avoid rechecks

[Mohammed Naser]

Hi everyone,

As the Puppet modules CI is still in the process of getting plumbed
properly with Zuul v3, you'll notice many of your checks failing.  If
you notice a job that has a legacy- prefix, it is probably not
migrated yet and will likely fail, therefore, I'd avoid a recheck to
avoid taking up resources for a job that will fail.

If none of your jobs are prefixed with legacy- then you can do the
normal troubleshooting and recheck if it is a timeout of the job or a
connectivity issue.

I'll keep everyone updated at the progress of moving things over.

Thanks,
Mohammed

__
OpenStack Development Mailing 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] [infra] Zull retry limit

[Clark Boylan]

On Sat, Sep 30, 2017, at 11:23 PM, Gary Kotton wrote:
> Hi,
> It seems like all patches are hitting this issue – “RETRY_LIMIT in 5m
> 35s”. Any idea? Is this specific to vmware-nsx or all projects?
> Did we miss doing an update for zuulv3?
>

This is specific to certain jobs. You can see general live status to
compare against global state at http://status.openstack.org/zuul. In
this particular case the job has attempted to provide a helpful error
message [0]. You should be able to create an openstack-tox-pep8 job
variant for vmware-nsx that includes neutron as a required project.
Documentation for how to go about that can be found at [1].

This does raise the question of why vmware-nsx needs to install neutron
to run pep8 though.

[0]
http://logs.openstack.org/30/508130/3/check/openstack-tox-pep8/7cb51cb/job-output.txt.gz#_2017-10-01_07_24_29_980352
[1] https://docs.openstack.org/infra/manual/zuulv3.html

Hope this helps,
Clark

__
OpenStack Development Mailing 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] [infra] pypi publishing

[Clark Boylan]

On Sat, Sep 30, 2017, at 10:28 PM, Gary Kotton wrote:
> Hi,
> Any idea why latest packages are not being published to pypi.
> Examples are:
> vmware-nsxlib 10.0.2 (latest stable/ocata)
> vmware-nsxlib 11.0.1 (latest stable/pike)
> vmware-nsxlib 11.1.0 (latest queens)
> Did we miss a configuration that we needed to do in the infra projects?
> Thanks
> Gary

Looks like these are all new tags pushed within the last day. Looking at
logs for 11.1.1 we see the tarball artifact creation failed [0] due to
what is likely a bug in the new zuulv3 jobs.

[0]
http://logs.openstack.org/e5/e5a2189276396201ad88a6c47360c90447c91589/release/publish-openstack-python-tarball/2bdd521/ara/result/6ec8ae45-7266-40a9-8fd5-3fb4abcde677/

We'll need to get the jobs debugged.

Clark

__
OpenStack Development Mailing 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][elections] Candidate proposals for TC (Technical Committee) positions are now open

[Kendall Nelson]

Hello Everyone :)

Candidate proposals for the Technical Committee positions (6 positions) are
now open and will remain open until 2017-10-08, 23:45 UTC

All candidacies must be submitted as a text file to the openstack/election
repository as explained on the election website[1].
Please note that the name of the file has changed this cycle to be the
candidates IRC nic *not* full-name.

Also for TC candidates election officials refer to the community member
profiles at [2] please take this opportunity to ensure that the you profile
contains current information.

Candidates for the Technical Committee Positions: Any Foundation individual
member can propose their candidacy for an available, directly-elected TC
seat. (except the six (6) TC members who were elected for a one-year seat
in October[3]).

The election will be held from March 30th through to 23:45 October 8th,
2017 UTC. The electorate are the Foundation individual members that are
also committers for one of the official programs projects[4] over the
Ocata-Pike
timeframe (September, 2016 23:59 UTC to August 3rd , 2017 23:59 UTC, as
well as the extra-ATCs who are acknowledged by the TC[5].

Please see the website[1] for additional details about this election.
Please find below the timeline:

TC nomination starts   @ 2017-09-29, 23:59 UTC
TC nomination ends @ 2017-10-08, 23:45 UTC
TC elections starts@ 2017-10-12, 23:59 UTC
TC elections ends  @ 2017-10-18, 23:45 UTC

If you have any questions please be sure to either voice them on the
mailing list or to the elections officials[6].

Thank you, and we look forward to reading your candidate proposals,
-Kendall Nelson (diablo_rojo)

[1] http://governance.openstack.org/election/#how-to-submit-your-candidacy
[2] http://www.openstack.org/community/members/
[3] https://governance.openstack.org/election/results/ocata/tc.html
[4]
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=

oct

-2017-elections

[5] Look for the extra-atcs element in [4]
[6] http://governance.openstack.org/election/#election-officials
__
OpenStack Development Mailing 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] [infra] Zull retry limit

[Gary Kotton]

Hi,
It seems like all patches are hitting this issue – “RETRY_LIMIT in 5m 35s”. Any 
idea? Is this specific to vmware-nsx or all projects?
Did we miss doing an update for zuulv3?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev