Re: [openstack-dev] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Tony Breeds]

On Tue, Aug 14, 2018 at 04:22:16PM -0400, Doug Hellmann wrote:

> Now that https://review.openstack.org/#/c/591671/ has landed, we need
> someone to propose the backports of the constraint updates to all of the
> existing stable branches.

Done:
https://review.openstack.org/#/q/owner:tonyb+topic:openstackdocstheme+project:openstack/requirements

I'm not entirely convinced such a new release will work on older
branches but I guess that's what CI is for :)

Yours Tony.


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

Re: [openstack-dev] [tempest][qa][congress] help with tempest plugin jobs against stable/queens

[Ghanshyam Mann]

  On Wed, 15 Aug 2018 09:37:18 +0900 Eric K  
wrote  
 > I'm adding jobs [1] to the tempest plugin to run tests against
 > congress stable/queens. The job output seems to show stable/queens
 > getting checked out [2], but I know the test is *not* run against
 > queens because it's using features not available in queens. The
 > expected result is for several tests to fail as seen here [3]. All
 > hints and tips much appreciated!

You are doing it in right way by 'override-checkout: stable/queens'. And as log 
also show, congress is checkout from stable/queens. I tried to check the 
results but could not get what tests should fail and why. 

If you can give me more idea, i can debug that. 

-gmann

 > 
 > [1] https://review.openstack.org/#/c/591861/1
 > [2] 
 > http://logs.openstack.org/61/591861/1/check/congress-devstack-api-mysql-queens/f7b5752/job-output.txt.gz#_2018-08-14_22_30_36_899501
 > [3] https://review.openstack.org/#/c/591805/ (the depends-on is
 > irrelevant because that patch has been merged)
 > 
 > __
 > OpenStack Development Mailing 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] [tempest][qa][congress] tempest test conditioning on release version

[Ghanshyam Mann]

  On Wed, 15 Aug 2018 06:40:57 +0900 Eric K  
wrote  
 > Anyone have an example handy of a tempest test conditioning on service
 > release version (because new features not available in past versions)?
 > Seems like it could get pretty messy and haphazard, so I'm curious to
 > see best practices. Thanks lots!

Thanks Eric for query. We do it in many times in Tempest and similar approach 
can be adopt by tempest plugins. There are 2 ways we can handle  this-

1. Using feature flag. Tempest documentation is here [1].
 Step1- This is simply adding a config options(feature flag) for new/old 
feature. 
 Example- https://review.openstack.org/#/c/545627/   
https://github.com/openstack/tempest/blob/6a8d495192632fd18dce4baf1a4b213f401a0167/tempest/config.py#L242
 Step2- Based on that flag you can skip the tests where that feature is not 
available. 
 Example-  
https://github.com/openstack/tempest/blob/d5058a8a9c8c1c5383699d04296087b6d5a24efd/tempest/api/identity/base.py#L315
 Step3- For gate, devstack plugin on project side (congress is your case [2]) 
which is branch aware can set that flag to true and false based on which branch 
that test is running. For tempest we do the same from devstack/lib/tempest
 Example - https://review.openstack.org/#/c/545680/
https://github.com/openstack-dev/devstack/blob/8c1052001629d62f001d04c182500fa293858f47/lib/tempest#L308
 Step4- For cloud testing(non-gate), tester can manually configure the those 
flag based on what service version they are testing. 

2. Detecting service version via version API
- If you can get the service version info from API then you can use that while 
skipping the tests.
- One example if for compute where based on microversion, it can be detected 
that test running against which release. 
- Example- 
https://github.com/openstack/tempest/blob/d5058a8a9c8c1c5383699d04296087b6d5a24efd/tempest/api/compute/base.py#L114


[1] 
https://docs.openstack.org/tempest/latest/HACKING.html#branchless-tempest-considerations
[2] 
https://github.com/openstack/congress/blob/014361c809517661264d0364eaf1e261e449ea80/devstack/plugin.sh#L88

 > 
 > Eric Kao
 > 
 > __
 > OpenStack Development Mailing 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] [tempest][qa][congress] help with tempest plugin jobs against stable/queens

[Eric K]

I'm adding jobs [1] to the tempest plugin to run tests against
congress stable/queens. The job output seems to show stable/queens
getting checked out [2], but I know the test is *not* run against
queens because it's using features not available in queens. The
expected result is for several tests to fail as seen here [3]. All
hints and tips much appreciated!

[1] https://review.openstack.org/#/c/591861/1
[2] 
http://logs.openstack.org/61/591861/1/check/congress-devstack-api-mysql-queens/f7b5752/job-output.txt.gz#_2018-08-14_22_30_36_899501
[3] https://review.openstack.org/#/c/591805/ (the depends-on is
irrelevant because that patch has been merged)

__
OpenStack Development Mailing 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] [First Contact] [SIG] [PTL] Project Liaisons - Please update list

[Matthew Oliver]

Greetings new and continuing PTLs!

Now that the PTL elections are over may I ask those of you who haven't done
so already to head on over to the First Contact SIG Project Liaison list
[0] and make sure you details, especially timezone has been filled out?

We of the First Contact SIG are striving to provide a place for new
contributors to come and get help, advice, and to better get connected to
our awesome online community. But we can only to that if we have coverage
of projects. As Kendall mentioned in a previous email [1], unless the
liaison for a project is filled by a volunteer, or better yet multiple
volunteers, the liaison for a project it will default to the PTL.

Please update your details in the list and provide your timezone, this will
not only let us know you've looked, but also shows us that you are engaged.
What do liaisons do? You'll be the point of call for new contributors. This
could be a SIG member adding you to a gerrit review of a new contributor to
help engage and show some review love, or being introduced to new
contributors to your project via email or IRC.

Why is your timezone important? Because new contributors are coming from
all around the globe and ideally we'd love to have not only project
coverage but timezone as well. This way be can get support and
encouragement to new contributors even in timezones that aren't covered.
For example, I'm in Australia, so I'm available in the APAC timezone. I can
reach out and help a new contributor even if they're interested in a
project I'm not familiar with, we are all one team, and their problems may
be generic enough I can help. If not, I can point them to a liaison that
can, hopefully in a closer timezone, but if not at least get them connected
via email.

As a SIG we are trying to help support new contributors, get them engaged,
and lower the bar to entry. Especially keeping there excitement up when
they get their first few patches in. Please partner with us and lets grow
the community.

Regards,
Matt

[0] - https://wiki.openstack.org/wiki/First_Contact_SIG#Project_Liaisons
[1] -
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131264.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

Re: [openstack-dev] [oslo][mox][python3][goal] need help with mox3 and python 3.6

[Doug Hellmann]

Excerpts from Zane Bitter's message of 2018-08-14 16:26:09 -0500:
> On 14/08/18 15:45, Doug Hellmann wrote:
> > The python 3.6 unit test job has exposed an issue with mox3. It looks
> > like it might just be in the test suite, but I can't tell.
> > 
> > I'm looking for one of the folks who suggested we should just keep
> > maintaining mox3 to help fix it. Please go ahead and take over the
> > relevant patch and include whatever changes are needed.
> > 
> > https://review.openstack.org/#/c/589591/
> 
> I'm not one of those people (and I'm not oblivious to the fact that this 
> was a not-especially-subtly coded message for mriedem), but I fixed it.
> 
> Please don't make me a maintainer now ;)
> 
> cheers,
> Zane.
> 

I'm not a maintainer myself, but if I *was* a maintainer your behavior
here would clearly need to be answered by adding you to that team. So,
watch yourself. ;-)

And thank you.

Doug

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

[openstack-dev] [tempest][qa][congress] tempest test conditioning on release version

[Eric K]

Anyone have an example handy of a tempest test conditioning on service
release version (because new features not available in past versions)?
Seems like it could get pretty messy and haphazard, so I'm curious to
see best practices. Thanks lots!

Eric Kao

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

Re: [openstack-dev] [oslo][mox][python3][goal] need help with mox3 and python 3.6

[Zane Bitter]

On 14/08/18 15:45, Doug Hellmann wrote:

The python 3.6 unit test job has exposed an issue with mox3. It looks
like it might just be in the test suite, but I can't tell.

I'm looking for one of the folks who suggested we should just keep
maintaining mox3 to help fix it. Please go ahead and take over the
relevant patch and include whatever changes are needed.

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


I'm not one of those people (and I'm not oblivious to the fact that this 
was a not-especially-subtly coded message for mriedem), but I fixed it.


Please don't make me a maintainer now ;)

cheers,
Zane.

__
OpenStack Development Mailing 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] [oslo][mox][python3][goal] need help with mox3 and python 3.6

[Doug Hellmann]

The python 3.6 unit test job has exposed an issue with mox3. It looks
like it might just be in the test suite, but I can't tell.

I'm looking for one of the folks who suggested we should just keep
maintaining mox3 to help fix it. Please go ahead and take over the
relevant patch and include whatever changes are needed.

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

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] [ironic] ironic-staging-drivers: what to do?

[Ruby Loo]

Hi Julia,

Thanks for bringing this up.


On Mon, Aug 13, 2018, 2:41 PM Julia Kreger, 
wrote:

> Greetings fellow ironicans!
>
> As many of you might know an openstack/ironic-staging-drivers[1]
> repository exists. What most might not know is that it was
> intentionally created outside of ironic's governance[2].
>
> At the time it was created ironic was moving towards removing drivers
> that did not meet our third-party CI requirement[3] to be in-tree. The
> repository was an attempt to give a home to what some might find
> useful or where third party CI is impractical or cost-prohibitive and
> thus could not be officially part of Ironic the service. There was
> hope that drivers could land in ironic-staging-drivers and possibly
> graduate to being moved in-tree with third-party CI. As our community
> has evolved we've not stopped and revisited the questions.
>
> With our most recent release over, I believe we need to ask ourselves
> if we should consider moving ironic-staging-drivers into our
> governance.
>
> Over the last couple of releases several contributors have found
> themselves trying to seek out two available reviewers to merge even
> trivial fixes[4]. Due to the team being so small this was no easy
> task. As a result, I'm wondering why not move the repository into
> governance, grant ironic-core review privileges upon the repository,
> and maintain the purpose and meaning of the repository. This would
> also result in the repository's release becoming managed via the
> release management process which is a plus.
>

If I understand, it seems like the main issue is lack of reviewers. As
mentioned by others, I would not be opposed to adding existing ironic cores
to this repo.
Whether folks review is a different question.

We could then propose an actual graduation process and help alleviate
> some of the issues where driver code is iterated upon for long periods
> of time before landing. At the same time I can see at least one issue
> which is if we were to do that, then we would also need to manage
> removal through the same path.
>

I am not sure I see any advantages to this. The ansible driver was in the
staging repo for awhile before it went into ironic so we know that is
do-able :)


> I know there are concerns over responsibility in terms of code
> ownership and quality, but I feel like we already hit such issues[5],
> like those encountered when Dmitry removed classic drivers[6] from the
> repository and also encountered issues just prior to the latest
> release[7][8].
>

I don't mind making changes or reviewing changes to this repo, especially
if there are unit tests. However, that is the most responsibility I am
comfortable having with this repo.

Right now, I don't see any good reasons for putting it under the ironic
governance. I am, of course, open to being convinced otherwise!

--ruby


> This topic has come up in passing at PTGs and most recently on IRC[9],
> and I think we ought to discuss it during our next weekly meeting[10].
> I've gone ahead and added an item to the agenda, but we can also
> discuss via email.


> -Julia
>
> [1]:
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml#n4571
> [2]:
> http://git.openstack.org/cgit/openstack/ironic-staging-drivers/tree/README.rst#n16
> [3]:
> https://specs.openstack.org/openstack/ironic-specs/specs/approved/third-party-ci.html
> [4]: https://review.openstack.org/#/c/548943/
> [5]: https://review.openstack.org/#/c/541916/
> [6]: https://review.openstack.org/567902
> [7]: https://review.openstack.org/590352
> [8]: https://review.openstack.org/590401
> [9]:
> http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2018-08-09.log.html#t2018-08-09T11:55:27
> [10]:
> https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-08-13 18:30:02 -0400:
> Excerpts from Matthew Thode's message of 2018-08-13 16:17:30 -0500:
> > On 18-08-13 20:28:23, Andreas Jaeger wrote:
> > > On 2018-08-13 19:16, Andreas Jaeger wrote:
> > > > On 2018-08-13 18:40, Petr Kovar wrote:
> > > > > Hi all,
> > > > > 
> > > > > This is a request for an FFE to release openstackdocstheme 1.21.2.
> > > > 
> > > > 
> > > > > This mostly fixes usability issues in rendering docs content, so we 
> > > > > would
> > > > > like to update the theme across all project team docs on docs.o.o.
> > > > 
> > > > I suggest to release quickly a 1.21.3 with
> > > > https://review.openstack.org/#/c/585517/ - and use that one instead.
> > > 
> > > Release request:
> > > https://review.openstack.org/591485
> > > 
> > 
> > Would this be a upper-constraint only bump?
> > 
> > If so reqs acks it
> 
> We need, eventually, to retrigger documentation builds in all of the
> open branches using this new version of the theme so we can inject the
> status info into those old pages. We will have an opportunity to trigger
> those builds when we move the zuul configuration into each repo as part
> of the python3 goal this cycle.
> 
> So, for now we need to update the constraints list on master. But we
> also need to work quickly to update the constraints lists in the open
> branches so that is done before we approve the goal-related changes in
> those branches.
> 
> Doug

Now that https://review.openstack.org/#/c/591671/ has landed, we need
someone to propose the backports of the constraint updates to all of the
existing stable branches.

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] Speaker Selection Process: OpenStack Summit Berlin

[Jimmy McArthur]

Hi Hongbin,

Please see below for some general notes...

Hongbin Lu wrote:



On Mon, Aug 13, 2018 at 9:53 AM Jimmy McArthur > wrote:


Greetings!

The speakers for the OpenStack Summit Berlin will be announced
August 14, at 4:00 AM UTC. Ahead of that, we want to take this
opportunity to thank our Programming Committee!  They have once
again taken time out of their busy schedules to help create
another round of outstanding content for the OpenStack Summit.

The OpenStack Foundation relies on the community-nominated
Programming Committee, along with your Community Votes to select
the content of the summit.  If you're curious about this process,
you can read more about it here


where we have also listed the Programming Committee members.


Hi, I particularly want to know the process of selecting Programming 
Committee of each track. You mentioned that the Programming Committee 
is "community-nominated" but there is no information about how to 
select among the list of "community-nominated" candidates. If there 
are multiple candidates self-nominating themselves, how to ensure the 
process of selecting Programming Committee members is fair and 
transparent?
We announce public track chair nominations, but it's true that we 
haven't published the nominees in the past.  Moving forward, we'll 
publish those to the MLs.


We do publish the selected track chairs as we did this year for Berlin 
.  
These are selected from a pool of volunteers (self-nominated or 
otherwise) and, for the most part, we do not have a large pool of people 
to choose from.  Programming Committee work can be a bit arduous and 
that's why we're so thankful for the hard work our volunteers put in 
each Summit.  We literally couldn't do it without them.


If you feel you could help with the process, I encourage you to 
volunteer for the Denver 2019 Summit Programming Committee: 
https://openstackfoundation.formstack.com/forms/openstackdenver2019_programmingcommitteenom 



I asked that because I have an impression that the selection of 
Programming Committee members has a significant impact on the final 
selected content of the summit, and the final selected content has 
impacts on the visibility of each OpenStack official project. It also 
appears that if a specific project is not well represented on its 
relevant track of the Programming Committee, none of the 
project-related talks was selected. I would wonder if the selection 
process is fair and give visibility of each official proj
Every project at the summit has the opportunity to submit both a Project 
Update and a Project Onboarding session, outside of the CFP. If an 
community project wants that space, it's guaranteed. In addition to the 
CFP, the Forum presents an additional opportunity for projects to speak 
to the community.


On top of that, we encourage diversity in selection of all presentations 
for the CFP.  Including but not limited to diversity in corporate, 
gender, project, etc... Beyond that, our track chairs have the 
discretion to select the best content from a field of high quality 
submissions.


Finally, if you feel a project is underrepresented in the community, we 
strongly encourage you to reach out to local user groups and to present 
your content there: 
https://openstackfoundation.formstack.com/forms/user_group_presentation_form  
This is both a great for community outreach and an opportunity to help 
gain support for a project, SIG, etc...


Cheers,
Jimmy



If you'd like to nominate yourself or someone you know for the
OpenStack Summit Denver Programming Committee, you can do so here: *

*https://openstackfoundation.formstack.com/forms/openstackdenver2019_programmingcommitteenom

Thanks a bunch and we look forward to seeing everyone in Berlin!

Cheers,
Jimmy
*



*
__
OpenStack Development Mailing 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] Speaker Selection Process: OpenStack Summit Berlin

[Hongbin Lu]

On Mon, Aug 13, 2018 at 9:53 AM Jimmy McArthur  wrote:

> Greetings!
>
> The speakers for the OpenStack Summit Berlin will be announced August 14,
> at 4:00 AM UTC. Ahead of that, we want to take this opportunity to thank
> our Programming Committee!  They have once again taken time out of their
> busy schedules to help create another round of outstanding content for the
> OpenStack Summit.
>
> The OpenStack Foundation relies on the community-nominated Programming
> Committee, along with your Community Votes to select the content of the
> summit.  If you're curious about this process, you can read more about it
> here
> 
> where we have also listed the Programming Committee members.
>

Hi, I particularly want to know the process of selecting Programming
Committee of each track. You mentioned that the Programming Committee is
"community-nominated" but there is no information about how to select among
the list of "community-nominated" candidates. If there are multiple
candidates self-nominating themselves, how to ensure the process of
selecting Programming Committee members is fair and transparent?

I asked that because I have an impression that the selection of Programming
Committee members has a significant impact on the final selected content of
the summit, and the final selected content has impacts on the visibility of
each OpenStack official project. It also appears that if a specific project
is not well represented on its relevant track of the Programming Committee,
none of the project-related talks was selected. I would wonder if the
selection process is fair and give visibility of each official project?


>
> If you'd like to nominate yourself or someone you know for the OpenStack
> Summit Denver Programming Committee, you can do so here:
>
> https://openstackfoundation.formstack.com/forms/openstackdenver2019_programmingcommitteenom
>
> Thanks a bunch and we look forward to seeing everyone in Berlin!
>
> Cheers,
> Jimmy
>
>
>
>
> *
> *
> __
> OpenStack Development Mailing 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] migrating to storyboard

[Kendall Nelson]

Hello!

The error you hit can be resolved by adding launchpadlib to your tox.ini if
I recall correctly..

also, if you'd like, I can run a test migration of puppet's launchpad
projects into our storyboard-dev db (where I've done a ton of other test
migrations) if you want to see how it looks/works with a larger db. Just
let me know and I can kick it off.

As for a time to migrate, if you all are good with it, we usually schedule
for Friday's so there is even less activity. Its a small project config
change and then we just need an infra core to kick off the script once the
change merges.

-Kendall (diablo_rojo)

On Tue, Aug 14, 2018 at 9:33 AM Tobias Urdin  wrote:

> Hello all incredible Puppeters,
>
> I've tested setting up an Storyboard instance and test migrated
> puppet-ceph and it went without any issues there using the documentation
> [1] [2]
> with just one minor issue during the SB setup [3].
>
> My goal is that we will be able to swap to Storyboard during the Stein
> cycle but considering that we have a low activity on
> bugs my opinion is that we could do this swap very easily anything soon
> as long as everybody is in favor of it.
>
> Please let me know what you think about moving to Storyboard?
> If everybody is in favor of it we can request a migration to infra
> according to documentation [2].
>
> I will continue to test the import of all our project while people are
> collecting their thoughts and feedback :)
>
> Best regards
> Tobias
>
> [1] https://docs.openstack.org/infra/storyboard/install/development.html
> [2] https://docs.openstack.org/infra/storyboard/migration.html
> [3] It failed with an error about launchpadlib not being installed,
> solved with `tox -e venv pip install launchpadlib`
>
> __
> OpenStack Development Mailing 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] [releases][requirements][cycle-with-intermediary][cycle-trailing] requirements is going to branch stable/rocky at ~08-15-2018 2100Z

[Sean McGinnis]

On Tue, Aug 14, 2018 at 11:13:13AM -0500, Matthew Thode wrote:
> This is to warn and call out all those projects that do not have a
> stable/rocky branch yet.
> 
> If you are in the folloing list your project will need to realize that
> your master is testing against the requirements/constraints from stein,
> not rocky.  Any branching / tests you do will need to keep that in mind.
> 
> ansible-role-container-registry
> ansible-role-redhat-subscription
> ansible-role-tripleo-modify-image
> barbican-tempest-plugin
> blazar-tempest-plugin
> cinder-tempest-plugin

Point of clarification - *-tempest-plugin repos do not get branched. Releases
should be done to track the version for rocky, but stable branches are not
created.


__
OpenStack Development Mailing 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] [barbican][oslo][release] FFE request for castellan

[Sean McGinnis]

> On 08/10/2018 10:15 AM, Ade Lee wrote:
> > Hi all,
> > 
> > I'd like to request a feature freeze exception to get the following
> > change in for castellan.
> > 
> > https://review.openstack.org/#/c/575800/
> > 
> > This extends the functionality of the vault backend to provide
> > previously uninmplemented functionality, so it should not break anyone.
> > 
> > The castellan vault plugin is used behind barbican in the barbican-
> > vault plugin.  We'd like to get this change into Rocky so that we can
> > release Barbican with complete functionality on this backend (along
> > with a complete set of passing functional tests).
> 
> This does seem fairly low risk since it's just implementing a function that
> previously raised a NotImplemented exception.  However, with it being so
> late in the cycle I think we need the release team's input on whether this
> is possible.  Most of the release FFE's I've seen have been for critical
> bugs, not actual new features.  I've added that tag to this thread so
> hopefully they can weigh in.
> 

As far as releases go, this should be fine. If this doesn't affect any other
projects and would just be a late merging feature, as long as the castellan
team has considered the risk of adding code so late and is comfortable with
that, this is OK.

Castellan follows the cycle-with-intermediary release model, so the final Rocky
release just needs to be done by next Thursday. I do see the stable/rocky
branch has already been created for this repo, so it would need to merge to
master first (technically stein), then get cherry-picked to stable/rocky.


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

Re: [openstack-dev] [requirements][heat][congress] gabbi<1.42.1 causing error in queens dsvm

[Eric K]

From:  Rabi Mishra 
Date:  Monday, August 13, 2018 at 10:10 PM
> On Tue, Aug 14, 2018 at 4:40 AM, Eric K  wrote:
>> It appears that gabbi<1.42.1 is causing on error with heat tempest
>> plugin in congress stable/queens dsvm job [1][2][3].
> I wonder why you're enabling heat-tempest-plugin in the first place? I see a
> number of tempest plugins enabled. However, you don't seem to gate on the
> tests in those plugins[1].
> 
> [1] 
> https://github.com/openstack/congress/blob/master/playbooks/legacy/congress-de
> vstack-api-base/run.yaml#L61
Hi Rabi,

When folks worked on transitioning from in-tree tempest tests to a separate
plugin, it seemed as though enabling these plugins
was necessary to get some of the skip checks like this to succeed:
https://github.com/openstack/congress-tempest-plugin/blob/master/congress_te
mpest_plugin/tests/scenario/congress_datasources/test_aodh.py#L32

But maybe that's not the case and there's a better way. Would be great to
shed these extra tempest plugins actually.
> 
>  
>> The issue was
>> addressed in heat tempest plugin [4], but the problem remains for
>> stable/queens jobs because the queens upper-constraint is still at
>> 1.40.0 [5].
>> 
> 
> Yeah, a uc bump to 1.42.1 is required if you're enabling it.
>  
>> Any suggestions on how to proceed? Thank you!
>> 
>> [1] https://bugs.launchpad.net/heat-tempest-plugin/+bug/1749218
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1609361
>> [3] 
>> http://logs.openstack.org/41/567941/2/check/congress-devstack-api-mysql/c232d
>> 8a/job-output.txt.gz#_2018-08-13_11_46_28_441837
>> [4] https://review.openstack.org/#/c/544025/
>> [5] 
>> https://github.com/openstack/requirements/blob/stable/queens/upper-constraint
>> s.txt#L245
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> Regards,
> Rabi Mishra
> 
> __
> OpenStack Development Mailing List (not for usage questions) Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [requirements][heat][congress] gabbi<1.42.1 causing error in queens dsvm

[Eric K]

On 8/13/18, 11:03 PM, "Tony Breeds"  wrote:

>On Mon, Aug 13, 2018 at 04:10:30PM -0700, Eric K wrote:
>> It appears that gabbi<1.42.1 is causing on error with heat tempest
>> plugin in congress stable/queens dsvm job [1][2][3]. The issue was
>> addressed in heat tempest plugin [4], but the problem remains for
>> stable/queens jobs because the queens upper-constraint is still at
>> 1.40.0 [5].
>> 
>> Any suggestions on how to proceed? Thank you!
>
>https://review.openstack.org/591561 Should fix it.  You can create a
>no-op test that:
>
>Depends-On: https://review.openstack.org/591561
>
>to verify it works.  Doing so and reporting the change ID would be
>really helpful.
>
>Yours Tony.
Thank you, Tony!

Here's a no-op test:
https://review.openstack.org/#/c/591805/
>__
>OpenStack Development Mailing 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] [tripleo] ansible roles in tripleo

[Jill Rouleau]

Hey folks,

Like Alex mentioned[0] earlier, we've created a bunch of ansible roles
for tripleo specific bits.  The idea is to start putting some basic
cookiecutter type things in them to get things started, then move some
low-hanging fruit out of tripleo-heat-templates and into the appropriate
roles.  For example, docker/services/keystone.yaml could have
upgrade_tasks and fast_forward_upgrade_tasks moved into ansible-role-
tripleo-keystone/tasks/(upgrade.yml|fast_forward_upgrade.yml), and the
t-h-t updated to 
include_role: ansible-role-tripleo-keystone 
  tasks_from: upgrade.yml 
without having to modify any puppet or heat directives.

This would let us define some patterns for implementing these tripleo
roles during Stein while looking at how we can make use of ansible for
things like core config.

t-h-t and config-download will still drive the vast majority of playbook
creation for now, but for new playbooks (such as for operations tasks)
tripleo-ansible[1] would be our project directory.

So in addition to the larger conversation about how deployers can start
to standardize how we're all using ansible, I'd like to also have a
tripleo-specific conversation at PTG on how we can break out some of our
ansible that's currently embedded in t-h-t into more modular and
flexible roles.

Cheers,
Jill

[0] http://lists.openstack.org/pipermail/openstack-dev/2018-August/13311
9.html
[1] https://git.openstack.org/cgit/openstack/tripleo-ansible/tree/

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

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

[Ben Nemec]

Okay, thanks.  There's no Sigyn in openstack-oslo so I think we're good. :-)

On 08/14/2018 10:37 AM, Jay S Bryant wrote:

Ben,

Don't fully understand why it was kicking me.  I guess one of the 
behaviors that is considered suspicious is trying to message a bunch of 
nicks at once.  I had tried reducing the number of people in my ping but 
it still kicked me and so I decided to not risk it again.


Sounds like the moral of the story is if sigyn is in the channel, be 
careful.  :-)


Jay


On 8/13/2018 4:06 PM, Ben Nemec wrote:



On 08/08/2018 12:04 PM, Jay S Bryant wrote:

Team,

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


Do you have any idea why you're being kicked?  I'm wondering how to 
avoid getting into this situation with the Oslo pings.




__
OpenStack Development Mailing 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] [barbican][oslo][release] FFE request for castellan

[Ben Nemec]

On 08/10/2018 10:15 AM, Ade Lee wrote:

Hi all,

I'd like to request a feature freeze exception to get the following
change in for castellan.

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

This extends the functionality of the vault backend to provide
previously uninmplemented functionality, so it should not break anyone.

The castellan vault plugin is used behind barbican in the barbican-
vault plugin.  We'd like to get this change into Rocky so that we can
release Barbican with complete functionality on this backend (along
with a complete set of passing functional tests).


This does seem fairly low risk since it's just implementing a function 
that previously raised a NotImplemented exception.  However, with it 
being so late in the cycle I think we need the release team's input on 
whether this is possible.  Most of the release FFE's I've seen have been 
for critical bugs, not actual new features.  I've added that tag to this 
thread so hopefully they can weigh in.


__
OpenStack Development Mailing 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] [releases][requirements][cycle-with-intermediary][cycle-trailing] requirements is going to branch stable/rocky at ~08-15-2018 2100Z

[Alex Schultz]

On Tue, Aug 14, 2018 at 10:13 AM, Matthew Thode
 wrote:

.. snip ..

> ansible-role-container-registry
> ansible-role-redhat-subscription
> ansible-role-tripleo-modify-image
> instack-undercloud
> os-apply-config
> os-collect-config
> os-net-config
> os-refresh-config
> paunch
> python-tricircleclient
> tripleo-common-tempest-plugin
> tripleo-ipsec
> tripleo-ui
> tripleo-validations
> puppet-tripleo
> python-tripleoclient
> tripleo-common
> tripleo-heat-templates
> tripleo-image-elements
> tripleo-puppet-elements

From a tripleo aspect, we're aware and will likely branch the client
at the end of the week and others soonish but we're dependent on
packaging for the most part. We'll keep an eye on breakages due to any
requirement changes.  Thanks for the heads up

> puppet-aodh
> puppet-barbican
> puppet-ceilometer
> puppet-cinder
> puppet-cloudkitty
> puppet-congress
> puppet-designate
> puppet-ec2api
> puppet-freezer
> puppet-glance
> puppet-glare
> puppet-gnocchi
> puppet-heat
> puppet-horizon
> puppet-ironic
> puppet-keystone
> puppet-magnum
> puppet-manila
> puppet-mistral
> puppet-monasca
> puppet-murano
> puppet-neutron
> puppet-nova
> puppet-octavia
> puppet-openstack_extras
> puppet-openstacklib
> puppet-oslo
> puppet-ovn
> puppet-panko
> puppet-qdr
> puppet-rally
> puppet-sahara
> puppet-swift
> puppet-tacker
> puppet-tempest
> puppet-trove
> puppet-vitrage
> puppet-vswitch
> puppet-watcher
> puppet-zaqar

puppet-* are fine as we rely on packaging and requirements bits are
only for docs.

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

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

[openstack-dev] [puppet] migrating to storyboard

[Tobias Urdin]

Hello all incredible Puppeters,

I've tested setting up an Storyboard instance and test migrated 
puppet-ceph and it went without any issues there using the documentation 
[1] [2]

with just one minor issue during the SB setup [3].

My goal is that we will be able to swap to Storyboard during the Stein 
cycle but considering that we have a low activity on
bugs my opinion is that we could do this swap very easily anything soon 
as long as everybody is in favor of it.


Please let me know what you think about moving to Storyboard?
If everybody is in favor of it we can request a migration to infra 
according to documentation [2].


I will continue to test the import of all our project while people are 
collecting their thoughts and feedback :)


Best regards
Tobias

[1] https://docs.openstack.org/infra/storyboard/install/development.html
[2] https://docs.openstack.org/infra/storyboard/migration.html
[3] It failed with an error about launchpadlib not being installed, 
solved with `tox -e venv pip install launchpadlib`


__
OpenStack Development Mailing 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] How to debug no valid host failures with placement

[Eric Fried]

Folks-

The patch mentioned below [1] has undergone several rounds of review
and collaborative revision, and we'd really like to get your feedback on
it. From the commit message:

Here are some examples of the debug output:

- A request for three resources with no aggregate or trait filters:

 found 7 providers with available 5 VCPU
 found 9 providers with available 1024 MEMORY_MB
   5 after filtering by previous result
 found 8 providers with available 1500 DISK_GB
   2 after filtering by previous result

- The same request, but with a required trait that nobody has, shorts
  out quickly:

 found 0 providers after applying required traits filter
({'HW_CPU_X86_AVX2': 65})

- A request for one resource with aggregates and forbidden (but no
  required) traits:

 found 2 providers after applying aggregates filter
([['3ed8fb2f-4793-46ee-a55b-fdf42cb392ca']])
 found 1 providers after applying forbidden traits filter
({u'CUSTOM_TWO': 201, u'CUSTOM_THREE': 202})
 found 3 providers with available 4 VCPU
   1 after applying initial aggregate and trait filters

Thanks,
efried

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


> I've created a patch that (hopefully) will address some of the
> difficulty that folks have had in diagnosing which parts of a request
> caused all providers to be filtered out from the return of GET
> /allocation_candidates:
> 
> https://review.openstack.org/#/c/590041
> 
> This patch changes two primary things:
> 
> 1) Query-splitting
> 
> The patch splits the existing monster SQL query that was being used for
> querying for all providers that matched all requested resources,
> required traits, forbidden traits and required aggregate associations
> into doing multiple queries, one for each requested resource. While this
> does increase the number of database queries executed for each call to
> GET /allocation_candidates, the changes allow better visibility into
> what parts of the request cause an exhaustion of matching providers.
> We've benchmarked the new patch and have shown the performance impact of
> doing 3 queries versus 1 (when there is a request for 3 resources --
> VCPU, RAM and disk) is minimal (a few extra milliseconds for execution
> against a DB with 1K providers having inventory of all three resource
> classes).
> 
> 2) Diagnostic logging output
> 
> The patch adds debug log output within each loop iteration, so there is
> no logging output that shows how many matching providers were found for
> each resource class involved in the request. The output looks like this
> in the logs:
> 
> [req-2d30faa8-4190-4490-a91e-610045530140] inside VCPU request loop.
> before applying trait and aggregate filters, found 12 matching providers
> [req-2d30faa8-4190-4490-a91e-610045530140] found 12 providers with
> capacity for the requested 1 VCPU.
> [req-2d30faa8-4190-4490-a91e-610045530140] inside MEMORY_MB request
> loop. before applying trait and aggregate filters, found 9 matching
> providers [req-2d30faa8-4190-4490-a91e-610045530140] found 9 providers
> with capacity for the requested 64 MEMORY_MB. before loop iteration we
> had 12 matches. [req-2d30faa8-4190-4490-a91e-610045530140]
> RequestGroup(use_same_provider=False, resources={MEMORY_MB:64, VCPU:1},
> traits=[], aggregates=[]) (suffix '') returned 9 matches
> 
> If a request includes required traits, forbidden traits or required
> aggregate associations, there are additional log messages showing how
> many matching providers were found after applying the trait or aggregate
> filtering set operation (in other words, the log output shows the impact
> of the trait filter or aggregate filter in much the same way that the
> existing FilterScheduler logging shows the "before and after" impact
> that a particular filter had on a request process.
> 
> Have a look at the patch in question and please feel free to add your
> feedback and comments on ways this can be improved to meet your needs.
> 
> Best,
> -jay
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing 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-ansible][ptg] PTG etherpad planning.

[jean-philippe]

Dear community,

We are approaching the PTG in Denver, and I want to remind everybody to make 
sure you are ready for it!

I've created the etherpad [1] where you can add any topic you want to discuss, 
if you haven't done so already.

If you are not able to attend the PTG, please mention it on the etherpad, and 
we'll run the session remotely if we can.

Note: There will be the now traditional team photos and dinner too :)

Regards,
Jean-Philippe Evrard (evrardjp)

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


__
OpenStack Development Mailing 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] [releases][requirements][cycle-with-intermediary][cycle-trailing] requirements is going to branch stable/rocky at ~08-15-2018 2100Z

[Matthew Thode]

This is to warn and call out all those projects that do not have a
stable/rocky branch yet.

If you are in the folloing list your project will need to realize that
your master is testing against the requirements/constraints from stein,
not rocky.  Any branching / tests you do will need to keep that in mind.

ansible-role-container-registry
ansible-role-redhat-subscription
ansible-role-tripleo-modify-image
barbican-tempest-plugin
blazar-tempest-plugin
cinder-tempest-plugin
cloudkitty-dashboard
cloudkitty-tempest-plugin
cloudkitty
congress-tempest-plugin
designate-tempest-plugin
ec2api-tempest-plugin
heat-agents
heat-dashboard
heat-tempest-plugin
instack-undercloud
ironic-tempest-plugin
karbor-dashboard
karbor
keystone-tempest-plugin
kuryr-kubernetes
kuryr-libnetwork
kuryr-tempest-plugin
magnum-tempest-plugin
magnum-ui
manila-tempest-plugin
mistral-tempest-plugin
monasca-kibana-plugin
monasca-tempest-plugin
murano-tempest-plugin
networking-generic-switch-tempest-plugin
networking-hyperv
neutron-tempest-plugin
octavia-tempest-plugin
os-apply-config
os-collect-config
os-net-config
os-refresh-config
oswin-tempest-plugin
paunch
python-tricircleclient
sahara-tests
senlin-tempest-plugin
solum-tempest-plugin
swift
tacker-horizon
tacker
telemetry-tempest-plugin
tempest-tripleo-ui
tempest
tripleo-common-tempest-plugin
tripleo-ipsec
tripleo-ui
tripleo-validations
trove-tempest-plugin
vitrage-tempest-plugin
watcher-tempest-plugin
zaqar-tempest-plugin
zun-tempest-plugin
zun-ui
zun

kolla-ansible
kolla
puppet-aodh
puppet-barbican
puppet-ceilometer
puppet-cinder
puppet-cloudkitty
puppet-congress
puppet-designate
puppet-ec2api
puppet-freezer
puppet-glance
puppet-glare
puppet-gnocchi
puppet-heat
puppet-horizon
puppet-ironic
puppet-keystone
puppet-magnum
puppet-manila
puppet-mistral
puppet-monasca
puppet-murano
puppet-neutron
puppet-nova
puppet-octavia
puppet-openstack_extras
puppet-openstacklib
puppet-oslo
puppet-ovn
puppet-panko
puppet-qdr
puppet-rally
puppet-sahara
puppet-swift
puppet-tacker
puppet-tempest
puppet-tripleo
puppet-trove
puppet-vitrage
puppet-vswitch
puppet-watcher
puppet-zaqar
python-tripleoclient
tripleo-common
tripleo-heat-templates
tripleo-image-elements
tripleo-puppet-elements

So please branch :D

-- 
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] [cinder] Reminder about the weekly Cinder meeting ...

[Amy Marrich]

That bot is indeed missing from the channel

Amy (spotz)

On Mon, Aug 13, 2018 at 5:44 PM, Jeremy Stanley  wrote:

> On 2018-08-13 16:29:27 -0500 (-0500), Amy Marrich wrote:
> > I know we did a ping last week in #openstack-ansible for our meeting no
> > issue. I wonder if it's a length of names thing or a channel setting.
> [...]
>
> Freenode's Sigyn bot may not have been invited to
> #openstack-ansible. We might want to consider kicking it from
> channels while they have nick registration enforced.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jay S Bryant]

On 8/13/2018 5:44 PM, Jeremy Stanley wrote:

On 2018-08-13 16:29:27 -0500 (-0500), Amy Marrich wrote:

I know we did a ping last week in #openstack-ansible for our meeting no
issue. I wonder if it's a length of names thing or a channel setting.

[...]

Freenode's Sigyn bot may not have been invited to
#openstack-ansible. We might want to consider kicking it from
channels while they have nick registration enforced.

It does seem that we don't really need the monitoring if registration is 
enforced.  I would be up for doing this.



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


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

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

[Jay S Bryant]

Ben,

Don't fully understand why it was kicking me.  I guess one of the 
behaviors that is considered suspicious is trying to message a bunch of 
nicks at once.  I had tried reducing the number of people in my ping but 
it still kicked me and so I decided to not risk it again.


Sounds like the moral of the story is if sigyn is in the channel, be 
careful.  :-)


Jay


On 8/13/2018 4:06 PM, Ben Nemec wrote:



On 08/08/2018 12:04 PM, Jay S Bryant wrote:

Team,

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


Do you have any idea why you're being kicked?  I'm wondering how to 
avoid getting into this situation with the Oslo pings.



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

Re: [openstack-dev] [requirements][release][osc] FFE osc-lib 1.11.1 release

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2018-08-14 15:28:07 +1000:
> On Tue, Aug 14, 2018 at 12:11:53AM -0500, Matthew Thode wrote:
> 
> > Maybe it'd be better to figure out what's using that removed method and
> > those would need the update?
> 
> Given we have per-project deps in rocky only those that *need* the
> exclusion will need to apply it.

Right. Now that we no longer sync dependencies, releases no longer
automatically trigger updates in the consuming projects. We could
exclude the bad version in the global list, but I don't think we
need to make that a prerequisite for anything else.

> I think it's fair to accept the U-c bump and block 0.11.0 in
> global-requirements.  Then any project that find they're broken next
> week can just add the exclusion themselves and move on.

Exactly. Our main concern should be about the potential breadth of
impact to our own CI systems, which we can mitigate with the constraints
list. In this case we know we have a version of something we manage
that broke several other things we manage. We should be able to go
ahead with the release and keep an eye on things in case we introduce
any new breakages.

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] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2018-08-13 16:17:30 -0500:
> On 18-08-13 20:28:23, Andreas Jaeger wrote:
> > On 2018-08-13 19:16, Andreas Jaeger wrote:
> > > On 2018-08-13 18:40, Petr Kovar wrote:
> > > > Hi all,
> > > > 
> > > > This is a request for an FFE to release openstackdocstheme 1.21.2.
> > > 
> > > 
> > > > This mostly fixes usability issues in rendering docs content, so we 
> > > > would
> > > > like to update the theme across all project team docs on docs.o.o.
> > > 
> > > I suggest to release quickly a 1.21.3 with
> > > https://review.openstack.org/#/c/585517/ - and use that one instead.
> > 
> > Release request:
> > https://review.openstack.org/591485
> > 
> 
> Would this be a upper-constraint only bump?
> 
> If so reqs acks it

We need, eventually, to retrigger documentation builds in all of the
open branches using this new version of the theme so we can inject the
status info into those old pages. We will have an opportunity to trigger
those builds when we move the zuul configuration into each repo as part
of the python3 goal this cycle.

So, for now we need to update the constraints list on master. But we
also need to work quickly to update the constraints lists in the open
branches so that is done before we approve the goal-related changes in
those branches.

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]Notification subteam meeting cancelled

[Balázs Gibizer]

Hi,

There won't be notification subteam meeting this week.

Cheers,
gibi


__
OpenStack Development Mailing 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] [releases][rocky][tempest-plugins][ptl] Reminder to tag the Tempest plugins for Rocky release

[Sean McGinnis]

On Sun, Aug 12, 2018 at 05:41:20PM +0900, Ghanshyam Mann wrote:
> Hi All,
> 
> Rocky release is few weeks away and we all agreed to release Tempest plugin 
> with cycle-with-intermediary. Detail discussion are in ML [1] in case you 
> missed.
> 
> This is reminder to tag your project tempest plugins for Rocky release. You 
> should be able to find your plugins deliverable file under rocky folder in 
> releases repo[3].  You can refer cinder-tempest-plugin release as example. 
> 
> Feel free to reach to release/QA team for any help/query. 
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131810.html  
> [2] https://review.openstack.org/#/c/590025/   
> [3] https://github.com/openstack/releases/tree/master/deliverables/rocky
> 
> -gmann
> 

It should also be noted that these repos will need to be set up with a release
job if they do not already have one. They will need either publish-to-pypi or
publish-to-pypi-python3, similar to what was done here:

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

And before that is done, please make sure the package is registered and set up
correctly on pypi following these insructions:

https://docs.openstack.org/infra/manual/creators.html#pypi

Requests to create a tempest plugin release will fail validation if this has
not be set up ahead of time.

Thanks,
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] [tripleo][Edge][FEMDC] Edge clouds and controlplane updates

[Bogdan Dobrelya]

On 8/13/18 9:47 PM, Giulio Fidente wrote:

Hello,

I'd like to get some feedback regarding the remaining
work for the split controlplane spec implementation [1]

Specifically, while for some services like nova-compute it is not
necessary to update the controlplane nodes after an edge cloud is
deployed, for other services, like cinder (or glance, probably
others), it is necessary to do an update of the config files on the
controlplane when a new edge cloud is deployed.

In fact for services like cinder or glance, which are hosted in the
controlplane, we need to pull data from the edge clouds (for example
the newly deployed ceph cluster keyrings and fsid) to configure cinder
(or glance) with a new backend.

It looks like this demands for some architectural changes to solve the > 
following two:

- how do we trigger/drive updates of the controlplane nodes after the
edge cloud is deployed?


Note, there is also a strict(?) requirement of local management 
capabilities for edge clouds temporary disconnected off the central 
controlplane. That complicates the updates triggering even more. We'll 
need at least a notification-and-triggering system to perform required 
state synchronizations, including conflicts resolving. If that's the 
case, the architecture changes for TripleO deployment framework are 
inevitable AFAICT.




- how do we scale the controlplane parameters to accomodate for N
backends of the same type?

A very rough approach to the latter could be to use jinja to scale up
the CephClient service so that we can have multiple copies of it in the
controlplane.

Each instance of CephClient should provide the ceph config file and
keyring necessary for each cinder (or glance) backend.

Also note that Ceph is only a particular example but we'd need a similar
workflow for any backend type.

The etherpad for the PTG session [2] touches this, but it'd be good to
start this conversation before then.

1.
https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html

2. https://etherpad.openstack.org/p/tripleo-ptg-queens-split-controlplane




--
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] [ironic] ironic-staging-drivers: what to do?

[Jim Rollenhagen]

On Mon, Aug 13, 2018 at 2:40 PM, Julia Kreger 
wrote:

> Greetings fellow ironicans!
>
> As many of you might know an openstack/ironic-staging-drivers[1]
> repository exists. What most might not know is that it was
> intentionally created outside of ironic's governance[2].
>
> At the time it was created ironic was moving towards removing drivers
> that did not meet our third-party CI requirement[3] to be in-tree. The
> repository was an attempt to give a home to what some might find
> useful or where third party CI is impractical or cost-prohibitive and
> thus could not be officially part of Ironic the service. There was
> hope that drivers could land in ironic-staging-drivers and possibly
> graduate to being moved in-tree with third-party CI. As our community
> has evolved we've not stopped and revisited the questions.
>

Which questions?

With our most recent release over, I believe we need to ask ourselves
> if we should consider moving ironic-staging-drivers into our
> governance.
>
> Over the last couple of releases several contributors have found
> themselves trying to seek out two available reviewers to merge even
> trivial fixes[4]. Due to the team being so small this was no easy
> task. As a result, I'm wondering why not move the repository into
> governance, grant ironic-core review privileges upon the repository,
> and maintain the purpose and meaning of the repository. This would
> also result in the repository's release becoming managed via the
> release management process which is a plus.
>

Agree with Dmitry, just because ironic-core has +2 doesn't mean they will
look at it. I'm not opposed to adding more of the ironic-core folks to it
outside of governance, though. While I probably wouldn't review
ironic-staging-drivers often whether it is in our governance or not, I'd be
happy to review trivial changes to help move things along.

We could then propose an actual graduation process and help alleviate
> some of the issues where driver code is iterated upon for long periods
> of time before landing. At the same time I can see at least one issue
> which is if we were to do that, then we would also need to manage
> removal through the same path.
>

Is there any reason we can't have the same graduation process without
bringing it into ironic's governance?

I know there are concerns over responsibility in terms of code
> ownership and quality, but I feel like we already hit such issues[5],
> like those encountered when Dmitry removed classic drivers[6] from the
> repository and also encountered issues just prior to the latest
> release[7][8].
>

Yes, this is my primary concern. I don't believe that the ironic team
should be responsible for this code, when we can't validate it (manually or
via CI).

Any code is going to have quality issues from time to time. The difference
is who is responsible for taking care of those.

[5] and [6] are examples of where we knew we were going to break
out-of-tree drivers, and helped fix them because we're kind people - not
where we were taking ownership of the code. I suspect if we were aware of
other out-of-tree drivers we would have been happy to fix those as well.
[7] and [8] are just general code maintenance, and aren't really an
argument to me for having the ironic team take over this project.

Besides, as Dmitry notes, he "has to" care about ironic-staging-drivers
anyway, and 3 out of those 4 commits are his. :)

Overall I'm -1, but will live by whatever decision we come to.

// jim

This topic has come up in passing at PTGs and most recently on IRC[9],
> and I think we ought to discuss it during our next weekly meeting[10].
> I've gone ahead and added an item to the agenda, but we can also
> discuss via email.


> -Julia
>
> [1]: http://git.openstack.org/cgit/openstack-infra/project-
> config/tree/gerrit/projects.yaml#n4571
> [2]: http://git.openstack.org/cgit/openstack/ironic-staging-
> drivers/tree/README.rst#n16
> [3]: https://specs.openstack.org/openstack/ironic-specs/specs/
> approved/third-party-ci.html
> [4]: https://review.openstack.org/#/c/548943/
> [5]: https://review.openstack.org/#/c/541916/
> [6]: https://review.openstack.org/567902
> [7]: https://review.openstack.org/590352
> [8]: https://review.openstack.org/590401
> [9]: http://eavesdrop.openstack.org/irclogs/%23openstack-
> ironic/%23openstack-ironic.2018-08-09.log.html#t2018-08-09T11:55:27
> [10]: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_
> for_next_meeting
>
> __
> OpenStack Development Mailing 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

[openstack-dev] [tc] [all] TC Report 18-33

[Chris Dent]

HTML: https://anticdent.org/tc-report-18-33.html

## Dead, Gone or Stable

[Last week](https://anticdent.org/tc-report-18-32.html) saw plenty
of discussion about how to deal with projects for which no PTL was
found by election or acclaim. That discussion continued this week,
but also stimulated discussion on the differences between a project
being dead, gone from OpenStack, or stable.

* [Needing a point 
person](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-07.log.html#t2018-08-07T13:05:48)
* [Risks (or lack) of being 
leaderless](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-13.log.html#t2018-08-13T08:09:23)

Mixed in with that are some dribbles of a theme which has become
increasingly common of late:

* [Contribution from foundation member 
corps](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-09.log.html#t2018-08-09T12:49:27)
* [The need for janitors, and board members not being the people able to 
provide](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-09.log.html#t2018-08-09T13:30:12)

As a group, the TC has very mixed feelings on these issues. On the
one hand everyone would like to keep projects healthy and within
OpenStack, where possible. On the other hand, it is important that
people who are upstream contributors stop over-committing to
compensate for lack of commitment from a downstream that benefits
hugely from their labor. Letting projects "die" or become unofficial
is one way to clearly signal that there are resourcing problems.

In fact, doing so with both
[Searchlight](https://review.openstack.org/#/c/588644/) and
[Freezer](https://review.openstack.org/#/c/588645/) raised some
volunteers to help out as PTLs. However, both of those projects have
been languishing for many months. How many second chances do
projects get?

## IRC for PTLs

Within all the discussion about the health of projects, there was
some
[discussion](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-08.log.html#t2018-08-08T17:25:20)
of whether it was appropriate to expect PTLs to have and use IRC
nicks. As the character of the pool of potential PTLs evolves, it
might not fit. See the log for a bit more nuance on the issues.

## TC Elections Soon

Six seats on the TC will be up for election. The nomination period
will start at the end of this month. If you're considering running
and have any questions, please feel free to ask me.

--
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] [ironic] ironic-staging-drivers: what to do?

[Dmitry Tantsur]

Inline

On 08/13/2018 08:40 PM, Julia Kreger wrote:

Greetings fellow ironicans!

As many of you might know an openstack/ironic-staging-drivers[1]
repository exists. What most might not know is that it was
intentionally created outside of ironic's governance[2].

At the time it was created ironic was moving towards removing drivers
that did not meet our third-party CI requirement[3] to be in-tree. The
repository was an attempt to give a home to what some might find
useful or where third party CI is impractical or cost-prohibitive and
thus could not be officially part of Ironic the service. There was
hope that drivers could land in ironic-staging-drivers and possibly
graduate to being moved in-tree with third-party CI. As our community
has evolved we've not stopped and revisited the questions.

With our most recent release over, I believe we need to ask ourselves
if we should consider moving ironic-staging-drivers into our
governance.


Not voting on this, since I'm obviously biased. Consider me +0 :)



Over the last couple of releases several contributors have found
themselves trying to seek out two available reviewers to merge even
trivial fixes[4]. Due to the team being so small this was no easy
task. As a result, I'm wondering why not move the repository into
governance, grant ironic-core review privileges upon the repository,
and maintain the purpose and meaning of the repository. This would
also result in the repository's release becoming managed via the
release management process which is a plus.


Strictly speaking, nothing prevents us from granting ironic-core +2 on it right 
now. It's a different question whether they'll actually review it. We need a 
commitment from >50% cores to review it more or less regularly, otherwise we'll 
end up in the same situation.




We could then propose an actual graduation process and help alleviate
some of the issues where driver code is iterated upon for long periods
of time before landing. At the same time I can see at least one issue
which is if we were to do that, then we would also need to manage
removal through the same path.


I don't think we really "need to", but we certainly can. Now that I think that 
we could use ironic-staging-drivers as an *actual* staging area for new drivers, 
I'm starting to lean towards +1 on this whole idea.


This still leaves some drivers that will never get a CI.



I know there are concerns over responsibility in terms of code
ownership and quality, but I feel like we already hit such issues[5],
like those encountered when Dmitry removed classic drivers[6] from the
repository and also encountered issues just prior to the latest
release[7][8].


Well, yes, I personally have to care about this repository anyway.

Dmitry



This topic has come up in passing at PTGs and most recently on IRC[9],
and I think we ought to discuss it during our next weekly meeting[10].
I've gone ahead and added an item to the agenda, but we can also
discuss via email.

-Julia

[1]: 
http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml#n4571
[2]: 
http://git.openstack.org/cgit/openstack/ironic-staging-drivers/tree/README.rst#n16
[3]: 
https://specs.openstack.org/openstack/ironic-specs/specs/approved/third-party-ci.html
[4]: https://review.openstack.org/#/c/548943/
[5]: https://review.openstack.org/#/c/541916/
[6]: https://review.openstack.org/567902
[7]: https://review.openstack.org/590352
[8]: https://review.openstack.org/590401
[9]: 
http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2018-08-09.log.html#t2018-08-09T11:55:27
[10]: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting

__
OpenStack Development Mailing 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] Berlin Summit Schedule Live!

[Ashlee Ferguson]

The schedule for the Berlin Summit 
 is live! 

Check out 100+ sessions, demos, and workshops covering 35+ open source projects 
in the following Tracks:

• CI/CD
• Container Infrastructure
• Edge Computing
• HPC / GPU / AI
• Private & Hybrid Cloud
• Public Cloud
• Telecom & NFV

Log in with your OpenStackID  and start building your 
schedule now!

Register for the Summit  - 
Get your Summit ticket for USD $699 before the price increases on August 21 at 
11:59pm PT (August 22 at 6:59 UTC)

For speakers with accepted sessions, look for an email from 
speakersupp...@openstack.org  for next 
steps on registration.

Thank you to our Programming Committee! They have once again taken time out of 
their busy schedules to help create another round of outstanding content for 
the OpenStack Summit. The OpenStack Foundation relies on the 
community-nominated Programming Committee, along with your Community Votes to 
select the content of the summit.  If you're curious about this process, you 
can read more about it here 

 where we have also listed the Programming Committee members.  

Interested in sponsoring the Berlin Summit? Learn more here 


Cheers,
Ashlee


Ashlee Ferguson
OpenStack Foundation
ash...@openstack.org




__
OpenStack Development Mailing 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] [rpm-packaging] Step down as a reviewer

[Javier Pena]

- Original Message -
> Dear rpm-packaging team,
> 
> I was lucky to help doing reviews for the rpm-packaging OpenStack
> project for the last couple of release cycles. I learned a lot during
> this time.
> 
> I will change my role at SUSE at the end of the month (August 2018), so
> I request to be removed from the core position on those projects.
> 
> Also, a big thank to the team for the provided help during this time.
> 

Alberto, thank you very much for your contributions. I wish you the best in 
your new position.

Regards,
Javier

> Saludos!
> 
> --
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
> Maxfeldstraße 5, 90409 Nürnberg, Germany
> 
> 
> __
> OpenStack Development Mailing 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] [edge][glance][nova][starlngx]: Edge sessions on the PTG

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

Hi,

We will have a whole day discussion on edge on the Tuesday of the PTG [1] where 
we plan [2] to have discussions on image handling, Nova, Keystone and StarlingX.
If you are interested in any of these please add your name to the name lists. 
Also if you have some ideas to discuss during the day please add it to the list.

Thanks,
Gerg0

[1]: https://www.openstack.org/ptg#tab_schedule
[2]: https://etherpad.openstack.org/p/EdgeComputingGroupPTG4
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][heat][congress] gabbi<1.42.1 causing error in queens dsvm

[Tony Breeds]

On Mon, Aug 13, 2018 at 04:10:30PM -0700, Eric K wrote:
> It appears that gabbi<1.42.1 is causing on error with heat tempest
> plugin in congress stable/queens dsvm job [1][2][3]. The issue was
> addressed in heat tempest plugin [4], but the problem remains for
> stable/queens jobs because the queens upper-constraint is still at
> 1.40.0 [5].
> 
> Any suggestions on how to proceed? Thank you!

https://review.openstack.org/591561 Should fix it.  You can create a
no-op test that:

Depends-On: https://review.openstack.org/591561 

to verify it works.  Doing so and reporting the change ID would be
really helpful.

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