date:20181004

Hi Matt,

Thanks for the input, I guess I should use '
http://git.openstack.org/static/openstack.png' which will definitely work.
Clark, Matt, Kindly let me know your opinion about the same.

Thanks & Best Regards,

Abhishek Kekane


On Fri, Oct 5, 2018 at 10:20 AM Matthew Treinish 
wrote:

>
>
> On October 5, 2018 12:11:51 AM EDT, Abhishek Kekane 
> wrote:
> >Hi Clark,
> >
> >Thank you for the inputs. I have verified the logs and found that
> >mostly
> >image import web-download import method related tests are failing.
> >Now in this test [1] we are trying to download a file from '
> >
> https://www.openstack.org/assets/openstack-logo/2016R/OpenStack-Logo-Horizontal.eps.zip
> '
> >in glance. Here we are assuming image will be downloaded and active
> >within
> >20 seconds of time and if not it will be marked as failed. Now this
> >test
> >never fails in local environment but their might be a problem of
> >connecting
> >to remote while this test is executed in zuul jobs.
> >
> >Do you have any alternative idea how we can test this scenario, as it
> >is
> >very hard to reproduce this in local environment.
> >
>
> External networking will always be unreliable from the ci environment,
> nothing is 100% reliable and just given the sheer number of jobs we execute
> there will be an appreciable number of failures just from that. That being
> said this exact problem you've described is one we fixed in
> devstack/tempest over 5 years ago:
>
> https://bugs.launchpad.net/tempest/+bug/1190623
>
> It'd be nice if we didn't keep repeating problems. The solution for that
> bug is likely to be the same thing here, and not relying on pulling
> something from the external network in the test. Just use something else
> hosted on the local apache httpd of the test node and use that as the url
> to import in the test.
>
> -Matt Treinish
>
> >
> >
> >On Thu, Oct 4, 2018 at 7:43 PM Clark Boylan 
> >wrote:
> >
> >> On Thu, Oct 4, 2018, at 12:16 AM, Abhishek Kekane wrote:
> >> > Hi,
> >> > Could you please point out some of the glance functional tests
> >which are
> >> > failing and causing this resets?
> >> > I will like to put some efforts towards fixing those.
> >>
> >> http://status.openstack.org/elastic-recheck/data/integrated_gate.html
> >is
> >> a good place to start. That shows you a list of tests that failed in
> >the
> >> OpenStack Integrated gate that elastic-recheck could not identify the
> >> failure for including those for several functional jobs.
> >>
> >> If you'd like to start looking at identified bugs first then
> >> http://status.openstack.org/elastic-recheck/gate.html shows
> >identified
> >> failures that happened in the gate.
> >>
> >> For glance functional jobs the first link points to:
> >>
> >>
> >
> http://logs.openstack.org/99/595299/1/gate/openstack-tox-functional/fc13eca/
> >>
> >>
> >
> http://logs.openstack.org/44/569644/3/gate/openstack-tox-functional/b7c487c/
> >>
> >>
> >
> http://logs.openstack.org/99/595299/1/gate/openstack-tox-functional-py35/b166313/
> >>
> >>
> >
> http://logs.openstack.org/44/569644/3/gate/openstack-tox-functional-py35/ce262ab/
> >>
> >> 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
> >>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> __
> OpenStack Development Mailing 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] Zuul job backlog

2018-10-04 Thread Matthew Treinish



On October 5, 2018 12:11:51 AM EDT, Abhishek Kekane  wrote:
>Hi Clark,
>
>Thank you for the inputs. I have verified the logs and found that
>mostly
>image import web-download import method related tests are failing.
>Now in this test [1] we are trying to download a file from '
>https://www.openstack.org/assets/openstack-logo/2016R/OpenStack-Logo-Horizontal.eps.zip'
>in glance. Here we are assuming image will be downloaded and active
>within
>20 seconds of time and if not it will be marked as failed. Now this
>test
>never fails in local environment but their might be a problem of
>connecting
>to remote while this test is executed in zuul jobs.
>
>Do you have any alternative idea how we can test this scenario, as it
>is
>very hard to reproduce this in local environment.
>

External networking will always be unreliable from the ci environment, nothing 
is 100% reliable and just given the sheer number of jobs we execute there will 
be an appreciable number of failures just from that. That being said this exact 
problem you've described is one we fixed in devstack/tempest over 5 years ago: 

https://bugs.launchpad.net/tempest/+bug/1190623

It'd be nice if we didn't keep repeating problems. The solution for that bug is 
likely to be the same thing here, and not relying on pulling something from the 
external network in the test. Just use something else hosted on the local 
apache httpd of the test node and use that as the url to import in the test.

-Matt Treinish

>
>
>On Thu, Oct 4, 2018 at 7:43 PM Clark Boylan 
>wrote:
>
>> On Thu, Oct 4, 2018, at 12:16 AM, Abhishek Kekane wrote:
>> > Hi,
>> > Could you please point out some of the glance functional tests
>which are
>> > failing and causing this resets?
>> > I will like to put some efforts towards fixing those.
>>
>> http://status.openstack.org/elastic-recheck/data/integrated_gate.html
>is
>> a good place to start. That shows you a list of tests that failed in
>the
>> OpenStack Integrated gate that elastic-recheck could not identify the
>> failure for including those for several functional jobs.
>>
>> If you'd like to start looking at identified bugs first then
>> http://status.openstack.org/elastic-recheck/gate.html shows
>identified
>> failures that happened in the gate.
>>
>> For glance functional jobs the first link points to:
>>
>>
>http://logs.openstack.org/99/595299/1/gate/openstack-tox-functional/fc13eca/
>>
>>
>http://logs.openstack.org/44/569644/3/gate/openstack-tox-functional/b7c487c/
>>
>>
>http://logs.openstack.org/99/595299/1/gate/openstack-tox-functional-py35/b166313/
>>
>>
>http://logs.openstack.org/44/569644/3/gate/openstack-tox-functional-py35/ce262ab/
>>
>> 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
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

__
OpenStack Development Mailing 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][neutron-release] feature/graphql branch rebase

2018-10-04 Thread Gilles Dubreuil


Hey Neutron folks,

I'm just reiterating the request.

Thanks


On 20/06/18 11:34, Gilles Dubreuil wrote:
Could someone from the Neutron release group rebase feature/graphql 
branch against master/HEAD branch please?


Regards,
Gilles





__
OpenStack Development Mailing 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] Zuul job backlog

Hi Clark,

Thank you for the inputs. I have verified the logs and found that mostly
image import web-download import method related tests are failing.
Now in this test [1] we are trying to download a file from '
https://www.openstack.org/assets/openstack-logo/2016R/OpenStack-Logo-Horizontal.eps.zip'
in glance. Here we are assuming image will be downloaded and active within
20 seconds of time and if not it will be marked as failed. Now this test
never fails in local environment but their might be a problem of connecting
to remote while this test is executed in zuul jobs.

Do you have any alternative idea how we can test this scenario, as it is
very hard to reproduce this in local environment.

Thanks & Best Regards,

Abhishek Kekane

On Thu, Oct 4, 2018 at 7:43 PM Clark Boylan  wrote:

> On Thu, Oct 4, 2018, at 12:16 AM, Abhishek Kekane wrote:
> > Hi,
> > Could you please point out some of the glance functional tests which are
> > failing and causing this resets?
> > I will like to put some efforts towards fixing those.
>
> http://status.openstack.org/elastic-recheck/data/integrated_gate.html is
> a good place to start. That shows you a list of tests that failed in the
> OpenStack Integrated gate that elastic-recheck could not identify the
> failure for including those for several functional jobs.
>
> If you'd like to start looking at identified bugs first then
> http://status.openstack.org/elastic-recheck/gate.html shows identified
> failures that happened in the gate.
>
> For glance functional jobs the first link points to:
>
> http://logs.openstack.org/99/595299/1/gate/openstack-tox-functional/fc13eca/
>
> http://logs.openstack.org/44/569644/3/gate/openstack-tox-functional/b7c487c/
>
> http://logs.openstack.org/99/595299/1/gate/openstack-tox-functional-py35/b166313/
>
> http://logs.openstack.org/44/569644/3/gate/openstack-tox-functional-py35/ce262ab/
>
> 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] [glance] spec-lite: Embed validation data in locations

2018-10-04 Thread Brian Rosmaita

I put together an etherpad outlining the changes to Iain's spec-lite
[0] that we discussed at today's glance meeting:

https://etherpad.openstack.org/p/glance-spec-lite-stein-locations-with-checksum

It's probably best to leave comments on the etherpad.

cheers,
brian

[0] https://review.openstack.org/#/c/597648/

__
OpenStack Development Mailing 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][Searchlight] Always build universal wheels

2018-10-04 Thread Trinh Nguyen

Thank Jeremy, Doug for explaining.

On Fri, Oct 5, 2018 at 6:54 AM Doug Hellmann  wrote:

> Jeremy Stanley  writes:
>
> > On 2018-10-04 23:11:22 +0900 (+0900), Trinh Nguyen wrote:
> > [...]
> >> Please avoid adding universal wheels to the project setup.cfg.
> > [...]
> >
> > Why would you avoid also adding it to the setup.cfg? The change you
> > cited is merely to be able to continue building universal wheels for
> > projects while the setup.cfg files are corrected over time, to
> > reduce the urgency of doing so. Wheel building happens in more
> > places than just our CI system, so only fixing it in CI is not a
> > good long-term strategy.
>
> I abandoned a couple of dozen patches submitted today by someone who was
> not coordinating with the goal champions with a message that said those
> patches were not needed because I didn't want folks to be dealing with
> this right now.
>
> Teams who want to update their setup.cfg can do so, but my intent is to
> ensure it is not required in order to produce releases with the
> automation in the short term.
>
> 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
>


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

Re: [openstack-dev] [Release-job-failures] Release of openstack/os-log-merger failed

On 2018-10-04 18:21:50 -0400 (-0400), Doug Hellmann wrote:
> Jeremy Stanley  writes:
> 
> > On 2018-10-04 17:57:06 -0400 (-0400), Doug Hellmann wrote:
> > [...]
> >>   HTTPError: 400 Client Error: Invalid value for classifiers. Error:
> >>   'Topic:: Utilities' is not a valid choice for this field for url:
> >>   https://upload.pypi.org/legacy/
> >> 
> >> I'm not aware of any way to test those values easily before doing an
> >> upload. If someone knows of a way, please let me know.
> >
> > I started writing a distcheck utility based on some validation code
> > flit uses, but now that twine has a check option there is expressed
> > intent by Dustin to do it there (see description of
> > https://github.com/pypa/twine/pull/395 for details) which seems like
> > a more natural solution anyway.
> 
> OK, good. The existing check job for packaging already runs 'twine
> check' so we should be covered when that feature is merged and released.

Well, the TODO comment at
https://github.com/pypa/warehouse/blob/55230d8/warehouse/forklift/legacy.py#L341-L343
expresses an interest in seeing Warehouse's (the current PyPI
implementation) metadata validation code move to the
https://pypi.org/project/packaging/ library, which should be clear
to progress now that https://www.python.org/dev/peps/pep-0459/
(which supplanted the withdrawn PEP 426 mentioned in the TODO) has
been finalized. Someone still needs to do that work, and then update
`twine check` to use it (probably won't be me either, unless I
somehow grow some extra spare time). This would be an awesome
project for *someone* interested in making new inroads in the Python
packaging community.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [Release-job-failures] Release of openstack/os-log-merger failed

Jeremy Stanley  writes:

> On 2018-10-04 17:57:06 -0400 (-0400), Doug Hellmann wrote:
> [...]
>>   HTTPError: 400 Client Error: Invalid value for classifiers. Error:
>>   'Topic:: Utilities' is not a valid choice for this field for url:
>>   https://upload.pypi.org/legacy/
>> 
>> I'm not aware of any way to test those values easily before doing an
>> upload. If someone knows of a way, please let me know.
>
> I started writing a distcheck utility based on some validation code
> flit uses, but now that twine has a check option there is expressed
> intent by Dustin to do it there (see description of
> https://github.com/pypa/twine/pull/395 for details) which seems like
> a more natural solution anyway.

OK, good. The existing check job for packaging already runs 'twine
check' so we should be covered when that feature is merged and released.

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-dev] [nova] agreement on how to specify options that impact scheduling and configuration

2018-10-04 Thread Chris Friesen

While discussing the "Add HPET timer support for x86 guests" 
blueprint[1] one of the items that came up was how to represent what are 
essentially flags that impact both scheduling and configuration.  Eric 
Fried posted a spec to start a discussion[2], and a number of nova 
developers met on a hangout to hash it out.  This is the result.


In this specific scenario the goal was to allow the user to specify that 
their image required a virtual HPET.  For efficient scheduling we wanted 
this to map to a placement trait, and the virt driver also needed to 
enable the feature when booting the instance.  (This can be generalized 
to other similar problems, including how to specify scheduling and 
configuration information for Ironic.)


We discussed two primary approaches:

The first approach was to specify an arbitrary "key=val" in flavor 
extra-specs or image properties, which nova would automatically 
translate into the appropriate placement trait before passing it to 
placement.  Once scheduled to a compute node, the virt driver would look 
for "key=val" in the flavor/image to determine how to proceed.


The second approach was to directly specify the placement trait in the 
flavor extra-specs or image properties.  Once scheduled to a compute 
node, the virt driver would look for the placement trait in the 
flavor/image to determine how to proceed.


Ultimately, the decision was made to go with the second approach.  The 
result is that it is officially acceptable for virt drivers to key off 
placement traits specified in the image/flavor in order to turn on/off 
configuration options for the instance.  If we do get down to the virt 
driver and the trait is set, and the driver for whatever reason 
determines it's not capable of flipping the switch, it should fail.


It should be noted that it only makes sense to use placement traits for 
things that affect scheduling.  If it doesn't affect scheduling, then it 
can be stored in the flavor extra-specs or image properties separate 
from the placement traits.  Also, this approach only makes sense for 
simple booleans.  Anything requiring more complex configuration will 
likely need additional extra-spec and/or config and/or unicorn dust.


Chris

[1] https://blueprints.launchpad.net/nova/+spec/support-hpet-on-guest
[2] 
https://review.openstack.org/#/c/607989/1/specs/stein/approved/support-hpet-on-guest.rst


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

Re: [openstack-dev] [Release-job-failures] Release of openstack/os-log-merger failed

On 2018-10-04 17:57:06 -0400 (-0400), Doug Hellmann wrote:
[...]
>   HTTPError: 400 Client Error: Invalid value for classifiers. Error:
>   'Topic:: Utilities' is not a valid choice for this field for url:
>   https://upload.pypi.org/legacy/
> 
> I'm not aware of any way to test those values easily before doing an
> upload. If someone knows of a way, please let me know.

I started writing a distcheck utility based on some validation code
flit uses, but now that twine has a check option there is expressed
intent by Dustin to do it there (see description of
https://github.com/pypa/twine/pull/395 for details) which seems like
a more natural solution anyway.
-- 
Jeremy Stanley


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

Re: [openstack-dev] Sphinx testing fun

Stephen Finucane  writes:

> On Thu, 2018-10-04 at 07:21 -0400, Doug Hellmann wrote:
>> Stephen Finucane  writes:

[snip]

>> > Anyway, we can go figure out what's changed here and handle it but this
>> > is, at best, going to be a band aid. The fact is 'sphinx_testing' is
>> > unmaintained and has been for some time now. The new hotness is
>> > 'sphinx.testing' [3], which is provided (with zero documentation) as
>> > part of Sphinx. Unfortunately, this uses pytest fixtures [4] which I'm
>> > pretty sure Monty (and a few others?) are vehemently against using in
>> > OpenStack. That leaves us with three options:
>> > 
>> >  * Take over 'sphinx_testing' and bring it up-to-date. Maintain
>> >forever.
>> >  * Start using 'sphinx.testing' and everything it comes with
>> >  * Delete any tests that use 'sphinx_testing' and deal with the lack of
>> >coverage
>> 
>> Could we change our tests to use pathlib to wrap app.outdir and get the
>> same results as before?
>
> That's what I've done [2], which is kind of based on how I fixed this
> in Sphinx. However, this is at best a stopgap. The fact remains that
> 'sphinx_testing' is dead and the large changes that Sphinx is
> undergoing (2.0 will be Python 3 only, with multiple other fixes) will
> make further breakages more likely. Unless we want a repeat of the Mox
> situation, I do think we should start thinking about this sooner rather
> than later.

Yeah, it sounds like we need to deal with the change.

It looks like only the os-api-ref repo uses sphinx-testing. How many
tests are we talking about having to rewrite/update there?

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] [Release-job-failures] Release of openstack/os-log-merger failed

z...@openstack.org writes:

> Build failed.
>
> - release-openstack-python 
> http://logs.openstack.org/b4/b4553baa59b1f13a57973f2a3cff9b57acf3d522/release/release-openstack-python/68d0da8/
>  : POST_FAILURE in 5m 19s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
>
> ___
> Release-job-failures mailing list
> release-job-failu...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

It looks like there is a bad classifier in the os-log-merger setup.cfg
file.

  HTTPError: 400 Client Error: Invalid value for classifiers. Error:
  'Topic:: Utilities' is not a valid choice for this field for url:
  https://upload.pypi.org/legacy/

I'm not aware of any way to test those values easily before doing an
upload. If someone knows of a way, please let me know.

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] [all][Searchlight] Always build universal wheels

Jeremy Stanley  writes:

> On 2018-10-04 23:11:22 +0900 (+0900), Trinh Nguyen wrote:
> [...]
>> Please avoid adding universal wheels to the project setup.cfg.
> [...]
>
> Why would you avoid also adding it to the setup.cfg? The change you
> cited is merely to be able to continue building universal wheels for
> projects while the setup.cfg files are corrected over time, to
> reduce the urgency of doing so. Wheel building happens in more
> places than just our CI system, so only fixing it in CI is not a
> good long-term strategy.

I abandoned a couple of dozen patches submitted today by someone who was
not coordinating with the goal champions with a message that said those
patches were not needed because I didn't want folks to be dealing with
this right now.

Teams who want to update their setup.cfg can do so, but my intent is to
ensure it is not required in order to produce releases with the
automation in the short term.

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-dev] OpenStack Community Meeting - October 10 - Strategic Area Governance Update

2018-10-04 Thread Chris Hoge

Following the interest in the first OpenStack Foundation community
meeting, where we discussed the OpenStack Rocky release as well as quick
updates from Kata, Airship, StarlingX and Zuul, we want to keep the
community meetings going. The second community meeting will be October 10
at 8:00 PT / 15:00 UTC, and the agenda is for Jonathan Bryce and Thierry
Carrez to share the latest plans for strategic project governance at the
Foundation. These updates will include the process for creating new
Strategic Focus Areas, and the lifecycle of new Foundation supported
projects. We will have an opportunity to share feedback as well as a
question and answer session at the end of the presentation.

For a little context about the proposed plan for strategic project
governance, you can read Jonathan’s email to the Foundation mailing list:
http://lists.openstack.org/pipermail/foundation/2018-August/002617.html 


This meeting will be recorded and made publicly available. This is part
of our plan to introduce bi-weekly OpenStack Foundation community meetings
that will cover topics like Foundation strategic area updates, project
demonstrations, and other community efforts. We expect the next meeting
to take place October 24 and focus on the anticipated StarlingX release.
Do you have something you'd like to discuss or share with the community?
Please share them with me so that I can schedule them for future meetings.

OpenStack Community Meeting - Strategic Area Governance Update
Date & Time: October 10, 8:00 PT / 15:00 UTC
Zoom Meeting Link: https://zoom.us/j/312447172 
Agenda: https://etherpad.openstack.org/p/openstack-community-meeting 


Thanks!
Chris Hoge
Strategic Program Manager
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] [tc] bringing back formal TC meetings

2018-10-04 Thread Sean McGinnis

On Thu, Oct 04, 2018 at 05:47:53PM +, Jeremy Stanley wrote:
> On 2018-10-04 13:40:05 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > TC members, please reply to this thread and indicate if you would
> > find meeting at 1300 UTC on the first Thursday of every month
> > acceptable, and of course include any other comments you might
> > have (including alternate times).
> 
> This time is acceptable to me. As long as we ensure that community
> feedback continues more frequently in IRC and on the ML (for example
> by making it clear that this meeting is expressly *not* for that)
> then I'm fine with resuming formal meetings.
> -- 
> Jeremy Stanley

Same here. The time works for me, but I hope that bringing back an official
meeting time does not prevent productive conversations from happening at any
other time.

Sean

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

Re: [openstack-dev] [ironic][neutron] SmartNics with Ironic

2018-10-04 Thread Moshe Levi

Hi Julia,

Apologize we were not able to be there to better represent the use case.

PSB

From: Julia Kreger 
Sent: Monday, October 1, 2018 11:07 PM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: isaku.yamah...@intel.com; Eyal Lavee 
Subject: Re: [openstack-dev] [ironic][neutron] SmartNics with Ironic

Greetings, Comments in-line.

Thanks,

-Julia

On Sat, Sep 29, 2018 at 11:27 PM Moshe Levi 
mailto:mosh...@mellanox.com>> wrote:
Hi Julia,

I don't mind to update the ironic spec [1]. Unfortunately, I wasn't in the PTG 
but I had a sync meeting with Isuku.

As I see it there is 2 use-cases:
1.   Running the neutron ovs agent in the smartnic
2.   Running the neutron super ovs agent which manage the ovs running on 
the smartnic.

My takeaway from the meeting with neutron is that there would not be a neutron 
ovs agent running on the smartnic. That the configuration would need to be 
pushed at all times, which is ultimately better security wise if the tenant NIC 
is somehow compromised it reduces the control plane exposure.
[ML] - Can you elaborate on  the security concerns with running the neutron ovs 
agent on the smart NIC?
If you compare this to the standard virtualization use case, this is as secure 
if not more secure.
The tenant image runs in the bare metal host and receives only a network 
interface/port.
The host has no way to access the OS/services/agents running on the smart NIC 
CPUs, in the same way that a tenant image running in a VM has no way to access 
the services/agents running in the hypervisor.
It is in fact event more secure, as they are running in physically disjoint 
hardware and memory (thus not accessible even through side-channel 
vulnerabilities such as meltdown/spectre).

1.

It seem that most of the discussion was around the second use-case.

By the time Ironic and Neutron met together, it seemed like the first use case 
was no longer under consideration. I may be wrong, but very strong preference 
existed for the second scenario when we met the next day.
[ML] –
We are seeing great interest on smart NICs for bare metal use cases to allow to 
provide services (networking, storage and others) to bare metal servers that 
were previously only possible for VMs.
Conceptually the smart NIC can be thought of as an isolated hypervisor layer 
for the bare metal host.
The first service we are targeting in this spec is aligning the bare metal 
networking with the standard neutron ovs agent.
The target is to try to align (as possible) the bare metal implementation to 
the virtualization use case, up to the point of actually running (as possible) 
the same agents on the smart NIC (again acting as a hypervisor for the bare 
metal host use case).
This allows to reuse/align the implementation, and naturally scales with the 
number of bare metal servers, as opposed to running the agents on controller 
nodes, requiring potentially scaling the controllers to match the number of 
bare metal servers.
It also provides a path to providing more advanced services in the smart NIC in 
the next steps (not limiting the implementation to be OVSDB protocol specific).

This is my understanding on the ironic neutron PTG meeting:

  1.  Ironic cores don't want to change the deployment interface as proposed in 
[1].
  2.  We should  a new network_interface for use case 2. But what about the 
first use case? Should it be a new network_interface as well?
  3.  We should delay the port binding until the baremetal is powered on the 
ovs is running.

 *   For the first use case I was thinking to change the neutron server to 
just keep the port binding information in the neutron DB. Then when the neutron 
ovs agent is a live it will retrieve all the baremeal port , add them to the 
ovsdb and start the neutron ovs agent fullsync.
 *   For the second use case the agent is alive so the agent itself can 
monitor the ovsdb of the baremetal and configure it when it up

  1.  How to notify that neutron agent successfully/unsuccessfully bind the 
port ?

 *   In both use-cases we should use neutron-ironic notification to make 
sure the port binding was done successfully.

Is my understanding correct?

Not quite.

1) We as in Ironic recognize that there would need to be changes, it is the 
method as to how that we would prefer to be explicit and have chosen by the 
interface. The underlying behavior needs to be different, and the new 
network_interface should support both cases 1 and 2 because that interface 
contain needed logic for the conductor to determine the appropriate path 
forward. We should likely also put some guards in to prevent non-smart 
interfaces from being used in the same configuration due to the security issues 
that creates.
3) I believe this would be more of a matter of the network_interface knowing 
that the machine is powered up, and attempting to assert configuration through 
Neutron to push configuration to the smartnic.
3a) The consensus is that the

Re: [openstack-dev] [tripleo][puppet] clearing the gate and landing patches to help CI

2018-10-04 Thread Wesley Hayutin

On Thu, Oct 4, 2018 at 8:29 AM Alex Schultz  wrote:

> And master is blocked again.  We need
> https://review.openstack.org/#/c/607952/
>
> Thanks,
> -Alex
>

I just got infra to put that patch on the top of the queue.
We also need https://review.openstack.org/#/c/607904/ reviewed ASAP

Thanks


>
> On Fri, Sep 28, 2018 at 9:02 AM Alex Schultz  wrote:
> >
> > Hey Folks,
> >
> > Currently the tripleo gate is at 21 hours and we're continue to have
> > timeouts and now scenario001/004 (in queens/pike) appear to be broken.
> > Additionally we've got some patches in puppet-openstack that we need
> > to land in order to resolve broken puppet unit tests which is
> > affecting both projects.
> >
> > Currently we need to wait for the following to land in puppet:
> >
> https://review.openstack.org/#/q/I4875b8bc8b2333046fc3a08b4669774fd26c89cb
> > https://review.openstack.org/#/c/605350/
> >
> > In tripleo we currently have not identified the root cause for any of
> > the timeout failures so I'd for us to work on that before trying to
> > land anything else because the gate resets are killing us and not
> > helping anything.  We have landed a few patches that have improved the
> > situation but we're still hitting issues.
> >
> > https://bugs.launchpad.net/tripleo/+bug/1795009 is the bug for the
> > scenario001/004 issues.  It appears that we're ending up with a newer
> > version of ansible on the system then what the packages provide. Still
> > working on figuring out where it's coming from.
> >
> > Please do not approve anything or recheck unless it's to address CI
> > issues at this time.
> >
> > 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
>
-- 

Wes Hayutin

Associate MANAGER

Red Hat



whayu...@redhat.comT: +1919 <+19197544114>4232509 IRC:  weshay


View my calendar and check my availability for meetings HERE

__
OpenStack Development Mailing 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] [tc] bringing back formal TC meetings

2018-10-04 Thread Zane Bitter


On 4/10/18 1:47 PM, Jeremy Stanley wrote:

On 2018-10-04 13:40:05 -0400 (-0400), Doug Hellmann wrote:
[...]

TC members, please reply to this thread and indicate if you would
find meeting at 1300 UTC on the first Thursday of every month
acceptable, and of course include any other comments you might
have (including alternate times).


This time is acceptable to me. As long as we ensure that community
feedback continues more frequently in IRC and on the ML (for example
by making it clear that this meeting is expressly *not* for that)
then I'm fine with resuming formal meetings.


+1

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

Re: [openstack-dev] [tc] bringing back formal TC meetings

On 2018-10-04 13:40:05 -0400 (-0400), Doug Hellmann wrote:
[...]
> TC members, please reply to this thread and indicate if you would
> find meeting at 1300 UTC on the first Thursday of every month
> acceptable, and of course include any other comments you might
> have (including alternate times).

This time is acceptable to me. As long as we ensure that community
feedback continues more frequently in IRC and on the ML (for example
by making it clear that this meeting is expressly *not* for that)
then I'm fine with resuming formal meetings.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [tc] bringing back formal TC meetings

2018-10-04 Thread Mohammed Naser



On Oct 4 2018, at 1:40 pm, Doug Hellmann  wrote:
>
> During the TC office hours today [1] we discussed the question of
> resuming having formal meetings of the TC to ensure we are in compliance
> with the section of the bylaws that says "The Technical Committee shall
> meet at least quarterly." [2] As not all TC members were present today,
> we decide to move the discussion to the mailing list to ensure all
> members have input into the decision.
>
> A bit of background
> ---
>
> The TC used to hold formal weekly meetings with agendas, roll call,
> etc. We stopped doing that in an attempt to encourage more asynchronous
> communication and to include folks in all time zones. Those meetings
> were replaced with less formal "office hours" where TC members were
> encouraged to be present on IRC in case the community had questions or
> issues to raise in a synchronous forum.
>
> The bylaws section that describes the membership and some of the
> expectations for the Technical Committee specifically requires us to
> meet at least once quarter year. We have had meetings at the PTGs and
> summits, which while not recorded via a roll call were open and
> documented afterwards with summaries to this mailing list.
>
> With the change in event schedule, we will no longer have obvious
> opportunities to hold 4 in-person meetings each year. During the
> discussion today, we established the general consensus that our current
> informal office hours do not constitute a "meeting" in the sense that
> any of us understand this requirement. As a result, we need to consider
> changes to our current meeting policy to ensure we are in compliance
> with the foundation bylaws.
>
> Today's discussion
> --
>
> A few folks expressed concern that we work to ensure these meetings
> *not* be seen as a replacement for asynchronous communication, and that
> we continue to encourage ad hoc discussions to continue to happen on the
> mailing list or during office hours. I think we agreed we could do that
> by managing the agenda carefully (i.e., the chair or vice chair would
> need to add topics to the agenda, rather than allowing anyone to add
> anything as we have done in the past). We also talked about only
> allowing recurring topics on the agenda, but I would prefer that we not
> write too many hard rules at the outset.
>
> We discussed how frequently we should meet, and everyone seemed to agree
> that weekly was too often and quarterly was not often enough. I proposed
> monthly, and there was some general support for that. We also talked
> about whether to find a new meeting time or to use one of the office
> hour times.
>
> As things stand now, the proposal is to try to find a time a few hours
> earlier than office hours on the first Thursday of each month for the
> meetings. The earlier time is so that APAC participants (Ghanshyam, in
> particular) do not need to stay up until midnight or later to
> participate.
>
> Next steps
> --
>
> TC members, please reply to this thread and indicate if you would find
> meeting at 1300 UTC on the first Thursday of every month acceptable, and
> of course include any other comments you might have (including alternate
> times).
>

I think every 1 month is a bit too much. Especially if we're going to rotate to 
be able to accommodate those in APAC time zones, they might not be able to make 
a proper meeting in 2 months.
I don't think a very brief weekly one that's planned which we can skip is a 
huge burden on all of us, finding an hour of time isn't too unreasonable (and 
we mostly are already doing it during office hours anyways).
> Thanks,
> Doug
>
>
> [1] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-10-04.log.html#t2018-10-04T15:02:31
> [2] https://www.openstack.org/legal/technical-committee-member-policy/ (item 
> #4)
>
> __
> OpenStack Development Mailing 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] [tc] bringing back formal TC meetings

During the TC office hours today [1] we discussed the question of
resuming having formal meetings of the TC to ensure we are in compliance
with the section of the bylaws that says "The Technical Committee shall
meet at least quarterly." [2] As not all TC members were present today,
we decide to move the discussion to the mailing list to ensure all
members have input into the decision.

A bit of background
---

The TC used to hold formal weekly meetings with agendas, roll call,
etc. We stopped doing that in an attempt to encourage more asynchronous
communication and to include folks in all time zones. Those meetings
were replaced with less formal "office hours" where TC members were
encouraged to be present on IRC in case the community had questions or
issues to raise in a synchronous forum.

The bylaws section that describes the membership and some of the
expectations for the Technical Committee specifically requires us to
meet at least once quarter year. We have had meetings at the PTGs and
summits, which while not recorded via a roll call were open and
documented afterwards with summaries to this mailing list.

With the change in event schedule, we will no longer have obvious
opportunities to hold 4 in-person meetings each year. During the
discussion today, we established the general consensus that our current
informal office hours do not constitute a "meeting" in the sense that
any of us understand this requirement. As a result, we need to consider
changes to our current meeting policy to ensure we are in compliance
with the foundation bylaws.

Today's discussion
--

A few folks expressed concern that we work to ensure these meetings
*not* be seen as a replacement for asynchronous communication, and that
we continue to encourage ad hoc discussions to continue to happen on the
mailing list or during office hours. I think we agreed we could do that
by managing the agenda carefully (i.e., the chair or vice chair would
need to add topics to the agenda, rather than allowing anyone to add
anything as we have done in the past). We also talked about only
allowing recurring topics on the agenda, but I would prefer that we not
write too many hard rules at the outset.

We discussed how frequently we should meet, and everyone seemed to agree
that weekly was too often and quarterly was not often enough. I proposed
monthly, and there was some general support for that. We also talked
about whether to find a new meeting time or to use one of the office
hour times.

As things stand now, the proposal is to try to find a time a few hours
earlier than office hours on the first Thursday of each month for the
meetings. The earlier time is so that APAC participants (Ghanshyam, in
particular) do not need to stay up until midnight or later to
participate.

Next steps
--

TC members, please reply to this thread and indicate if you would find
meeting at 1300 UTC on the first Thursday of every month acceptable, and
of course include any other comments you might have (including alternate
times).

Thanks,
Doug

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-10-04.log.html#t2018-10-04T15:02:31
[2] https://www.openstack.org/legal/technical-committee-member-policy/ (item #4)

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

[openstack-dev] [release] Release countdown for week R-26 and R-25, October 8-19

2018-10-04 Thread Sean McGinnis

Welcome to the (biweekly for now) release countdown email. Just a quick
reminder for this one.

Development Focus
-

Team focus should be on spec approval and implementation for priority features.

General Information
---

Teams should now be making progress towards the cycle goals [1]. Please
prioritize reviews for these appropriately. 

[1] https://governance.openstack.org/tc/goals/stein/index.html

Upcoming Deadlines & Dates
--

Stein-1 milestone: October 25  (R-24 week)
Forum at OpenStack Summit in Berlin: November 13-15

-- 
Sean McGinnis (smcginnis)

__
OpenStack Development Mailing 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-sigs] [all][tc] We're combining the lists!

2018-10-04 Thread jean-philippe

Agreed with the merge. 
null__
OpenStack Development Mailing 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][Searchlight] Always build universal wheels

On 2018-10-04 23:11:22 +0900 (+0900), Trinh Nguyen wrote:
[...]
> Please avoid adding universal wheels to the project setup.cfg.
[...]

Why would you avoid also adding it to the setup.cfg? The change you
cited is merely to be able to continue building universal wheels for
projects while the setup.cfg files are corrected over time, to
reduce the urgency of doing so. Wheel building happens in more
places than just our CI system, so only fixing it in CI is not a
good long-term strategy.
-- 
Jeremy Stanley


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

Re: [openstack-dev] Sphinx testing fun

2018-10-04 Thread Stephen Finucane

On Thu, 2018-10-04 at 07:21 -0400, Doug Hellmann wrote:
> Stephen Finucane  writes:
> 
> > The tests in os-api-ref recently broke:
> > 
> >   
> > http://logs.openstack.org/62/606362/1/check/openstack-tox-py35/8b709de/testr_results.html.gz
> > 
> > Specifically, we're seeing errors likes this:
> > 
> >   ft1.1: 
> > os_api_ref.tests.test_basic_example.TestBasicExample.test_rest_method_StringException:
> >  Traceback (most recent call last):
> > File 
> > "/home/zuul/src/git.openstack.org/openstack/os-api-ref/.tox/py35/lib/python3.5/site-packages/sphinx_testing/util.py",
> >  line 143, in decorator
> >func(*(args + (app, status, warning)), **kwargs)
> >  File 
> > "/home/zuul/src/git.openstack.org/openstack/os-api-ref/os_api_ref/tests/test_basic_example.py",
> >  line 41, in setUp
> >self.html = (app.outdir / 'index.html').read_text(encoding='utf-8')
> >TypeError: unsupported operand type(s) for /: 'str' and 'str'
> > 
> > Which is wrong because 'app.outdir' is not supposed to be an instance
> > of 'unicode' but rather 'sphinx_testing.path.path' [1] (which overrides
> > the '/' operator to act as concatenation because operator overloading
> > is always a good idea ) [2].
> 
> Is that a change in Sphinx's API? Or sphinx_testing's?

It's a change in Sphinx, though not in the API [1]. I should really
stop playing with Sphinx. 

> > 
> > Anyway, we can go figure out what's changed here and handle it but this
> > is, at best, going to be a band aid. The fact is 'sphinx_testing' is
> > unmaintained and has been for some time now. The new hotness is
> > 'sphinx.testing' [3], which is provided (with zero documentation) as
> > part of Sphinx. Unfortunately, this uses pytest fixtures [4] which I'm
> > pretty sure Monty (and a few others?) are vehemently against using in
> > OpenStack. That leaves us with three options:
> > 
> >  * Take over 'sphinx_testing' and bring it up-to-date. Maintain
> >forever.
> >  * Start using 'sphinx.testing' and everything it comes with
> >  * Delete any tests that use 'sphinx_testing' and deal with the lack of
> >coverage
> 
> Could we change our tests to use pathlib to wrap app.outdir and get the
> same results as before?

That's what I've done [2], which is kind of based on how I fixed this
in Sphinx. However, this is at best a stopgap. The fact remains that
'sphinx_testing' is dead and the large changes that Sphinx is
undergoing (2.0 will be Python 3 only, with multiple other fixes) will
make further breakages more likely. Unless we want a repeat of the Mox
situation, I do think we should start thinking about this sooner rather
than later.

Stephen

[1] https://github.com/sphinx-doc/sphinx/commit/3a85b3502f
[2] https://review.openstack.org/607984

> 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] [tripleo][puppet] clearing the gate and landing patches to help CI

2018-10-04 Thread Alex Schultz

And master is blocked again.  We need https://review.openstack.org/#/c/607952/

Thanks,
-Alex

On Fri, Sep 28, 2018 at 9:02 AM Alex Schultz  wrote:
>
> Hey Folks,
>
> Currently the tripleo gate is at 21 hours and we're continue to have
> timeouts and now scenario001/004 (in queens/pike) appear to be broken.
> Additionally we've got some patches in puppet-openstack that we need
> to land in order to resolve broken puppet unit tests which is
> affecting both projects.
>
> Currently we need to wait for the following to land in puppet:
> https://review.openstack.org/#/q/I4875b8bc8b2333046fc3a08b4669774fd26c89cb
> https://review.openstack.org/#/c/605350/
>
> In tripleo we currently have not identified the root cause for any of
> the timeout failures so I'd for us to work on that before trying to
> land anything else because the gate resets are killing us and not
> helping anything.  We have landed a few patches that have improved the
> situation but we're still hitting issues.
>
> https://bugs.launchpad.net/tripleo/+bug/1795009 is the bug for the
> scenario001/004 issues.  It appears that we're ending up with a newer
> version of ansible on the system then what the packages provide. Still
> working on figuring out where it's coming from.
>
> Please do not approve anything or recheck unless it's to address CI
> issues at this time.
>
> 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] Dose anyone have use Vitrage to build a mature project for RCA or any other purpose?

2018-10-04 Thread Ifat Afek

On Wed, Sep 5, 2018 at 4:59 AM zhangwenqing <18800173...@163.com> wrote:

> Thanks for your reply!
> So how do you analyse the RCA?Do you ever use any statistics methods like 
> time series or mathine learning methods?Or just use the method that Vitrage 
> provides?
>
>
> zhangwenqing
>
>
Hi,

Sorry for the late reply, I somehow missed your mail.

Vitrage is not a monitoring tool. It does not perform statistic
calculations, health checks, etc. Instead, it gets topology and alarms from
several datasources (OpenStack or external), combines them in a topology
graph, and performs RCA analysis on top of the graph.

The RCA rules are defined in Vitrage templates [1]. In these templates, you
can define topology conditions and actions to be executed as a result, like
raise an additional alarm, modify a resource state, or mark root-cause
relationship between two alarms.

[1]
https://docs.openstack.org/vitrage/latest/contributor/vitrage-template-format.html

Hope it helps,

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

Re: [openstack-dev] [all] Zuul job backlog

2018-10-04 Thread Clark Boylan

On Thu, Oct 4, 2018, at 12:16 AM, Abhishek Kekane wrote:
> Hi,
> Could you please point out some of the glance functional tests which are
> failing and causing this resets?
> I will like to put some efforts towards fixing those.

http://status.openstack.org/elastic-recheck/data/integrated_gate.html is a good 
place to start. That shows you a list of tests that failed in the OpenStack 
Integrated gate that elastic-recheck could not identify the failure for 
including those for several functional jobs.

If you'd like to start looking at identified bugs first then 
http://status.openstack.org/elastic-recheck/gate.html shows identified failures 
that happened in the gate.

For glance functional jobs the first link points to:
http://logs.openstack.org/99/595299/1/gate/openstack-tox-functional/fc13eca/
http://logs.openstack.org/44/569644/3/gate/openstack-tox-functional/b7c487c/
http://logs.openstack.org/99/595299/1/gate/openstack-tox-functional-py35/b166313/
http://logs.openstack.org/44/569644/3/gate/openstack-tox-functional-py35/ce262ab/

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][Searchlight] Always build universal wheels

2018-10-04 Thread Trinh Nguyen

Hi team,

Not sure if anyone is aware of [1] in openstack-infra that is trying to
always build universal wheels by default for all projects. Please avoid
adding universal wheels to the project setup.cfg.

Bests,

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

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

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

2018-10-04 Thread Ifat Afek

Hi,

Can you please give us some more details about your scenario with
Prometheus? Please try and give as many details as possible, so we can try
to reproduce the bug.

What do you mean by “if the alarm is resolved, the alarm manager makes a
silence, or removes the alarm rule from Prometheus”? these are different
cases. None of them works in your environment?

Which Prometheus and Alertmanager versions are you using?

 Please try to change the Vitrage loglevel to DEBUG (set “debug = true” in
/etc/vitrage/vitrage.conf) and send me the Vitrage collector, graph and api
logs.

Regarding the multi nodes, I'm not sure I understand your configuration. Do
you mean there is more than one OpenStack and Nova? more than one host?
more than one vm?

Basically, vms are deleted from Vitrage in two cases:
1. After each periodic call to get_all of nova.instance datasource. By
default this is done once in 10 minutes.
2. Immediately, if you have the following configuration in
/etc/nova/nova.conf:
notification_topics = notifications,vitrage_notifications

So, please check your nova.conf and also whether the vms are deleted after
10 minutes.

Thanks,
Ifat

On Thu, Oct 4, 2018 at 7:12 AM Won  wrote:

> Thank you for your reply Ifat.
>
> The alertmanager.yml file already contains 'send_resolved:true'.
> However, the alarm does not disappear from the alarm list and the entity
> graph even if the alarm is resolved, the alarm manager makes a silence, or
> removes the alarm rule from Prometheus.
> The only way to remove alarms is to manually remove them from the db. Is
> there any other way to remove the alarm?
> Entities(vm) that run on multi nodes in the rocky version have similar
> symptoms. There was a symptom that the Entities created on the multi-node
> would not disappear from the Entity Graph even after deletion.
> Is this a bug in rocky version?
>
> Best Regards,
> Won
>
>
__
OpenStack Development Mailing 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] [placement] [infra] [qa] tuning some zuul jobs from "it works" to "proper"

2018-10-04 Thread Chris Dent


On Wed, 3 Oct 2018, Chris Dent wrote:

I'd really like to see this become a real thing, so if I could get
some help from tempest people on how to make it in line with
expectations that would be great.


I've written up the end game of what I'm trying to achieve in a bit
more detail at https://anticdent.org/gabbi-in-the-gate.html

--
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] [nova][xenapi] can we deprecate the xenapi-specific 'nova-console' service?

2018-10-04 Thread Stephen Finucane

On Thu, 2018-10-04 at 12:03 +, Bob Ball wrote:
> Hi Melanie,
> 
> We recommend using novncproxy_base_url with
> vncserver_proxyclient_address set to the dom0's management IP
> address.
> 
> We don't currently use nova-console, so deprecation would be the best
> approach.
> 
> Thanks,
> 
> Bob

What about nova-xvpvncproxy [1]? This would be configured using
xvpvncproxy_base_url. This is also Xen-specific (as the name, Xen VNC
Proxy, would suggest). If the noVNC-based console is now recommended,
can we also deprecate the XVP one?

Stephen

[1] 
https://review.openstack.org/#/c/606148/5/doc/source/admin/remote-console-access.rst@313

> -Original Message-
> From: melanie witt [mailto:melwi...@gmail.com] 
> Sent: 03 October 2018 23:08
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>; 
> openstack-operat...@lists.openstack.org
> Subject: [openstack-dev] [nova][xenapi] can we deprecate the xenapi-
> specific 'nova-console' service?
> 
> Greetings Devs and Ops,
> 
> Today I noticed that our code does not handle the 'nova-console'
> service properly in a multi-cell deployment and given that no one has
> complained or reported bugs about it, we're wondering if anyone still
> uses the nova-console service. The documentation [1] says that the
> nova-console service is a "XenAPI-specific service that most recent
> VNC proxy architectures do not use."
> 
> Can anyone from xenapi land shed some light on whether the nova-
> console service is still useful in deployments using the xenapi
> driver, or is it an old relic that we should deprecate and remove?
> 
> Thanks for your help,
> -melanie
> 
> [1] 
> https://docs.openstack.org/nova/latest/admin/remote-console-access.html 
> class="Apple-tab-span" style="white-space:pre">   
>   
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [nova][xenapi] can we deprecate the xenapi-specific 'nova-console' service?

2018-10-04 Thread Bob Ball

Hi Melanie,

We recommend using novncproxy_base_url with vncserver_proxyclient_address set 
to the dom0's management IP address.

We don't currently use nova-console, so deprecation would be the best approach.

Thanks,

Bob

-Original Message-
From: melanie witt [mailto:melwi...@gmail.com] 
Sent: 03 October 2018 23:08
To: OpenStack Development Mailing List (not for usage questions) 
; openstack-operat...@lists.openstack.org
Subject: [openstack-dev] [nova][xenapi] can we deprecate the xenapi-specific 
'nova-console' service?

Greetings Devs and Ops,

Today I noticed that our code does not handle the 'nova-console' service 
properly in a multi-cell deployment and given that no one has complained or 
reported bugs about it, we're wondering if anyone still uses the nova-console 
service. The documentation [1] says that the nova-console service is a 
"XenAPI-specific service that most recent VNC proxy architectures do not use."

Can anyone from xenapi land shed some light on whether the nova-console service 
is still useful in deployments using the xenapi driver, or is it an old relic 
that we should deprecate and remove?

Thanks for your help,
-melanie

[1] https://docs.openstack.org/nova/latest/admin/remote-console-access.html 

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

Re: [openstack-dev] Sphinx testing fun

Stephen Finucane  writes:

> The tests in os-api-ref recently broke:
>
>   
> http://logs.openstack.org/62/606362/1/check/openstack-tox-py35/8b709de/testr_results.html.gz
>
> Specifically, we're seeing errors likes this:
>
>   ft1.1: 
> os_api_ref.tests.test_basic_example.TestBasicExample.test_rest_method_StringException:
>  Traceback (most recent call last):
> File 
> "/home/zuul/src/git.openstack.org/openstack/os-api-ref/.tox/py35/lib/python3.5/site-packages/sphinx_testing/util.py",
>  line 143, in decorator
>func(*(args + (app, status, warning)), **kwargs)
>  File 
> "/home/zuul/src/git.openstack.org/openstack/os-api-ref/os_api_ref/tests/test_basic_example.py",
>  line 41, in setUp
>self.html = (app.outdir / 'index.html').read_text(encoding='utf-8')
>TypeError: unsupported operand type(s) for /: 'str' and 'str'
>
> Which is wrong because 'app.outdir' is not supposed to be an instance
> of 'unicode' but rather 'sphinx_testing.path.path' [1] (which overrides
> the '/' operator to act as concatenation because operator overloading
> is always a good idea ) [2].

Is that a change in Sphinx's API? Or sphinx_testing's?

>
> Anyway, we can go figure out what's changed here and handle it but this
> is, at best, going to be a band aid. The fact is 'sphinx_testing' is
> unmaintained and has been for some time now. The new hotness is
> 'sphinx.testing' [3], which is provided (with zero documentation) as
> part of Sphinx. Unfortunately, this uses pytest fixtures [4] which I'm
> pretty sure Monty (and a few others?) are vehemently against using in
> OpenStack. That leaves us with three options:
>
>  * Take over 'sphinx_testing' and bring it up-to-date. Maintain
>forever.
>  * Start using 'sphinx.testing' and everything it comes with
>  * Delete any tests that use 'sphinx_testing' and deal with the lack of
>coverage

Could we change our tests to use pathlib to wrap app.outdir and get the
same results as before?

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-dev] Sphinx testing fun

2018-10-04 Thread Stephen Finucane

The tests in os-api-ref recently broke:

  
http://logs.openstack.org/62/606362/1/check/openstack-tox-py35/8b709de/testr_results.html.gz

Specifically, we're seeing errors likes this:

  ft1.1: 
os_api_ref.tests.test_basic_example.TestBasicExample.test_rest_method_StringException:
 Traceback (most recent call last):
File 
"/home/zuul/src/git.openstack.org/openstack/os-api-ref/.tox/py35/lib/python3.5/site-packages/sphinx_testing/util.py",
 line 143, in decorator
   func(*(args + (app, status, warning)), **kwargs)
 File 
"/home/zuul/src/git.openstack.org/openstack/os-api-ref/os_api_ref/tests/test_basic_example.py",
 line 41, in setUp
   self.html = (app.outdir / 'index.html').read_text(encoding='utf-8')
   TypeError: unsupported operand type(s) for /: 'str' and 'str'

Which is wrong because 'app.outdir' is not supposed to be an instance
of 'unicode' but rather 'sphinx_testing.path.path' [1] (which overrides
the '/' operator to act as concatenation because operator overloading
is always a good idea ) [2].

Anyway, we can go figure out what's changed here and handle it but this
is, at best, going to be a band aid. The fact is 'sphinx_testing' is
unmaintained and has been for some time now. The new hotness is
'sphinx.testing' [3], which is provided (with zero documentation) as
part of Sphinx. Unfortunately, this uses pytest fixtures [4] which I'm
pretty sure Monty (and a few others?) are vehemently against using in
OpenStack. That leaves us with three options:

 * Take over 'sphinx_testing' and bring it up-to-date. Maintain
   forever.
 * Start using 'sphinx.testing' and everything it comes with
 * Delete any tests that use 'sphinx_testing' and deal with the lack of
   coverage

For what it's worth, I use 'sphinx.testing' in 'sphinxcontrib-apidoc'
[5] without *too* many issues, but that lives outside the 'openstack'
namespace and isn't bound by upper-constraints and the likes.

Stephen

[1] 
https://github.com/sphinx-doc/sphinx-testing/blob/0.7.2/src/sphinx_testing/path.py#L217
[2] 
https://github.com/sphinx-doc/sphinx-testing/blob/0.7.2/src/sphinx_testing/util.py#L45-L63
[3] https://github.com/sphinx-doc/sphinx/tree/v1.8.0/sphinx/testing
[4] https://docs.pytest.org/en/latest/fixture.html
[5] https://github.com/sphinx-contrib/apidoc/blob/0.3.0/tests/test_ext.py


__
OpenStack Development Mailing 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] [glance] Glance API Caching Enhancements for Edge Computing

Geeg,

Glance uses launchpad for blueprints and for specs you can refer to
glance-specs repo.

Thank you,

Abhishek

On Thu 4 Oct, 2018, 16:14 Waines, Greg,  wrote:

> I have not yet done a blueprint or spec for this in Glance.
>
> But can do that now.
>
>
>
> Is Glance using Launchpad or Storyboard ?
>
>
>
> Greg.
>
>
>
>
>
>
>
> *From: *Abhishek Kekane 
> *Reply-To: *"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> *Date: *Thursday, October 4, 2018 at 2:08 AM
> *To: *"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [glance] Glance API Caching Enhancements
> for Edge Computing
>
>
>
> Hi Greg,
>
>
>
> Have you actually filed a blueprint or specs for this in glance?
>
> If yes could you please provide a reference for the same.
>
>
>
>
> Thanks & Best Regards,
>
> Abhishek Kekane
>
>
>
>
>
> On Thu, Oct 4, 2018 at 12:34 AM Waines, Greg 
> wrote:
>
> Glance Team,
>
>
>
> I am following up on discussions in the edge-computing PTG meetings.
>
> There were discussions on potential enhancements to Glance API Caching for
> support of the proposed MVP Edge Architecture.
>
> And I took the action to write up a blueprint and a specification for
> these enhancements ... and will follow up with implementation.
>
>
>
> I thought I’d start the discussions on the mailing list ... and if
> everyone is still in agreement,
>
> then I’ll move the high-level definition/requirements to Glance’s
> Launchpad (or Storyboard?) and
>
> write up a Glance spec and review it in Gerrit.
>
>
>
> *THE PROPOSAL:*
>
>
>
> Enhance Glance API Caching such that
>
> a)   It works between two Glance Services (i.e. Glance at a Central
> OpenStack Cloud and Glance at an Edge OpenStack Cloud)
>
> · i.e. current Glance API Caching only works with external
> webservers
>
> b)   Enable the Edge Cloud Glance API Caching to support the ability
> to locally use those cached images (e.g. nova boot ...)
> even when network connectivity is lost to the Central Cloud Glance Service
>
> · i.e. image meta-data is required in order to service a ‘nova
> boot ...’, and
>today image meta-data is NOT cached by Glance API Caching.
>
>
>
> The proposed solution should generically work between any two Glance
> Services.
>
> e.g.
>
> · in a Multi-Region Environment,
>
> · in a StarlingX Distributed Cloud,
>
> · etc.
>
>
>
> The proposed solution need only deal with the Edge Cloud Glance talking to
> a single Central Cloud Glance.
>
>
>
>
>
> Let me know if you have any a questions or comments,
>
> Greg.
>
>
>
>
>
>
>
> p.s.
>
> *Background:*
>
> More info on the edge-computing group’s MVP Edge Architecture can be found
> here:
>
>
> https://www.dropbox.com/s/255x1cao14taer3/MVP-Architecture_edge-computing_PTG.pptx?dl=0
>
> and
>
>
> https://docs.google.com/document/d/1Mq6bSm_lES56S4gygEuhmMbEeCI2nBFl_U5vl50wih8/edit?ts=5baa654e#heading=h.ncllqse6iw0u
>
> __
> OpenStack Development Mailing 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] [glance] Glance API Caching Enhancements for Edge Computing

2018-10-04 Thread Waines, Greg

I have not yet done a blueprint or spec for this in Glance.
But can do that now.

Is Glance using Launchpad or Storyboard ?

Greg.



From: Abhishek Kekane 
Reply-To: "openstack-dev@lists.openstack.org" 

Date: Thursday, October 4, 2018 at 2:08 AM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [glance] Glance API Caching Enhancements for Edge 
Computing

Hi Greg,

Have you actually filed a blueprint or specs for this in glance?
If yes could you please provide a reference for the same.


Thanks & Best Regards,
Abhishek Kekane


On Thu, Oct 4, 2018 at 12:34 AM Waines, Greg 
mailto:greg.wai...@windriver.com>> wrote:
Glance Team,

I am following up on discussions in the edge-computing PTG meetings.
There were discussions on potential enhancements to Glance API Caching for 
support of the proposed MVP Edge Architecture.
And I took the action to write up a blueprint and a specification for these 
enhancements ... and will follow up with implementation.

I thought I’d start the discussions on the mailing list ... and if everyone is 
still in agreement,
then I’ll move the high-level definition/requirements to Glance’s Launchpad (or 
Storyboard?) and
write up a Glance spec and review it in Gerrit.

THE PROPOSAL:

Enhance Glance API Caching such that

a)   It works between two Glance Services (i.e. Glance at a Central 
OpenStack Cloud and Glance at an Edge OpenStack Cloud)

• i.e. current Glance API Caching only works with external webservers

b)   Enable the Edge Cloud Glance API Caching to support the ability to 
locally use those cached images (e.g. nova boot ...)
even when network connectivity is lost to the Central Cloud Glance Service

• i.e. image meta-data is required in order to service a ‘nova boot 
...’, and
   today image meta-data is NOT cached by Glance API Caching.

The proposed solution should generically work between any two Glance Services.
e.g.

• in a Multi-Region Environment,

• in a StarlingX Distributed Cloud,

• etc.

The proposed solution need only deal with the Edge Cloud Glance talking to a 
single Central Cloud Glance.


Let me know if you have any a questions or comments,
Greg.



p.s.
Background:
More info on the edge-computing group’s MVP Edge Architecture can be found here:
 
https://www.dropbox.com/s/255x1cao14taer3/MVP-Architecture_edge-computing_PTG.pptx?dl=0
and
 
https://docs.google.com/document/d/1Mq6bSm_lES56S4gygEuhmMbEeCI2nBFl_U5vl50wih8/edit?ts=5baa654e#heading=h.ncllqse6iw0u
__
OpenStack Development Mailing 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] Zuul job backlog

Hi,
Could you please point out some of the glance functional tests which are
failing and causing this resets?
I will like to put some efforts towards fixing those.

Thanks & Best Regards,

Abhishek Kekane


On Wed, Oct 3, 2018 at 10:14 PM Doug Hellmann  wrote:

> Wesley Hayutin  writes:
>
> [snip]
>
> > The TripleO project has created a single node container based composable
> > OpenStack deployment [2]. It is the projects intention to replace most of
> > the TripleO upstream jobs with the Standalone deployment.  We would like
> to
> > reduce our multi-node usage to a total of two or three multinode jobs to
> > handle a basic overcloud deployment, updates and upgrades[a]. Currently
> in
> > master we are relying on multiple multi-node scenario jobs to test many
> of
> > the OpenStack services in a single job. Our intention is to move these
> > multinode scenario jobs to single node job(s) that tests a smaller subset
> > of services. The goal of this would be target the specific areas of the
> > TripleO code base that affect these services and only run those there.
> This
> > would replace the existing 2-3 hour two node job(s) with single node
> job(s)
> > for specific services that completes in about half the time.  This
> > unfortunately will reduce the overall coverage upstream but still allows
> us
> > a basic smoke test of the supported OpenStack services and their
> deployment
> > upstream.
> >
> > Ideally projects other than TripleO would make use of the Standalone
> > deployment to test their particular service with containers, upgrades or
> > for various other reasons.  Additional projects using this deployment
> would
> > help ensure bugs are found quickly and resolved providing additional
> > resilience to the upstream gate jobs. The TripleO team will begin review
> to
> > scope out and create estimates for the above work starting on October 18
> > 2018.  One should expect to see updates on our progress posted to the
> > list.  Below are some details on the proposed changes.
>
> [snip]
>
> Thanks for all of the details, Wes. I know the current situation has
> been hurting the TripleO team as well, so I'm glad to see a good plan in
> place to address it. I look forward to seeing updates about the
> progress.
>
> 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] [glance] Glance API Caching Enhancements for Edge Computing