Re: [openstack-dev] [neutron][graphql] PoC with Oslo integration

[Gilles Dubreuil]

Hi,

We're going to reschedule this one.

Sorry for the inconvenience.

Regards,
Gilles


On 02/07/18 15:17, Gilles Dubreuil wrote:

Hi,

We now have an initial base for using GraphQL [1] as you can see from 
[2].

What we need now is too use Oslo properly to police the requests.

The best way to achieve that would likely to use a similar approach as 
the pecan hooks which are in place for v2.0.
Ultimately some of the code could be share between v2.0 and graphql 
but that's not a goal or either a priority for now.


We need Neutron developers to help with the design and to get this 
moving in the right direction.


I'm scheduling an on-line working session for next week (using either 
BlueJeans or Google Hangouts)?
Please vote on doodle [2] on the best time for you (please understand 
that we have to cover all time zones).


Thanks,
Gilles

[1] https://storyboard.openstack.org/#!/story/2002782
[2] https://review.openstack.org/#/c/575898/
[3] https://doodle.com/poll/43kx8nfpe6w6pvia



--
Gilles Dubreuil
Senior Software Engineer - Red Hat - Openstack DFG Integration
Email: gil...@redhat.com
GitHub/IRC: gildub
Mobile: +61 400 894 219


__
OpenStack Development Mailing 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] Clearing out old gerrit reviews

[Renat Akhmerov]

Dougal, I’m totally OK with this idea.

Thanks

Renat Akhmerov
@Nokia
On 9 Jul 2018, 22:14 +0700, Dougal Matthews , wrote:
> Hey folks,
>
> I'd like to propose that we start abandoning old Gerrit reviews.
>
> This report shows how stale and out of date some of the reviews are:
> http://stackalytics.com/report/reviews/mistral-group/open
>
> I would like to initially abandon anything without any activity for a year, 
> but we might want to consider a shorter limit - maybe 6 months. Reviews can 
> be restored, so the risk is low.
>
> What do you think? Any objections or counter suggestions?
>
> If I don't hear any complaints, I'll go ahead with this next week (or maybe 
> the following week).
>
> Cheers,
> Dougal
> __
> OpenStack Development Mailing 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] [puppet] puppet-senlin development

[Emilien Macchi]

Also please take a look at this guide to create new modules:
https://docs.openstack.org/puppet-openstack-guide/latest/contributor/new-module.html

Thanks and welcome!

On Mon, Jul 9, 2018 at 1:46 PM Tobias Urdin 
wrote:

> Hello Alex,
>
> I personally don’t know about any entity specifically working on the
> Puppet Senlin module.
>
> We strongly welcome anybody to contribute to the development of the Puppet
> OpenStack modules.
>
> We are happy to help :)
>
> Best regards
> Tobias
>
> Sent from my iPhone
>
> On 9 Jul 2018, at 16:00, Alexandru Sorodoc  wrote:
>
> Hello,
>
> Is anyone working or planning to work on the puppet-senlin module? We want
> to use Senlin in our Pike deployment and we are considering contributing to
> its puppet module to bring it to a working state.
>
> Best regards,
> Alex
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

Re: [openstack-dev] [stestr?][tox?][infra?] Unexpected success isn't a failure

[Matthew Treinish]

On Mon, Jul 09, 2018 at 06:59:42PM -0500, Eric Fried wrote:
> In gabbi, there's a way [1] to mark a test as an expected failure, which
> makes it show up in your stestr run thusly:
> 
> {0}
> nova.tests.functional.api.openstack.placement.test_placement_api.allocations-1.28_put_that_allocation_to_new_consumer.test_request
> [0.710821s] ... ok
> 
> ==
> Totals
> ==
> Ran: 1 tests in 9. sec.
>  - Passed: 0
>  - Skipped: 0
>  - Expected Fail: 1
>  - Unexpected Success: 0
>  - Failed: 0
> 
> If I go fix the thing causing the heretofore-expected failure, but
> forget to take out the `xfail: True`, it does this:
> 
> {0}
> nova.tests.functional.api.openstack.placement.test_placement_api.allocations-1.28_put_that_allocation_to_new_consumer.test_request
> [0.710517s] ... FAILED
> {0}
> nova.tests.functional.api.openstack.placement.test_placement_api.allocations-1.28_put_that_allocation_to_new_consumer.test_request
> [0.00s] ... ok
> 
> ==
> Failed 1 tests - output below:
> ==
> 
> nova.tests.functional.api.openstack.placement.test_placement_api.allocations-1.28_put_that_allocation_to_new_consumer.test_request
> --
> 
> 
> ==
> Totals
> ==
> Ran: 2 tests in 9. sec.
>  - Passed: 1
>  - Skipped: 0
>  - Expected Fail: 0
>  - Unexpected Success: 1
>  - Failed: 0
> 
> BUT it does not cause the run to fail. For example, see the
> nova-tox-functional results for [2] (specifically PS4): the test appears
> twice in the middle of the run [3] and prints failure output [4] but the
> job passes [5].
> 
> So I'm writing this email because I have no idea if this is expected
> behavior or a bug (I'm hoping the latter, cause it's whack, yo); and if
> a bug, I have no idea whose bug it should be. Help?
It's definitely  a bug, and likely a bug in stestr (or one of the lower level
packages like testtools or python-subunit), because that's what's generating
the return code. Tox just looks at the return code from the commands to figure
out if things were successful or not. I'm a bit surprised by this though I
thought we covered the unxsuccess and xfail cases because I would have expected
cdent to file a bug if it didn't. Looking at the stestr tests we don't have
coverage for the unxsuccess case so I can see how this slipped through.

Looking at the where the return code for the output from the run command is
generated (it's a bit weird because run calls the load command internally which
handles the output generation, result storage, and final return code):

https://github.com/mtreinish/stestr/blob/master/stestr/commands/load.py#L222-L225

I'm thinking it might be an issue in testtools or python-subunit, I don't 
remember
which generates the results object used there (if it is subunit it'll be a
subclass from testtools). But I'll have to trace through it to be sure. In the
mean time we can easily workaround the issue in stestr itself by just manually
checking the result status instead of relying on the existing function from the
results class.

-Matt Treinish

> 
> [1] https://gabbi.readthedocs.io/en/latest/format.html?highlight=xfail
> [2] https://review.openstack.org/#/c/579921/4
> [3]
> http://logs.openstack.org/21/579921/4/check/nova-tox-functional/5fb6ee9/job-output.txt.gz#_2018-07-09_17_22_11_846366
> [4]
> http://logs.openstack.org/21/579921/4/check/nova-tox-functional/5fb6ee9/job-output.txt.gz#_2018-07-09_17_31_07_229271
> [5]
> http://logs.openstack.org/21/579921/4/check/nova-tox-functional/5fb6ee9/testr_results.html.gz
> 


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

[openstack-dev] [stestr?][tox?][infra?] Unexpected success isn't a failure

[Eric Fried]

In gabbi, there's a way [1] to mark a test as an expected failure, which
makes it show up in your stestr run thusly:

{0}
nova.tests.functional.api.openstack.placement.test_placement_api.allocations-1.28_put_that_allocation_to_new_consumer.test_request
[0.710821s] ... ok

==
Totals
==
Ran: 1 tests in 9. sec.
 - Passed: 0
 - Skipped: 0
 - Expected Fail: 1
 - Unexpected Success: 0
 - Failed: 0

If I go fix the thing causing the heretofore-expected failure, but
forget to take out the `xfail: True`, it does this:

{0}
nova.tests.functional.api.openstack.placement.test_placement_api.allocations-1.28_put_that_allocation_to_new_consumer.test_request
[0.710517s] ... FAILED
{0}
nova.tests.functional.api.openstack.placement.test_placement_api.allocations-1.28_put_that_allocation_to_new_consumer.test_request
[0.00s] ... ok

==
Failed 1 tests - output below:
==

nova.tests.functional.api.openstack.placement.test_placement_api.allocations-1.28_put_that_allocation_to_new_consumer.test_request
--


==
Totals
==
Ran: 2 tests in 9. sec.
 - Passed: 1
 - Skipped: 0
 - Expected Fail: 0
 - Unexpected Success: 1
 - Failed: 0

BUT it does not cause the run to fail. For example, see the
nova-tox-functional results for [2] (specifically PS4): the test appears
twice in the middle of the run [3] and prints failure output [4] but the
job passes [5].

So I'm writing this email because I have no idea if this is expected
behavior or a bug (I'm hoping the latter, cause it's whack, yo); and if
a bug, I have no idea whose bug it should be. Help?

Thanks,
efried

[1] https://gabbi.readthedocs.io/en/latest/format.html?highlight=xfail
[2] https://review.openstack.org/#/c/579921/4
[3]
http://logs.openstack.org/21/579921/4/check/nova-tox-functional/5fb6ee9/job-output.txt.gz#_2018-07-09_17_22_11_846366
[4]
http://logs.openstack.org/21/579921/4/check/nova-tox-functional/5fb6ee9/job-output.txt.gz#_2018-07-09_17_31_07_229271
[5]
http://logs.openstack.org/21/579921/4/check/nova-tox-functional/5fb6ee9/testr_results.html.gz

__
OpenStack Development Mailing 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] [dib] pip-and-virtualenv element failing on CentOS

[Sai Sindhur Malleni]

Hi all,

I raised https://bugs.launchpad.net/diskimage-builder/+bug/1768135 a while
ago as CentOS images using pip-and-virtual-env elements are failing to
build. While exporting DIB_INSTALLTYPE_pip_and_virtualenv=package helps
workaround the issue, this wasn't needed earlier.  Would really appreciate
any help from the dib community to debug/fix this issue.

-- 
Sai Sindhur Malleni

Software Engineer
Red Hat Inc.
100 East Davie Street
Raleigh, NC, USA
Work: (919) 754-4557 | Cell: (919) 985-1055
__
OpenStack Development Mailing 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] [python3][tc][infra][docs] changing the documentation build PTI to use tox

[James E. Blair]

Doug Hellmann  writes:

> Excerpts from Zane Bitter's message of 2018-07-09 11:04:28 -0400:
>> On 05/07/18 16:46, Doug Hellmann wrote:
>> > I have a governance patch up [1] to change the project-testing-interface
>> > (PTI) for building documentation to restore the use of tox.
>> > 
>> > We originally changed away from tox because we wanted to have a
>> > single standard command that anyone could use to build the documentation
>> > for a project. It turns out that is more complicated than just
>> > running sphinx-build in a lot of cases anyway, because of course
>> > you have a bunch of dependencies to install before sphinx-build
>> > will work.
>> 
>> Is this the main reason? If we think we made the wrong call (i.e. 
>> everyone has to set up a virtualenv and install doc/requirements.txt 
>> anyway so we should just make them use tox even if they are not Python 
>> projects), then I agree it makes sense to fix it even though we only 
>> _just_ finished telling people it would be the opposite way.
>
> Yes, we made the wrong call when we set the PTI to not use tox for these
> cases.
>
>> > Updating the job that uses sphinx directly to run under python 3,
>> > while allowing the transition to be self-testing, was going to
>> > require writing some extra complexity to look at something in the
>> > repository to decide what version of python to use.  Since tox
>> > handles that for us by letting us set basepython in the virtualenv
>> > configuration, it seemed more straightforward to go back to using
>> > tox.
>> 
>> Wouldn't another option be to have separate Zuul jobs for Python 3 and 
>> Python 2-based sphinx builds? Then the switchover would still be 
>> self-testing.
>> 
>> I'd rather do that if this is the main problem we're trying to solve, 
>> rather than reverse course.
>
> These jobs run on tag events, which are not "branch aware" (tags
> can be on 0 or more branches at the same time). That means we cannot
> have different versions of the job running for different branches.
>
> Instead we need 1 job, which uses data inside the repository to
> decide exactly what to do. Instead of writing a new, more complicated,
> job to look at a flag file or other settings to decide whether to
> run sphinx under python 2 or 3, it will be simpler to go back to
> using the old existing tox-based job and to use the tox configuration
> to control the version of python. Using the tox job also has the
> benefit of fixing the tox-siblings issue for projects like neutron
> plugins that need neutron installed in order to generate their
> documentation. So we fix 2 problems with 1 change.
>
> We actually have a similar problem for the release job, but in that
> case we don't need tox because we don't need to install any
> dependencies in order to build the artifacts.  I have tested building
> sdists and wheels from every repo with a setup.py and did not find
> any failures related to using python 3, so we can just switch
> everyone over to use the new job.

Indeed, this is a situation where in many cases our intuition collides
with git's implementation.  We've always had this restriction with Zuul
(we can cause different jobs to run for different tags, but we can only
do so by matching the name of the tag, not the name of the branch that
people associate with the tag).  If we were very consistent about
release version numbers and branches across projects, we could write
some configuration which ran python2 jobs on some releases and python3
jobs on others.  But we aren't in that position, and doing so would
require a jumble of regexes, different for each project.

In Zuul v3, since much of the configuration is in-repo, the desire to
alter tag/release jobs based on the content in-repo is even closer to
the surface.  So the desire to handle this situation better is growing,
and I think stands on its own merit.  To that end, we've started
exploring some changes to Zuul in that direction.  One of them is here:
https://review.openstack.org/578557

But, even if we do land that change, I think the PTI change that Doug is
proposing is the best thing for us to do in this situation.  We made the
PTI so that we have a really simple interface and line of demarcation
where we say that, collectively, we want all projects to be able to
build docs, and we're going to build a bunch of automation around that,
but the PTI is the boundary between that automation and the in-repo
content.  It has served us very well through a number of changes to how
we run unit tests.  The fact that we've gone through far fewer changes
to how docs are built has perhaps led us to think that we didn't need
the layer of abstraction that tox provided us.  However, as soon as we
removed it, we encountered a situation where, in fact, it would have
insulated us.

Put another way, I think the spirit of the PTI is about finding the
right place where the automation that we build for all the projects
stops, and the project-specific implementation begins.  Facilitating a

Re: [openstack-dev] Fwd: [TIP] tox release 3.1.1

[Doug Hellmann]

Excerpts from Ben Nemec's message of 2018-07-09 15:42:02 -0500:
> 
> On 07/09/2018 11:16 AM, Eric Fried wrote:
> > Doug-
> > 
> > How long til we can start relying on the new behavior in the gate?  I
> > gots me some basepython to purge...
> 
> I want to point out that most projects require a rather old version of 
> tox, so chances are most people are not staying up to date with the very 
> latest version.  I don't love the repetition in tox.ini right now, but I 
> also don't love that immediately bumping the lower bound for tox is 
> going to be kind of disruptive to a lot of people.
> 
> 1: http://codesearch.openstack.org/?q=minversion=nope=tox.ini=

Good point. Any patches to clean up the repetition should probably
go ahead and update that minimum version setting, too.

Doug

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

Re: [openstack-dev] Fwd: [TIP] tox release 3.1.1

[Ben Nemec]

On 07/09/2018 11:16 AM, Eric Fried wrote:

Doug-

How long til we can start relying on the new behavior in the gate?  I
gots me some basepython to purge...


I want to point out that most projects require a rather old version of 
tox, so chances are most people are not staying up to date with the very 
latest version.  I don't love the repetition in tox.ini right now, but I 
also don't love that immediately bumping the lower bound for tox is 
going to be kind of disruptive to a lot of people.


1: http://codesearch.openstack.org/?q=minversion=nope=tox.ini=



-efried

On 07/09/2018 11:03 AM, Doug Hellmann wrote:

Heads-up, there is a new tox release out. 3.1 includes some behavior
changes in the way basepython behaves (thanks, Stephen Finucan!), as
well as other bug fixes.

If you start seeing odd job failures, check your tox version.

Doug

--- Begin forwarded message from toxdevorg ---
From: toxdevorg 
To: testing-in-python , tox-dev 

Date: Mon, 09 Jul 2018 08:45:15 -0700
Subject: [TIP] tox release 3.1.1

The tox team is proud to announce the 3.1.1 bug fix release!

tox aims to automate and standardize testing in Python. It is part of
a larger vision of easing the packaging, testing and release process
of Python software.

For details about the fix(es),please check the CHANGELOG:
https://pypi.org/project/tox/3.1.1/#changelog

We thank all present and past contributors to tox. Have a look at
https://github.com/tox-dev/tox/blob/master/CONTRIBUTORS to see who
contributed.

Happy toxing,
the tox-dev team

--- End forwarded message ---

__
OpenStack Development Mailing 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] [requirements][taskflow] networkx migration

[Matthew Thode]

We have a patch that looks good, can we get it merged?

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

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [puppet][tripleo] Why is this acceptance test failing?

[Emilien Macchi]

On Wed, Jul 4, 2018 at 9:53 PM Lars Kellogg-Stedman  wrote:

> On Wed, Jul 04, 2018 at 07:51:20PM -0600, Emilien Macchi wrote:
> > The actual problem is that the manifest isn't idempotent anymore:
> >
> http://logs.openstack.org/47/575147/16/check/puppet-openstack-beaker-centos-7/3f70cc9/job-output.txt.gz#_2018-07-04_00_42_19_705516
>
> Hey Emilien, thanks for taking a look. I'm not following -- or maybe
> I'm just misreading the failure message.  It really looks to me as if
> the failure is caused by a regular expression; it says:
>
>   Failure/Error:
> apply_manifest(pp, :catch_changes => true) do |result|
>   expect(result.stderr)
> .to
> include_regexp([/Puppet::Type::Keystone_tenant::ProviderOpenstack: Support
> for a resource without the domain.*using 'Default'.*default domain id is
> '/])
> end
>
> And yet, the regular expression in that check clearly matches the
> output shown in the failure message. What do you see that points at an
> actual idempotency issue?
>
> (I wouldn't be at all surprised to find an actual problem in this
> change; I've fixed several already.  I'm just not sure how to turn
> this failure into actionable information.)
>

Sorry for late answers, not doing a good job at catching up emails since I
was 2 weeks on PTO.

So in order to test if that comes from your code or not, please try the
manifest yourself and run puppet 2 times. If the second time is still
triggering changes in the catalog, it means the idempotency of the resource
is broken, which can also mean the resource itself isn't created properly
the first time and a second puppet run tries to create it again.

Basically, you shouldn't see that on a second puppet run:
/Stage[main]/Keystone/Keystone_domain[my_default_domain]/is_default:
is_default changed 'false' to 'true'

If you can't reproduce it, let me know on IRC and I'll help you but you
could use
https://github.com/openstack/puppet-openstack-integration/blob/master/all-in-one.sh
if you need a quick way to deploy.

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

Re: [openstack-dev] Fwd: [TIP] tox release 3.1.1

[Paul Belanger]

On Mon, Jul 09, 2018 at 01:44:00PM -0400, Doug Hellmann wrote:
> Excerpts from Eric Fried's message of 2018-07-09 11:16:11 -0500:
> > Doug-
> > 
> > How long til we can start relying on the new behavior in the gate?  I
> > gots me some basepython to purge...
> > 
> > -efried
> 
> Great question. I have to defer to the infra team to answer, since I'm
> not sure how we're managing the version of tox we use in CI.
> 
Should be less then 24 hours, likely sooner. We pull in the latest tox when we
rebuild images each day[1].

[1] 
http://git.openstack.org/cgit/openstack-infra/project-config/tree/nodepool/elements/infra-package-needs/install.d/10-pip-packages

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

Re: [openstack-dev] [nova] [placement] placement update 18-27

[Chris Dent]

On Fri, 6 Jul 2018, Chris Dent wrote:


This is placement update 18-27, a weekly update of ongoing
development related to the [OpenStack](https://www.openstack.org/)
[placement
service](https://developer.openstack.org/api-ref/placement/). This
is a contract version.


Forgot to mention: There won't be an 18-28 this Friday, I'll be out
and about. If someone else would like to do one, that would be
great.

--
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] [puppet] puppet-senlin development

[Tobias Urdin]

Hello Alex,

I personally don't know about any entity specifically working on the Puppet 
Senlin module.

We strongly welcome anybody to contribute to the development of the Puppet 
OpenStack modules.

We are happy to help :)

Best regards
Tobias

Sent from my iPhone

On 9 Jul 2018, at 16:00, Alexandru Sorodoc 
mailto:a...@privacysystems.eu>> wrote:


Hello,

Is anyone working or planning to work on the puppet-senlin module? We want to 
use Senlin in our Pike deployment and we are considering contributing to its 
puppet module to bring it to a working state.

Best regards,
Alex

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing 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] Fwd: [TIP] tox release 3.1.1

[Doug Hellmann]

Excerpts from Eric Fried's message of 2018-07-09 11:16:11 -0500:
> Doug-
> 
> How long til we can start relying on the new behavior in the gate?  I
> gots me some basepython to purge...
> 
> -efried

Great question. I have to defer to the infra team to answer, since I'm
not sure how we're managing the version of tox we use in CI.

Doug

> 
> On 07/09/2018 11:03 AM, Doug Hellmann wrote:
> > Heads-up, there is a new tox release out. 3.1 includes some behavior
> > changes in the way basepython behaves (thanks, Stephen Finucan!), as
> > well as other bug fixes.
> > 
> > If you start seeing odd job failures, check your tox version.
> > 
> > Doug
> > 
> > --- Begin forwarded message from toxdevorg ---
> > From: toxdevorg 
> > To: testing-in-python , tox-dev 
> > 
> > Date: Mon, 09 Jul 2018 08:45:15 -0700
> > Subject: [TIP] tox release 3.1.1
> > 
> > The tox team is proud to announce the 3.1.1 bug fix release!
> > 
> > tox aims to automate and standardize testing in Python. It is part of
> > a larger vision of easing the packaging, testing and release process
> > of Python software.
> > 
> > For details about the fix(es),please check the CHANGELOG:
> > https://pypi.org/project/tox/3.1.1/#changelog
> > 
> > We thank all present and past contributors to tox. Have a look at
> > https://github.com/tox-dev/tox/blob/master/CONTRIBUTORS to see who
> > contributed.
> > 
> > Happy toxing,
> > the tox-dev team
> > 
> > --- End forwarded message ---
> > 
> > __
> > OpenStack Development Mailing 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] Reminder: UC Meeting Today 1800UTC / 1300CST

[Melvin Hillsman]

Hey everyone,

Please see https://wiki.openstack.org/wiki/Governance/Foundation/Us
erCommittee for UC meeting info and add additional agenda items if needed.

-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646

>
__
OpenStack Development Mailing 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] [manila] Planning Etherpad for Denver 2018 PTG

[Tom Barron]

Here's an etherpad we can use for planning for the Denver PTG in 
September [1].  Please add topics as they occur to you!


-- Tom Barron (tbarron)

[1] https://etherpad.openstack.org/p/manila-ptg-planning-denver-2018


__
OpenStack Development Mailing 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] Fwd: [TIP] tox release 3.1.1

[Eric Fried]

Doug-

How long til we can start relying on the new behavior in the gate?  I
gots me some basepython to purge...

-efried

On 07/09/2018 11:03 AM, Doug Hellmann wrote:
> Heads-up, there is a new tox release out. 3.1 includes some behavior
> changes in the way basepython behaves (thanks, Stephen Finucan!), as
> well as other bug fixes.
> 
> If you start seeing odd job failures, check your tox version.
> 
> Doug
> 
> --- Begin forwarded message from toxdevorg ---
> From: toxdevorg 
> To: testing-in-python , tox-dev 
> 
> Date: Mon, 09 Jul 2018 08:45:15 -0700
> Subject: [TIP] tox release 3.1.1
> 
> The tox team is proud to announce the 3.1.1 bug fix release!
> 
> tox aims to automate and standardize testing in Python. It is part of
> a larger vision of easing the packaging, testing and release process
> of Python software.
> 
> For details about the fix(es),please check the CHANGELOG:
> https://pypi.org/project/tox/3.1.1/#changelog
> 
> We thank all present and past contributors to tox. Have a look at
> https://github.com/tox-dev/tox/blob/master/CONTRIBUTORS to see who
> contributed.
> 
> Happy toxing,
> the tox-dev team
> 
> --- End forwarded message ---
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

[openstack-dev] Fwd: [TIP] tox release 3.1.1

[Doug Hellmann]

Heads-up, there is a new tox release out. 3.1 includes some behavior
changes in the way basepython behaves (thanks, Stephen Finucan!), as
well as other bug fixes.

If you start seeing odd job failures, check your tox version.

Doug

--- Begin forwarded message from toxdevorg ---
From: toxdevorg 
To: testing-in-python , tox-dev 

Date: Mon, 09 Jul 2018 08:45:15 -0700
Subject: [TIP] tox release 3.1.1

The tox team is proud to announce the 3.1.1 bug fix release!

tox aims to automate and standardize testing in Python. It is part of
a larger vision of easing the packaging, testing and release process
of Python software.

For details about the fix(es),please check the CHANGELOG:
https://pypi.org/project/tox/3.1.1/#changelog

We thank all present and past contributors to tox. Have a look at
https://github.com/tox-dev/tox/blob/master/CONTRIBUTORS to see who
contributed.

Happy toxing,
the tox-dev team

--- End forwarded message ---

__
OpenStack Development Mailing 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] [python3][tc][infra][docs] changing the documentation build PTI to use tox

[Doug Hellmann]

Excerpts from Zane Bitter's message of 2018-07-09 11:04:28 -0400:
> On 05/07/18 16:46, Doug Hellmann wrote:
> > I have a governance patch up [1] to change the project-testing-interface
> > (PTI) for building documentation to restore the use of tox.
> > 
> > We originally changed away from tox because we wanted to have a
> > single standard command that anyone could use to build the documentation
> > for a project. It turns out that is more complicated than just
> > running sphinx-build in a lot of cases anyway, because of course
> > you have a bunch of dependencies to install before sphinx-build
> > will work.
> 
> Is this the main reason? If we think we made the wrong call (i.e. 
> everyone has to set up a virtualenv and install doc/requirements.txt 
> anyway so we should just make them use tox even if they are not Python 
> projects), then I agree it makes sense to fix it even though we only 
> _just_ finished telling people it would be the opposite way.

Yes, we made the wrong call when we set the PTI to not use tox for these
cases.

> > Updating the job that uses sphinx directly to run under python 3,
> > while allowing the transition to be self-testing, was going to
> > require writing some extra complexity to look at something in the
> > repository to decide what version of python to use.  Since tox
> > handles that for us by letting us set basepython in the virtualenv
> > configuration, it seemed more straightforward to go back to using
> > tox.
> 
> Wouldn't another option be to have separate Zuul jobs for Python 3 and 
> Python 2-based sphinx builds? Then the switchover would still be 
> self-testing.
> 
> I'd rather do that if this is the main problem we're trying to solve, 
> rather than reverse course.

These jobs run on tag events, which are not "branch aware" (tags
can be on 0 or more branches at the same time). That means we cannot
have different versions of the job running for different branches.

Instead we need 1 job, which uses data inside the repository to
decide exactly what to do. Instead of writing a new, more complicated,
job to look at a flag file or other settings to decide whether to
run sphinx under python 2 or 3, it will be simpler to go back to
using the old existing tox-based job and to use the tox configuration
to control the version of python. Using the tox job also has the
benefit of fixing the tox-siblings issue for projects like neutron
plugins that need neutron installed in order to generate their
documentation. So we fix 2 problems with 1 change.

We actually have a similar problem for the release job, but in that
case we don't need tox because we don't need to install any
dependencies in order to build the artifacts.  I have tested building
sdists and wheels from every repo with a setup.py and did not find
any failures related to using python 3, so we can just switch
everyone over to use the new job.

> 
> > So, this new PTI definition restores the use of tox and specifies
> > a "docs" environment. I have started defining the relevant jobs [2]
> > and project templates [3], and I will be updating the python3-first
> > transition plan as well.
> > 
> > Let me know if you have any questions about any of that,
> > Doug
> > 
> > [1] https://review.openstack.org/#/c/580495/
> > [2] 
> > https://review.openstack.org/#/q/project:openstack-infra/project-config+topic:python3-first
> > [3] 
> > https://review.openstack.org/#/q/project:openstack-infra/openstack-zuul-jobs+topic:python3-first
> > 
> > __
> > OpenStack Development Mailing 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] [mistral] Clearing out old gerrit reviews

[Dougal Matthews]

Hey folks,

I'd like to propose that we start abandoning old Gerrit reviews.

This report shows how stale and out of date some of the reviews are:
http://stackalytics.com/report/reviews/mistral-group/open

I would like to initially abandon anything without any activity for a year,
but we might want to consider a shorter limit - maybe 6 months. Reviews can
be restored, so the risk is low.

What do you think? Any objections or counter suggestions?

If I don't hear any complaints, I'll go ahead with this next week (or maybe
the following week).

Cheers,
Dougal
__
OpenStack Development Mailing 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] [python3][tc][infra][docs] changing the documentation build PTI to use tox

[Zane Bitter]

On 05/07/18 16:46, Doug Hellmann wrote:

I have a governance patch up [1] to change the project-testing-interface
(PTI) for building documentation to restore the use of tox.

We originally changed away from tox because we wanted to have a
single standard command that anyone could use to build the documentation
for a project. It turns out that is more complicated than just
running sphinx-build in a lot of cases anyway, because of course
you have a bunch of dependencies to install before sphinx-build
will work.


Is this the main reason? If we think we made the wrong call (i.e. 
everyone has to set up a virtualenv and install doc/requirements.txt 
anyway so we should just make them use tox even if they are not Python 
projects), then I agree it makes sense to fix it even though we only 
_just_ finished telling people it would be the opposite way.



Updating the job that uses sphinx directly to run under python 3,
while allowing the transition to be self-testing, was going to
require writing some extra complexity to look at something in the
repository to decide what version of python to use.  Since tox
handles that for us by letting us set basepython in the virtualenv
configuration, it seemed more straightforward to go back to using
tox.


Wouldn't another option be to have separate Zuul jobs for Python 3 and 
Python 2-based sphinx builds? Then the switchover would still be 
self-testing.


I'd rather do that if this is the main problem we're trying to solve, 
rather than reverse course.



So, this new PTI definition restores the use of tox and specifies
a "docs" environment. I have started defining the relevant jobs [2]
and project templates [3], and I will be updating the python3-first
transition plan as well.

Let me know if you have any questions about any of that,
Doug

[1] https://review.openstack.org/#/c/580495/
[2] 
https://review.openstack.org/#/q/project:openstack-infra/project-config+topic:python3-first
[3] 
https://review.openstack.org/#/q/project:openstack-infra/openstack-zuul-jobs+topic:python3-first

__
OpenStack Development Mailing 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] swift containers.

[Monty Taylor]

On 07/09/2018 02:46 AM, jayshankar nair wrote:





Hi,

I am unable to create containers in object store.

"Unable to get the Swift service info".
"Unable to get the swift container listing".

My horizon is running on 192.168.0.19. My swift is running on 
192.168.0.12(how can i change it).


I am trying to list the container with python sdk. Is this the right api.

from openstack import connection
conn = connection.Connection(auth_url="http://192.168.0.19:5000/v3;,
                       project_name="admin",username="admin",
                       password="6908a8d218f843dd",
                       user_domain_id="default",
                       project_domain_id="default",
                       identity_api_version=3)


That looks fine (although you don't need identity_api_version=3 - you 
are specifying domain_ids - it'll figure things out)


Can you add:

import openstack
openstack.enable_logging(http_debug=True)

before your current code and paste the output?


for container in conn,object_store.containers():
print(container.name).

I need documentation of python sdk


https://docs.openstack.org/openstacksdk/latest/


Thanks,
Jayshankar


__
OpenStack Development Mailing 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] puppet-senlin development

[Alexandru Sorodoc]

Hello,

Is anyone working or planning to work on the puppet-senlin module? We 
want to use Senlin in our Pike deployment and we are considering 
contributing to its puppet module to bring it to a working state.


Best regards,
Alex

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

Re: [openstack-dev] [TripleO] easily identifying how services are configured

[Bogdan Dobrelya]

On 7/6/18 7:02 PM, Ben Nemec wrote:



On 07/05/2018 01:23 PM, Dan Prince wrote:

On Thu, 2018-07-05 at 14:13 -0400, James Slagle wrote:


I would almost rather see us organize the directories by service
name/project instead of implementation.

Instead of:

puppet/services/nova-api.yaml
puppet/services/nova-conductor.yaml
docker/services/nova-api.yaml
docker/services/nova-conductor.yaml

We'd have:

services/nova/nova-api-puppet.yaml
services/nova/nova-conductor-puppet.yaml
services/nova/nova-api-docker.yaml
services/nova/nova-conductor-docker.yaml

(or perhaps even another level of directories to indicate
puppet/docker/ansible?)


I'd be open to this but doing changes on this scale is a much larger
developer and user impact than what I was thinking we would be willing
to entertain for the issue that caused me to bring this up (i.e. how to
identify services which get configured by Ansible).

Its also worth noting that many projects keep these sorts of things in
different repos too. Like Kolla fully separates kolla-ansible and
kolla-kubernetes as they are quite divergent. We have been able to
preserve some of our common service architectures but as things move
towards kubernetes we may which to change things structurally a bit
too.


True, but the current directory layout was from back when we intended to 
support multiple deployment tools in parallel (originally 
tripleo-image-elements and puppet).  Since I think it has become clear 
that it's impractical to maintain two different technologies to do 
essentially the same thing I'm not sure there's a need for it now.  It's 
also worth noting that kolla-kubernetes basically died because there 
wasn't enough people to maintain both deployment methods, so we're not 
the only ones who have found that to be true.  If/when we move to 
kubernetes I would anticipate it going like the initial containers work 
did - development for a couple of cycles, then a switch to the new thing 
and deprecation of the old thing, then removal of support for the old 
thing.


That being said, because of the fact that the service yamls are 
essentially an API for TripleO because they're referenced in user


this ^^

resource registries, I'm not sure it's worth the churn to move 
everything either.  I think that's going to be an issue either way 
though, it's just a question of the scope.  _Something_ is going to move 
around no matter how we reorganize so it's a problem that needs to be 
addressed anyway.


[tl;dr] I can foresee reorganizing that API becomes a nightmare for 
maintainers doing backports for queens (and the LTS downstream release 
based on it). Now imagine kubernetes support comes within those next a 
few years, before we can let the old API just go...


I have an example [0] to share all that pain brought by a simple move of 
'API defaults' from environments/services-docker to 
environments/services plus environments/services-baremetal. Each time a 
file changes contents by its old location, like here [1], I had to run a 
lot of sanity checks to rebase it properly. Like checking for the 
updated paths in resource registries are still valid or had to/been 
moved as well, then picking the source of truth for diverged old vs 
changes locations - all that to loose nothing important in progress.


So I'd say please let's do *not* change services' paths/namespaces in 
t-h-t "API" w/o real need to do that, when there is no more alternatives 
left to that.


[0] https://review.openstack.org/#/q/topic:containers-default-stable/queens
[1] https://review.openstack.org/#/c/567810



-Ben

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



--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing 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-infra][releases] couldn't find xstatic package in pypi after release job is merged

[Tony Breeds]

On Mon, Jul 09, 2018 at 04:38:47PM +0900, Xinni Ge wrote:
> Hello openstack-infra team,
> 
> I uploaded a patch to add a new release of xstatic-angular-material, and
> thanks for your work it was merged several days ago.
> Here is the link of the patch.
> https://review.openstack.org/#/c/577018/
> 
> However, I cannot find the correct version in pypi index. It still shows an
> initial version as 0.0.0.
> https://pypi.org/project/xstatic-angular-material/
> 
> There was a similar problem before but it seems to be fixed already after
> the following patches were merged.
> https://review.openstack.org/#/c/559300/
> https://review.openstack.org/#/c/559373/
> 
> Could you help me with this issue please? Thank you very much.

There was a thread about this starting here:
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131773.html

The tools side of things has been fixed, so if you correct the version
in your package and ask for a new release things should work.

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

[openstack-dev] [openstack-infra][releases] couldn't find xstatic package in pypi after release job is merged

[Xinni Ge]

Hello openstack-infra team,

I uploaded a patch to add a new release of xstatic-angular-material, and
thanks for your work it was merged several days ago.
Here is the link of the patch.
https://review.openstack.org/#/c/577018/

However, I cannot find the correct version in pypi index. It still shows an
initial version as 0.0.0.
https://pypi.org/project/xstatic-angular-material/

There was a similar problem before but it seems to be fixed already after
the following patches were merged.
https://review.openstack.org/#/c/559300/
https://review.openstack.org/#/c/559373/

Could you help me with this issue please? Thank you very much.

Best regards,
​​
Xinni
​ Ge​
__
OpenStack Development Mailing 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] swift containers.

[jayshankar nair]

 

   
 
 Hi,
I am unable to create containers in object store.
"Unable to get the Swift service info"."Unable to get the swift container 
listing".
My horizon is running on 192.168.0.19. My swift is running on 192.168.0.12(how 
can i change it). 
I am trying to list the container with python sdk. Is this the right api.
from openstack import connectionconn = 
connection.Connection(auth_url="http://192.168.0.19:5000/v3",                   
   project_name="admin",username="admin",                      
password="6908a8d218f843dd",                      user_domain_id="default",     
                 project_domain_id="default",                      
identity_api_version=3)


for container in conn,object_store.containers():print(container.name).
I need documentation of python sdk
Thanks,Jayshankar  __
OpenStack Development Mailing 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] swift containers.

[jayshankar nair]

Hi,
I am unable to create containers in object store.
"Unable to get the Swift service info"."Unable to get the swift container 
listing".
My horizon is running on 192.168.0.19. My swift is running on 192.168.0.12(how 
can i change it). 
I am trying to list the container with python sdk. Is this the right api.
from openstack import connectionconn = 
connection.Connection(auth_url="http://192.168.0.19:5000/v3",                   
   project_name="admin",username="admin",                      
password="6908a8d218f843dd",                      user_domain_id="default",     
                 project_domain_id="default",                      
identity_api_version=3)


for container in conn,object_store.containers():print(container.name).
I need documentation of python sdk
Thanks,Jayshankar__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev