Re: [openstack-dev] [goal][python3] more updates to the goal tools

[Doug Hellmann]

https://review.openstack.org/#/c/593289/ should fix the similar
problem you found with CommentedSeq.

Doug

Excerpts from super user's message of 2018-08-18 11:15:20 +0900:
> The problem was fixed.
> 
> Nguyen Hai
> 
> On Fri, Aug 17, 2018 at 11:47 PM Doug Hellmann 
> wrote:
> 
> > I was not able to reproduce the problem. Please test the fix in
> > https://review.openstack.org/#/c/593068/ to see if that helps.
> >
> > Which version of Python are you using to run the tools? And on which OS?
> >
> > Excerpts from Doug Hellmann's message of 2018-08-17 10:30:29 -0400:
> > > I will work on fixing this today.
> > >
> > > Has the designate team agreed to go ahead with their migration, or
> > > are you still testing the scripts?
> > >
> > > Doug
> > >
> > > Excerpts from super user's message of 2018-08-17 15:37:03 +0900:
> > > > Hi Doug,
> > > >
> > > > I'm Nguyen Hai. I proposed the python3-first patch set for
> > > > designate projects. However, I have met this error to designate and
> > > > designate-dashboard:
> > > >
> > > > === ../Output/designate/openstack/designate @ master ===
> > > >
> > > > ./tools/python3-first/do_repo.sh
> > ../Output/designate/openstack/designate
> > > > master 24292
> > > >
> > > > ++ cat ../Output/designate/openstack/designate/.gitreview
> > > > ++ grep project
> > > > ++ cut -f2 -d=
> > > > + actual=openstack/designate.git
> > > > +++ dirname ../Output/designate/openstack/designate
> > > > ++ basename ../Output/designate/openstack
> > > > ++ basename ../Output/designate/openstack/designate
> > > > + expected=openstack/designate
> > > > + '[' openstack/designate.git '!=' openstack/designate -a
> > > > openstack/designate.git '!=' openstack/designate.git ']'
> > > > + git -C ../Output/designate/openstack/designate review -s
> > > > Creating a git remote called 'gerrit' that maps to:
> > > > ssh://
> > > > nguyentri...@review.openstack.org:29418/openstack/designate.git
> > > > ++ basename master
> > > > + new_branch=python3-first-master
> > > > + git -C ../Output/designate/openstack/designate branch
> > > > + grep -q python3-first-master
> > > > + echo 'creating python3-first-master'
> > > > creating python3-first-master
> > > > + git -C ../Output/designate/openstack/designate checkout -- .
> > > > + git -C ../Output/designate/openstack/designate clean -f -d
> > > > + git -C ../Output/designate/openstack/designate checkout -q
> > origin/master
> > > > + git -C ../Output/designate/openstack/designate checkout -b
> > > > python3-first-master
> > > > Switched to a new branch 'python3-first-master'
> > > > + python3-first -v --debug jobs update
> > > > ../Output/designate/openstack/designate
> > > > determining repository name from .gitreview
> > > > working on openstack/designate @ master
> > > > looking for zuul config in
> > > > ../Output/designate/openstack/designate/.zuul.yaml
> > > > using zuul config from
> > ../Output/designate/openstack/designate/.zuul.yaml
> > > > loading project settings from ../project-config/zuul.d/projects.yaml
> > > > loading project templates from
> > > > ../openstack-zuul-jobs/zuul.d/project-templates.yaml
> > > > loading jobs from ../openstack-zuul-jobs/zuul.d/jobs.yaml
> > > > looking for settings for openstack/designate
> > > > looking at template 'openstack-python-jobs'
> > > > looking at template 'openstack-python35-jobs'
> > > > looking at template 'publish-openstack-sphinx-docs'
> > > > looking at template 'periodic-stable-jobs'
> > > > looking at template 'check-requirements'
> > > > did not find template definition for 'check-requirements'
> > > > looking at template 'translation-jobs-master-stable'
> > > > looking at template 'release-notes-jobs'
> > > > looking at template 'api-ref-jobs'
> > > > looking at template 'install-guide-jobs'
> > > > looking at template 'release-openstack-server'
> > > > filtering on master
> > > > merging templates
> > > >   adding openstack-python-jobs
> > > >   adding openstack-python35-jobs
> > > >   adding publish-openstack-sphinx-docs
> > > >   adding periodic-stable-jobs

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

[Doug Hellmann]

Excerpts from Dan Smith's message of 2018-08-17 10:30:41 -0700:
> > The subject of using placement in Cinder has come up, and since then I've 
> > had a
> > few conversations with people in and outside of that team. I really think 
> > until
> > placement is its own project outside of the nova team, there will be 
> > resistance
> > from some to adopt it.
> 
> I know politics will be involved in this, but this is a really terrible
> reason to do a thing, IMHO. After the most recent meeting we had with
> the Cinder people on placement adoption, I'm about as convinced as ever
> that Cinder won't (and won't need to) _consume_ placement any time
> soon. I hope it will _report_ to placement so Nova can make better
> decisions, just like Neutron does now, but I think that's the extent
> we're likely to see if we're honest.
> 
> What other projects are _likely_ to _consume_ placement even if they
> don't know they'd want to? What projects already want to use it but
> refuse to because it has Nova smeared all over it? We talked about this
> a lot in the early justification for placement, but the demand for that
> hasn't really materialized, IMHO; maybe it's just me.
> 
> > This reluctance on having it part of Nova may be real or just perceived, but
> > with it within Nova it will likely be an uphill battle for some time 
> > convincing
> > other projects that it is a nicely separated common service that they can 
> > use.
> 
> Splitting it out to another repository within the compute umbrella (what
> do we call it these days?) satisfies the _technical_ concern of not
> being able to use placement without installing the rest of the nova code
> and dependency tree. Artificially creating more "perceived" distance
> sounds really political to me, so let's be sure we're upfront about the
> reasoning for doing that if so :)
> 
> --Dan
> 

If we ignore the political concerns in the short term, are there
other projects actually interested in using placement? With what
technical caveats? Perhaps with modifications of some sort to support
the needs of those projects?

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] [goal][python3] more updates to the goal tools

[Doug Hellmann]

oal-tools/goal_tools/python3_first/jobs.py",
> > line 362, in merge_pipeline*
> > *if job_name in job_names:*
> > *TypeError: unhashable type: 'CommentedMap'*
> > *Traceback (most recent call last):*
> > *  File "/home/stack/python3-first/goal-tools/.tox/venv/bin/python3-first",
> > line 10, in *
> > *sys.exit(main())*
> > *  File
> > "/home/stack/python3-first/goal-tools/goal_tools/python3_first/main.py",
> > line 42, in main*
> > *return Python3First().run(argv)*
> > *  File
> > "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/app.py",
> > line 281, in run*
> > *result = self.run_subcommand(remainder)*
> > *  File
> > "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/app.py",
> > line 402, in run_subcommand*
> > *result = cmd.run(parsed_args)*
> > *  File
> > "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/command.py",
> > line 184, in run*
> > *return_code = self.take_action(parsed_args) or 0*
> > *  File
> > "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> > line 531, in take_action*
> > *entry,*
> > *  File
> > "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> > line 397, in merge_project_settings*
> > *up.get(pipeline, comments.CommentedMap()),*
> > *  File
> > "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> > line 362, in merge_pipeline*
> > *if job_name in job_names:*
> > *TypeError: unhashable type: 'CommentedMap'*
> > *+ echo 'No changes'*
> > *No changes*
> > *+ exit 1*
> > 
> > On Wed, Aug 8, 2018 at 7:58 AM Doug Hellmann  wrote:
> > 
> > > Champions,
> > >
> > > I have made quite a few changes to the tools for generating the zuul
> > > migration patches today. If you have any patches you generated locally
> > > for testing, please check out the latest version of the tool (when all
> > > of the changes merge) and regenerate them.
> > >
> > > 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] [neutron] Broken pep8 job

[Doug Hellmann]

Excerpts from Slawomir Kaplonski's message of 2018-08-17 10:16:35 +0200:
> Hi,
> 
> It looks that pep8 job in Neutron is currently broken because of new version 
> of bandit (1.5.0).
> If You have in Your patch failure of pep8 job with error like [1] please 
> don’t recheck as it will not help.
> I did some patch which should fix it [2]. Will let You know when it will be 
> fixed and You will be able to rebase You patches.
> 
> [1] 
> http://logs.openstack.org/37/382037/67/check/openstack-tox-pep8/e2bbd84/job-output.txt.gz#_2018-08-16_21_45_55_366148
> [2] https://review.openstack.org/#/c/592884/
> 
> — 
> Slawek Kaplonski
> Senior software engineer
> Red Hat
> 

We had this problem in oslo.concurrency, too.

Because bandit is considered to be a linter and different teams may
want to use different versions, it is not managed through the
constraints list (there is no co-installability requirement for
linters). Some of the projects using it do not have it capped, so
new releases that introduce breaking changes like this can cause
gate issues.

In the oslo.concurrency stable branch we capped the version of
bandit to avoid having to backport changes just to fix the linter
errors. We made code changes in master to address them and left
bandit uncapped there, for now.

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] [goal][python3] more updates to the goal tools

[Doug Hellmann]

al-tools/.tox/venv/lib/python3.6/site-packages/cliff/app.py",
> line 402, in run_subcommand*
> *result = cmd.run(parsed_args)*
> *  File
> "/home/stack/python3-first/goal-tools/.tox/venv/lib/python3.6/site-packages/cliff/command.py",
> line 184, in run*
> *return_code = self.take_action(parsed_args) or 0*
> *  File
> "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> line 531, in take_action*
> *entry,*
> *  File
> "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> line 397, in merge_project_settings*
> *up.get(pipeline, comments.CommentedMap()),*
> *  File
> "/home/stack/python3-first/goal-tools/goal_tools/python3_first/jobs.py",
> line 362, in merge_pipeline*
> *if job_name in job_names:*
> *TypeError: unhashable type: 'CommentedMap'*
> *+ echo 'No changes'*
> *No changes*
> *+ exit 1*
> 
> On Wed, Aug 8, 2018 at 7:58 AM Doug Hellmann  wrote:
> 
> > Champions,
> >
> > I have made quite a few changes to the tools for generating the zuul
> > migration patches today. If you have any patches you generated locally
> > for testing, please check out the latest version of the tool (when all
> > of the changes merge) and regenerate them.
> >
> > Doug
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

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

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

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2018-08-17 06:56:11 +1000:
> On Thu, Aug 16, 2018 at 10:45:32AM -0400, Doug Hellmann wrote:
> 
> > Is there any reason we can't uncap pbr, at least within the CI jobs?
> 
> It might work for the docs builds but jumping a major version of pbr,
> which if I recall caused problems ate the time (hence the lower-bound)
> for all octata projects wouldn't happen.
> 
> How terrible would it be to branch openstackdocstheme and backport the fix
> without the pbr changes?  It might also be possible, though I'm not sure
> how we'd land it, to branch (stable/ocata) openstackdocstheme today and
> just revert the pbr changes to set the lower bound.
> 
> If you let me know what the important changes are to functionality in
> oslosdocstheme I can play with it next week.  Having said that I'm aware
> there is time pressure here so I'm happy for others to do it
> 
> Yours Tony.

The thing we need is the deprecation badge support in
https://review.openstack.org/#/c/585517/

It if backporting that to an older version of the theme is going
to be easier, and we don't care about adding a feature to a stable
branch for that, than I'm OK with doing it that way.

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 Andreas Jaeger's message of 2018-08-16 08:42:22 +0200:
> On 2018-08-16 07:38, Tony Breeds wrote:
> > On Thu, Aug 16, 2018 at 06:27:39AM +0200, Andreas Jaeger wrote:
> > 
> >> Ocata should be retired by now ;) Let's drop it...
> > 
> > *cough* extended maintenance *cough*  ;P
> 
> Ah, forget about that.
> 
> > So we don't need the Ocata docs to be rebuilt with this version?
> 
> Ocata uses older sphinx etc. It would be nice - but not sure about the
> effort,

We want *all* of the docs rebuilt with this version.

Is there any reason we can't uncap pbr, at least within the CI jobs?

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] [oslo][castellan][python3][goal] need help debugging stable/queens failure in castellan functional tests

[Doug Hellmann]

The patch to add the zuul job settings to the castellan stable/queens
branch is failing the castellan-functional-devstack job. It looks like
the job fails to set up some of the services correctly (I see lots of
messages about services not responding or not starting).

When was that job added to castellan? Should it be running on
stable/queens?

If we need it, can someone familiar with the job look into the
failure and try to fix the problem?

Thanks,
Doug

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

__
OpenStack Development Mailing 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 Andreas Jaeger's message of 2018-08-15 09:28:51 +0200:
> On 08/15/2018 07:25 AM, Tony Breeds wrote:
> > 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 :)
> 
> openstackdocsstheme has:
> sphinx!=1.6.6,!=1.6.7,>=1.6.2
> 
> So, we cannot use it on branches that constraint sphinx to an older version,
> 
> Sorry, can't check this right now from where I am,
> Andreas

That's a good point. We should give it a try, though. I don't think
pip's constraints resolver takes version specifiers into account, so we
should get the older sphinx and the newer theme. If those do happen to
work together, it should be OK.

If not, we need another solution. We may have to do more work to
backport the theme change into an older version of the library to
make it work in the old 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] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2018-08-15 15:25:29 +1000:
> 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.

Thanks, Tony!

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

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

Re: [openstack-dev] [oslo][tooz][etcd] need help debugging tooz test failure

[Doug Hellmann]

Excerpts from Davanum Srinivas (dims)'s message of 2018-08-14 04:05:23 +0800:
> Jay, Doug,
> 
> We need to blacklist 0.2.2 and 0.2.3 (looking at changelog in)
> https://github.com/dims/etcd3-gateway/releases

Done in https://review.openstack.org/591517

Thanks,
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] [oslo][tooz][etcd] need help debugging tooz test failure

[Doug Hellmann]

Excerpts from Davanum Srinivas (dims)'s message of 2018-08-14 03:50:54 +0800:
> Thanks Jay. Pushed out a 0.2.4 with a revert to the offending PR
> 
> On Tue, Aug 14, 2018 at 1:22 AM Jay Pipes  wrote:
> 
> > On 08/12/2018 04:11 PM, Doug Hellmann wrote:
> > > The tooz tests on master and stable/rocky are failing with an error:
> > >
> > >  UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in position
> > 0:
> > >  invalid continuation byte
> > >
> > > This is unrelated to the change, which is simply importing test job
> > > settings or updating the .gitreview file. I need someone familiar with
> > > the library to help debug the issue.
> > >
> > > Can we get a volunteer?
> >
> > Looking into it. Seems to be related to this upstream patch to
> > python-etcd3gw:
> >
> >
> > https://github.com/dims/etcd3-gateway/commit/224f40972b42c4ff16234c0e78ea765e3fe1af95
> >
> > 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
> >
> 

I filed the constraint update: https://review.openstack.org/591498

I also set the tooz patches to depend on that as a test:
https://review.openstack.org/588720

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] [oslo][tooz][etcd] need help debugging tooz test failure

[Doug Hellmann]

Excerpts from Jay Pipes's message of 2018-08-13 13:21:56 -0400:
> On 08/12/2018 04:11 PM, Doug Hellmann wrote:
> > The tooz tests on master and stable/rocky are failing with an error:
> > 
> >  UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in position 0:
> >  invalid continuation byte
> > 
> > This is unrelated to the change, which is simply importing test job
> > settings or updating the .gitreview file. I need someone familiar with
> > the library to help debug the issue.
> > 
> > Can we get a volunteer?
> 
> Looking into it. Seems to be related to this upstream patch to 
> python-etcd3gw:
> 
> https://github.com/dims/etcd3-gateway/commit/224f40972b42c4ff16234c0e78ea765e3fe1af95
> 
> Best,
> -jay
> 

Thanks, Jay!

I see that Dims says he pushed a release. Is that something we need to
update in the constraints list, then?

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] [goal][python3] week 1 update: here we go!

[Doug Hellmann]

This is week 1 of the roll-out of the "Run under Python 3 by default"
goal (https://governance.openstack.org/tc/goals/stein/python3-first.html).

I intend to send a summary message like this roughly weekly to
report progress on the Zuul setting migrations, because that portion
of the goal needs to be coordinated.

I will also be watching for changes to
https://wiki.openstack.org/wiki/Python3 and will try to report on
progress with functional or unit test jobs as teams log the information
there.

This email is a bit longer than I hope they will usually be, because
it is the first and has some planning information.

== The Plan ==

The completion criteria from the goal are:

1. The Zuul settings to attach jobs have been moved from the
   openstack-infra/project-config repository into each project
   repository.
2. Documentation build and publish jobs use python 3.
3. Release notes build and publish jobs use python 3.
4. Source code linter jobs (pep8, pylint, bandit, etc.) should use
   python 3.
5. Release artifact build and publish jobs use python 3 and publish to
   PyPI.
6. There are functional test jobs running under python 3.
7. The wiki tracking page is up to date for the project.
8. Projects are running python 3.6 unit test jobs.

The goal champions will start by preparing the patches for steps
1-5, and 8. That will give project teams more time to focus on
reviewing and on completing steps 6 and 7, which will need the
expertise of someone on the team.

PLEASE do not write the Zuul configuration migration patches
yourselves.  The rules for which things need to move ended up a bit
complicated, it's all automated, and we do not want to start them
before all of the stable/rocky branches are created for a team
(otherwise we risk misconfiguring the stable branch). Sit tight
and be ready to review the patches when we send them your way.

We are waiting to start most teams until the final releases for
Rocky are done, but we're going to start some of the teams less
affected by that deadline early (like Oslo, Infra, and possibly
Documentation).  Project teams should be prepared to assist if there
are any issues or questions about jobs with branch-specifiers.

While the job migration is under way, changes to project-config for
the team's repositories will be locked. As soon as the patches to
import the job settings are landed for *all* of the repositories
owned by a team we will update the project-config repo to remove
those settings and then the job settings for the team will be
unfrozen again. So, please review zuul configuration changes quickly,
but carefully. :-)

Step 6 involves adding more test jobs and may also require code
changes or tox settings updates, so that work will be left to the
project team.

Step 7, updating the wiki tracking page to indicate what level of
testing is being done and where any gaps might be, is the responsibility
of the project team.

Step 8 starts with a simple patch to add the unit test jobs, which
will come as part of the rest of the zuul migration patches. If the
tests do not immediately work, We will need the project teams to
fix things up in the code or tox.ini files so the tests pass.

== Tracking Progress ==

Because teams potentially need to do something in each repository,
I have created separate stories for each team in storyboard, with
one task per repo. Those stories are all tagged with 'goal-python3-first'
and appear on the tracking board at
https://storyboard.openstack.org/#!/board/104 The tasks on these
stories are for teams to track their work. Feel free to add more
tasks or otherwise elaborate on the stories as needed. If you add
more stories, please use the same tag so they will show up on the
board.

Because not all teams have migrated to storyboard, some of the tasks
are associated with the openstack/governance repo instead of a team
repository. If your team wants to track work using a different tool,
please come back and update the storyboard tasks as part of completing
your goal so anyone tracking progress can find it all in one place.
PTLs should update the stories based on the instructions in the
goal procedures
(https://governance.openstack.org/tc/goals/index.html#team-acknowledgment-of-goals
). If you include the story and task information in commit messages,
some of that updating will happen for free (this is one of the
reasons we're using storyboard).

The goal champions will use a separate story, with one task per
team, to track the work we are going to do with the zuul configuration
migration. See https://storyboard.openstack.org/#!/story/2002586
for details.

== Ongoing work ==

We are making good progress with migrating the zuul settings for
the Oslo team as a final test of the full process. We will start
with other regular teams after the final release candidates for
Rocky are done (after 24 Aug), and the cycle-trailing projects after
their release deadline has passed (after 31 Aug).

== Next Steps ==

If your team is interested in being one of 

Re: [openstack-dev] [releases][rocky][tempest-plugins][ptl] Reminder to tag the Tempest plugins for Rocky release

[Doug Hellmann]

Excerpts from Ghanshyam Mann's message of 2018-08-13 23:12:51 +0900:
> 
> 
> 
>   On Mon, 13 Aug 2018 23:01:33 +0900 Doug Hellmann 
>  wrote  
>  > Excerpts from Dmitry Tantsur's message of 2018-08-13 15:51:56 +0200:
>  > > On 08/13/2018 03:46 PM, Doug Hellmann wrote:
>  > > > Excerpts from Dmitry Tantsur's message of 2018-08-13 15:35:23 +0200:
>  > > >> Hi,
>  > > >>
>  > > >> The plugins are branchless and should stay so. Let us not dive into 
> this madness
>  > > >> again please.
>  > > > 
>  > > > You are correct that we do not want to branch, because we want the
>  > > > same tests running against all branches of services in our CI system
>  > > > to help us avoid (or at least recognize) API-breaking changes across
>  > > > release boundaries.
>  > > 
>  > > Okay, thank you for clarification. I stand corrected and apologize if my 
>  > > frustration was expressed too loudly or harshly :)
>  > 
>  > Not at all. This is new territory, and we made a decision somewhat
>  > quickly, so I am not surprised that we need to do a little more work to
>  > communicate the results.
>  > 
>  > > 
>  > > > 
>  > > > We *do* need to tag so that people consuming the plugins to certify
>  > > > their clouds know which version of the plugin works with the version
>  > > > of the software they are installing. Newer versions of plugins may
>  > > > rely on features or changes in newer versions of tempest, or other
>  > > > dependencies, that are not available in an environment that is
>  > > > running an older cloud.
>  > > 
>  > > ++
>  > > 
>  > > > 
>  > > > We will apply those tags in the series-specific deliverable files in
>  > > > openstack/releases so that the version numbers appear together on
>  > > > releases.openstack.org on the relevant release page so that users
>  > > > looking for the "rocky" version of a plugin can find it easily.
>  > > 
>  > > Okay, this makes sense now.
>  > 
>  > Good.
>  > 
>  > Now, we just need someone to figure out where to write all of that down
>  > so we don't have to have the same conversation next cycle. :-)
> 
> +1, this is very imp. I was discussing the same with amotoki today on QA 
> channel. I have added a TODO for me to write the 1. "How Plugins should cover 
> the stable branch testing with branchless repo" now i can add 2nd TODO also 
> 2. "Release model & tagging clarification of Tempest  Plugins". I do not know 
> the best common place to add those doc but as start i can write those in 
> Tempest doc and later we can refer/move the same on Plugins side too. 
> 
> I have added this TODO on qa stein ptg etherpad also for reminder/feedback- 
> https://etherpad.openstack.org/p/qa-stein-ptg

We have a reference page for deliverable types in the releases
repository
(https://releases.openstack.org/reference/deliverable_types.html). That
could be a place to talk about the tagging and branching expectations.
It doesn't cover tempest-plugins at all, yet.

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] [tc] Technical Committee update for 13 Aug

[Doug Hellmann]

This is the weekly summary of work being done by the Technical
Committee members. The full list of active items is managed in the
wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Project updates:

- add tripleo ansible repo: https://review.openstack.org/#/c/583416/
- add openstack-chef repo: https://review.openstack.org/#/c/585473/

Other changes:

- Stein goal for upgrade check automation: 
https://review.openstack.org/#/c/585491/
- confirm the Stein election results: https://review.openstack.org/#/c/589691/
- confirm Darisz Krol PTL for Trove: https://review.openstack.org/#/c/588510/
- confirm Dirk Mueller PTL for rpm-packaging project: 
https://review.openstack.org/#/c/588617/
- remove expired extra ATCs: https://review.openstack.org/#/c/588586/

== Leaderless teams after PTL elections ==

As part of the discussion of how to deal with re-appointments of
PTLs where no governance patch would be needed and hence we would
have no place to vote, Chris has proposed a schema change that will
let us handle the changes in the governance repo instead of updating
the election repository after the election is over.

- https://review.openstack.org/#/c/590790/

The RefStack team is being dissolved and the repositories moved to
the interop working group.

- https://review.openstack.org/#/c/590179/

Claudiu Belu volunteered to serve as PTL for the Winstackers team
again for Stein.

- https://review.openstack.org/#/c/590386/

We now have volunteers to serve as PTL for both Freezer and
Searchlight, so we need to decide what action to take with those
teams.

- removing both from the rocky release: 
https://review.openstack.org/#/c/588605/ 
- removing freezer from governance: 
http://lists.openstack.org/pipermail/openstack-dev/2018-August/132873.html and 
https://review.openstack.org/#/c/588645/
- removing searchlight from governance: 
http://lists.openstack.org/pipermail/openstack-dev/2018-August/132874.html and 
https://review.openstack.org/#/c/588644/
- Trinh Nguyen has volunteered to be PTL for Searchlight: 
https://review.openstack.org/#/c/590601/
- Changcai Geng has volunteered to be PTL for Freezer: 
https://review.openstack.org/#/c/590071/

== Ongoing Discussions ==

Ian has updated his proposals to change the project testing interface
to support PDF generation and documentation translation. These need
to be reviewed by folks familiar with the tools and processes.

- https://review.openstack.org/#/c/572559/
- https://review.openstack.org/#/c/588110/

The TC is planning 2 meetings during the week of the PTG. The
proposed agendas are up for comment.

- https://etherpad.openstack.org/p/tc-stein-ptg

== TC member actions/focus/discussions for the coming week(s) ==

The PTG is approaching quickly. Please complete any remaining team
health checks.

Besides the items listed above as ongoing discussions, we have
several other governance reviews open without sufficient votes to
be approved. Please review.

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

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

- 09:00 UTC on Tuesdays
- 01:00 UTC on Wednesdays
- 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string "tc-members" to alert the members to your question.

You will find channel logs with past conversations at
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/

If you expect your topic to require significant discussion or to
need input from members of the community other than the TC, please
start a mailing list discussion on openstack-dev at lists.openstack.org
and use the subject tag "[tc]" to bring it to the attention of TC
members.



__
OpenStack Development Mailing 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

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2018-08-13 15:51:56 +0200:
> On 08/13/2018 03:46 PM, Doug Hellmann wrote:
> > Excerpts from Dmitry Tantsur's message of 2018-08-13 15:35:23 +0200:
> >> Hi,
> >>
> >> The plugins are branchless and should stay so. Let us not dive into this 
> >> madness
> >> again please.
> > 
> > You are correct that we do not want to branch, because we want the
> > same tests running against all branches of services in our CI system
> > to help us avoid (or at least recognize) API-breaking changes across
> > release boundaries.
> 
> Okay, thank you for clarification. I stand corrected and apologize if my 
> frustration was expressed too loudly or harshly :)

Not at all. This is new territory, and we made a decision somewhat
quickly, so I am not surprised that we need to do a little more work to
communicate the results.

> 
> > 
> > We *do* need to tag so that people consuming the plugins to certify
> > their clouds know which version of the plugin works with the version
> > of the software they are installing. Newer versions of plugins may
> > rely on features or changes in newer versions of tempest, or other
> > dependencies, that are not available in an environment that is
> > running an older cloud.
> 
> ++
> 
> > 
> > We will apply those tags in the series-specific deliverable files in
> > openstack/releases so that the version numbers appear together on
> > releases.openstack.org on the relevant release page so that users
> > looking for the "rocky" version of a plugin can find it easily.
> 
> Okay, this makes sense now.

Good.

Now, we just need someone to figure out where to write all of that down
so we don't have to have the same conversation next cycle. :-)

Doug

> 
> > 
> > Doug
> > 
> >>
> >> Dmitry
> >>
> >> On 08/12/2018 10:41 AM, 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.
> >>
> >> Please make up your mind. Please. Please. Please.
> >>
> >>>
> >>> [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
> >>>
> >>>
> >>>
> >>> __
> >>> OpenStack Development Mailing 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] [releases][rocky][tempest-plugins][ptl] Reminder to tag the Tempest plugins for Rocky release

[Doug Hellmann]

Excerpts from Jim Rollenhagen's message of 2018-08-13 09:50:34 -0400:
> // jim
> 
> On Mon, Aug 13, 2018 at 9:46 AM, Doug Hellmann 
> wrote:
> 
> > Excerpts from Dmitry Tantsur's message of 2018-08-13 15:35:23 +0200:
> > > Hi,
> > >
> > > The plugins are branchless and should stay so. Let us not dive into this
> > madness
> > > again please.
> >
> > You are correct that we do not want to branch, because we want the
> > same tests running against all branches of services in our CI system
> > to help us avoid (or at least recognize) API-breaking changes across
> > release boundaries.
> >
> > We *do* need to tag so that people consuming the plugins to certify
> > their clouds know which version of the plugin works with the version
> > of the software they are installing. Newer versions of plugins may
> > rely on features or changes in newer versions of tempest, or other
> > dependencies, that are not available in an environment that is
> > running an older cloud.
> >
> > We will apply those tags in the series-specific deliverable files in
> > openstack/releases so that the version numbers appear together on
> > releases.openstack.org on the relevant release page so that users
> > looking for the "rocky" version of a plugin can find it easily.
> >
> 
> Thanks Doug. My confusion was around the cycle-with-intermediary model,
> which I thought implied a stable branch. Tagging at end of cycle seems
> fine to me. :)
> 
> // jim

Normally cycle-with-intermediary would imply a branch, but it's really
focused more around the releases than the branching. There's a separate
flag that most deliverables don't need to use that controls the
branching policy, and in this case we treat these repos as branchless.

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

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2018-08-13 15:35:23 +0200:
> Hi,
> 
> The plugins are branchless and should stay so. Let us not dive into this 
> madness 
> again please.

You are correct that we do not want to branch, because we want the
same tests running against all branches of services in our CI system
to help us avoid (or at least recognize) API-breaking changes across
release boundaries.

We *do* need to tag so that people consuming the plugins to certify
their clouds know which version of the plugin works with the version
of the software they are installing. Newer versions of plugins may
rely on features or changes in newer versions of tempest, or other
dependencies, that are not available in an environment that is
running an older cloud.

We will apply those tags in the series-specific deliverable files in
openstack/releases so that the version numbers appear together on
releases.openstack.org on the relevant release page so that users
looking for the "rocky" version of a plugin can find it easily.

Doug

> 
> Dmitry
> 
> On 08/12/2018 10:41 AM, 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.
> 
> Please make up your mind. Please. Please. Please.
> 
> > 
> > [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
> > 
> > 
> > 
> > __
> > OpenStack Development Mailing 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] [oslo][tooz][etcd] need help debugging tooz test failure

[Doug Hellmann]

The tooz tests on master and stable/rocky are failing with an error:

UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in position 0:
invalid continuation byte

This is unrelated to the change, which is simply importing test job
settings or updating the .gitreview file. I need someone familiar with
the library to help debug the issue.

Can we get a volunteer?

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

__
OpenStack Development Mailing 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][tc][election] Timing of the Upcoming Stein TC election

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2018-08-10 07:44:42 +1000:
> On Thu, Aug 09, 2018 at 05:20:53PM -0400, Doug Hellmann wrote:
> > Excerpts from Tony Breeds's message of 2018-08-08 14:39:30 +1000:
> > > Hello all,
> > > With the PTL elections behind us it's time to start looking at the
> > > TC election.  Our charter[1] says:
> > > 
> > >   The election is held no later than 6 weeks prior to each OpenStack
> > >   Summit (on or before ‘S-6’ week), with elections held open for no less
> > >   than four business days.
> > > 
> > > Assuming we have the same structure that gives us a timeline of:
> > > 
> > >   Summit is at: 2018-11-13
> > >   Latest possible completion is at: 2018-10-02
> > >   Moving back to Tuesday: 2018-10-02
> > >   TC Election from 2018-09-25T23:45 to 2018-10-02T23:45
> > >   TC Campaigning from 2018-09-18T23:45 to 2018-09-25T23:45
> > >   TC Nominations from 2018-09-11T23:45 to 2018-09-18T23:45
> > > 
> > > This puts the bulk of the nomination period during the PTG, which is
> > > sub-optimal as the nominations cause a distraction from the PTG but more
> > > so because the campaigning will coincide with travel home, and some
> > > community members take vacation along with the PTG.
> > > 
> > > So I'd like to bring up the idea of moving the election forward a
> > > little so that it's actually the campaigning period that overlaps with
> > > the PTG:
> > > 
> > >   TC Electionfrom 2018-09-18T23:45 to 2018-09-27T23:45
> > >   TC Campaigning from 2018-09-06T23:45 to 2018-09-18T23:45
> > >   TC Nominations from 2018-08-30T23:45 to 2018-09-06T23:45
> > > 
> > > This gives us longer campaigning and election periods.
> > > 
> > > There are some advantages to doing this:
> > > 
> > >  * A panel style Q could be held formally or informally ;P
> > >  * There's improved scope for for incoming, outgoing and staying put TC
> > >members to interact in a high bandwidth way.
> > >  * In personi/private discussions with TC candidates/members.
> > > 
> > > However it isn't without downsides:
> > > 
> > >   * Election fatigue, We've just had the PTL elections and the UC
> > > elections are currently running.  Less break before the TC elections
> > > may not be a good thing.
> > >   * TC candidates that can't travel to the PTG could be disadvantaged
> > >   * The campaigning would all happen at the PTG and not on the mailing
> > > list disadvantaging community members not at the PTG.
> > > 
> > > So thoughts?
> > > 
> > > Yours Tony.
> > > 
> > > [1] https://governance.openstack.org/tc/reference/charter.html
> > 
> > Who needs to make this decision? The current TC?
> 
> I believe that the TC delegated that to the Election WG [1] but the
> governance here is a little gray/fuzzy.

OK, I'm content for the Election team to make the call I just wanted to
make sure I gave you an opinion if you were asking me for one. ;-)

> So I kinda think that if the TC doesn't object I can propose the patch
> to the election repo and you (as TC chair) can +/-1 is as you see fit.
> 
> Is it fair to ask we do that shortly after the next TC office hours?

+1

> 
> Yours Tony.
> 
> [1] https://governance.openstack.org/tc/reference/working-groups.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] [tc] [all] documenting appointed PTLs

[Doug Hellmann]

Excerpts from Chris Dent's message of 2018-08-10 16:19:27 +0100:
> 
> We've had several appointed PTLs this cycle, in some cases because
> people forgot to nominate themselves, in other cases because
> existing maintainers have been pulled away and volunteers stepped
> up. Thanks to those people who did.
> 
> We haven't had a formal process for documenting those appointments
> and there's been some confusion on who and where it should all
> happen. I've proposed a plan at
> 
>  https://review.openstack.org/#/c/590790/
> 
> that may not yet be perfect, but gives a starting point on which
> to accrete a reasonable solution.
> 
> If you have opinions on the matter, please leave something on the
> review.
> 
> Thanks.
> 

Thanks for writing that up, Chris.

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][tc][election] Timing of the Upcoming Stein TC election

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2018-08-08 14:39:30 +1000:
> Hello all,
> With the PTL elections behind us it's time to start looking at the
> TC election.  Our charter[1] says:
> 
>   The election is held no later than 6 weeks prior to each OpenStack
>   Summit (on or before ‘S-6’ week), with elections held open for no less
>   than four business days.
> 
> Assuming we have the same structure that gives us a timeline of:
> 
>   Summit is at: 2018-11-13
>   Latest possible completion is at: 2018-10-02
>   Moving back to Tuesday: 2018-10-02
>   TC Election from 2018-09-25T23:45 to 2018-10-02T23:45
>   TC Campaigning from 2018-09-18T23:45 to 2018-09-25T23:45
>   TC Nominations from 2018-09-11T23:45 to 2018-09-18T23:45
> 
> This puts the bulk of the nomination period during the PTG, which is
> sub-optimal as the nominations cause a distraction from the PTG but more
> so because the campaigning will coincide with travel home, and some
> community members take vacation along with the PTG.
> 
> So I'd like to bring up the idea of moving the election forward a
> little so that it's actually the campaigning period that overlaps with
> the PTG:
> 
>   TC Electionfrom 2018-09-18T23:45 to 2018-09-27T23:45
>   TC Campaigning from 2018-09-06T23:45 to 2018-09-18T23:45
>   TC Nominations from 2018-08-30T23:45 to 2018-09-06T23:45
> 
> This gives us longer campaigning and election periods.
> 
> There are some advantages to doing this:
> 
>  * A panel style Q could be held formally or informally ;P
>  * There's improved scope for for incoming, outgoing and staying put TC
>members to interact in a high bandwidth way.
>  * In personi/private discussions with TC candidates/members.
> 
> However it isn't without downsides:
> 
>   * Election fatigue, We've just had the PTL elections and the UC
> elections are currently running.  Less break before the TC elections
> may not be a good thing.
>   * TC candidates that can't travel to the PTG could be disadvantaged
>   * The campaigning would all happen at the PTG and not on the mailing
> list disadvantaging community members not at the PTG.
> 
> So thoughts?
> 
> Yours Tony.
> 
> [1] https://governance.openstack.org/tc/reference/charter.html

Who needs to make this decision? The current TC?

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] [openstack-ansible][kolla-ansible][tripleo] ansible roles: where they live and what do they do

[Doug Hellmann]

Excerpts from Alex Schultz's message of 2018-08-09 14:31:34 -0600:
> Ahoy folks,
> 
> I think it's time we come up with some basic rules/patterns on where
> code lands when it comes to OpenStack related Ansible roles and as we
> convert/export things. There was a recent proposal to create an
> ansible-role-tempest[0] that would take what we use in
> tripleo-quickstart-extras[1] and separate it for re-usability by
> others.   So it was asked if we could work with the openstack-ansible
> team and leverage the existing openstack-ansible-os_tempest[2].  It
> turns out we have a few more already existing roles laying around as
> well[3][4].
> 
> What I would like to propose is that we as a community come together
> to agree on specific patterns so that we can leverage the same roles
> for some of the core configuration/deployment functionality while
> still allowing for specific project specific customization.  What I've
> noticed between all the project is that we have a few specific core
> pieces of functionality that needs to be handled (or skipped as it may
> be) for each service being deployed.
> 
> 1) software installation
> 2) configuration management
> 3) service management
> 4) misc service actions
> 
> Depending on which flavor of the deployment you're using, the content
> of each of these may be different.  Just about the only thing that is
> shared between them all would be the configuration management part.

Does that make the 4 things separate roles, then? Isn't the role
usually the unit of sharing between playbooks?

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][election][tc] Lederless projects.

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2018-08-01 10:32:50 +1000:

[snip]

> Need appointment  : 8 (Dragonflow Freezer Loci Packaging_Rpm RefStack
>Searchlight Trove Winstackers)

To summarize the situation for these teams as it stands now:

Omer Anson volunteered to serve as PTL for Dragonflow another term. The
patch to appoint him is https://review.openstack.org/589939

Changcai Geng has offered to be PTL for Freezer
(https://review.openstack.org/#/c/590071). There is still a proposal
to remove the project from governance
(https://review.openstack.org/588645).  We need the TC members to
vote on the proposals above to indicate which direction they want
to take.  Several folks suggested retaining the project provisionally,
but we don't have a formal proposal for that.  If you want to retain
the team provisionally, please say so when you vote in favor of
confirming Changcai Geng as PTL.

Sam Yaple has volunteered to serve as the PTL of Loci. The patch to
appoint him is https://review.openstack.org/#/c/590488/

Dirk Mueller volunteered to serve as the PTL of the packaging-rpm team.
The patch to confirm him is https://review.openstack.org/#/c/588617/

The repositories currently owned by the RefStack team are being moved to
the Interop Working Group in https://review.openstack.org/#/c/590179/

The proposal to remove the Searchlight project
(https://review.openstack.org/588644) has one comment indicating
potential interest in taking over maintenance of the project. We are
waiting for a formal proposal to designate a PTL before deciding whether
to keep the team under governance.

Dariusz Krol has volunteered to serve as PTL for Trove. The patch to
confirm him is https://review.openstack.org/#/c/588510/

Claudiu Belu has volunteered to serve as PTL for the Winstackers team.
The patch to confirm him is https://review.openstack.org/#/c/590386/

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] [nova][placement][oslo] Excessive WARNING level log messages in placement-api

[Doug Hellmann]

Excerpts from Lance Bragstad's message of 2018-08-09 12:55:52 -0500:
> 
> On 08/09/2018 12:48 PM, Doug Hellmann wrote:
> > Excerpts from Matt Riedemann's message of 2018-08-09 12:18:14 -0500:
> >> On 8/9/2018 11:47 AM, Doug Hellmann wrote:
> >>> Excerpts from Jay Pipes's message of 2018-08-08 22:53:54 -0400:
> >>>> For evidence, see:
> >>>>
> >>>> http://logs.openstack.org/41/590041/1/check/tempest-full-py3/db08dec/controller/logs/screen-placement-api.txt.gz?level=WARNING
> >>>>
> >>>> thousands of these are filling the logs with WARNING-level log messages,
> >>>> making it difficult to find anything:
> >>>>
> >>>> Aug 08 22:17:30.837557 ubuntu-xenial-inap-mtl01-0001226060
> >>>> devstack@placement-api.service[14403]: WARNING py.warnings
> >>>> [req-a809b022-59af-4628-be73-488cfec3187d
> >>>> req-d46cb1f0-431f-490f-955b-b9c2cd9f6437 service placement]
> >>>> /usr/local/lib/python3.5/dist-packages/oslo_policy/policy.py:896:
> >>>> UserWarning: Policy placement:resource_providers:list failed scope
> >>>> check. The token used to make the request was project scoped but the
> >>>> policy requires ['system'] scope. This behavior may change in the future
> >>>> where using the intended scope is required
> >>>> Aug 08 22:17:30.837800 ubuntu-xenial-inap-mtl01-0001226060
> >>>> devstack@placement-api.service[14403]:   warnings.warn(msg)
> >>>> Aug 08 22:17:30.838067 ubuntu-xenial-inap-mtl01-0001226060
> >>>> devstack@placement-api.service[14403]:
> >>>>
> >>>> Is there any way we can get rid of these?
> >>>>
> >>>> Thanks,
> >>>> -jay
> >>>>
> >>> It looks like those are coming out of the policy library? Maybe file a
> >>> bug there. I added "oslo" to the subject line to get the team's
> >>> attention.
> >>>
> >>> This feels like something we could fix and backport to rocky.
> >>>
> >>> Doug
> >> I could have sworn I created a bug in oslo.policy for this at one point 
> >> for the same reason Jay mentions it, but I guess not.
> >>
> >> We could simply, on the nova side, add a warnings filter to only log 
> >> this once.
> >>
> > What level should it be logged at in the policy library? Should it be
> > logged there at all?
> 
> The initial intent behind logging was to make sure operators knew that
> they needed to make a role assignment adjustment in order to be
> compatible moving forward. I can investigate a way to log things at
> least once in oslo.policy though. I fear not logging it at all would
> cause failures in upgrade since operators wouldn't know they need to
> make that adjustment.

That sounds like a good check to add to the upgrade test tools as part
of the goal for Stein.

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][masakari][release] Pre-release of openstack/masakari failed

[Doug Hellmann]

Excerpts from zuul's message of 2018-08-09 17:23:01 +:
> Build failed.
> 
> - release-openstack-python 
> http://logs.openstack.org/84/84135048cb372cbd11080fc27151949cee4e52d1/pre-release/release-openstack-python/095990b/
>  : FAILURE in 8m 57s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
> 

The RC1 build for Masakari failed with this error:

  error: can't copy 'etc/masakari/masakari-custom-recovery-methods.conf':
  doesn't exist or not a regular file

The packaging files need to be fixed so a new release candidate can be
prepared. The changes will need to be made on master and then backported
to the new stable/rocky branch.

Doug

http://logs.openstack.org/84/84135048cb372cbd11080fc27151949cee4e52d1/pre-release/release-openstack-python/095990b/ara-report/result/7459d483-48d8-414f-8830-d6411158f9a2/

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

Re: [openstack-dev] [nova][placement][oslo] Excessive WARNING level log messages in placement-api

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2018-08-09 12:18:14 -0500:
> On 8/9/2018 11:47 AM, Doug Hellmann wrote:
> > Excerpts from Jay Pipes's message of 2018-08-08 22:53:54 -0400:
> >> For evidence, see:
> >>
> >> http://logs.openstack.org/41/590041/1/check/tempest-full-py3/db08dec/controller/logs/screen-placement-api.txt.gz?level=WARNING
> >>
> >> thousands of these are filling the logs with WARNING-level log messages,
> >> making it difficult to find anything:
> >>
> >> Aug 08 22:17:30.837557 ubuntu-xenial-inap-mtl01-0001226060
> >> devstack@placement-api.service[14403]: WARNING py.warnings
> >> [req-a809b022-59af-4628-be73-488cfec3187d
> >> req-d46cb1f0-431f-490f-955b-b9c2cd9f6437 service placement]
> >> /usr/local/lib/python3.5/dist-packages/oslo_policy/policy.py:896:
> >> UserWarning: Policy placement:resource_providers:list failed scope
> >> check. The token used to make the request was project scoped but the
> >> policy requires ['system'] scope. This behavior may change in the future
> >> where using the intended scope is required
> >> Aug 08 22:17:30.837800 ubuntu-xenial-inap-mtl01-0001226060
> >> devstack@placement-api.service[14403]:   warnings.warn(msg)
> >> Aug 08 22:17:30.838067 ubuntu-xenial-inap-mtl01-0001226060
> >> devstack@placement-api.service[14403]:
> >>
> >> Is there any way we can get rid of these?
> >>
> >> Thanks,
> >> -jay
> >>
> > It looks like those are coming out of the policy library? Maybe file a
> > bug there. I added "oslo" to the subject line to get the team's
> > attention.
> > 
> > This feels like something we could fix and backport to rocky.
> > 
> > Doug
> 
> I could have sworn I created a bug in oslo.policy for this at one point 
> for the same reason Jay mentions it, but I guess not.
> 
> We could simply, on the nova side, add a warnings filter to only log 
> this once.
> 

What level should it be logged at in the policy library? Should it be
logged there at all?

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] [nova][placement][oslo] Excessive WARNING level log messages in placement-api

[Doug Hellmann]

Excerpts from Jay Pipes's message of 2018-08-08 22:53:54 -0400:
> For evidence, see:
> 
> http://logs.openstack.org/41/590041/1/check/tempest-full-py3/db08dec/controller/logs/screen-placement-api.txt.gz?level=WARNING
> 
> thousands of these are filling the logs with WARNING-level log messages, 
> making it difficult to find anything:
> 
> Aug 08 22:17:30.837557 ubuntu-xenial-inap-mtl01-0001226060 
> devstack@placement-api.service[14403]: WARNING py.warnings 
> [req-a809b022-59af-4628-be73-488cfec3187d 
> req-d46cb1f0-431f-490f-955b-b9c2cd9f6437 service placement] 
> /usr/local/lib/python3.5/dist-packages/oslo_policy/policy.py:896: 
> UserWarning: Policy placement:resource_providers:list failed scope 
> check. The token used to make the request was project scoped but the 
> policy requires ['system'] scope. This behavior may change in the future 
> where using the intended scope is required
> Aug 08 22:17:30.837800 ubuntu-xenial-inap-mtl01-0001226060 
> devstack@placement-api.service[14403]:   warnings.warn(msg)
> Aug 08 22:17:30.838067 ubuntu-xenial-inap-mtl01-0001226060 
> devstack@placement-api.service[14403]:
> 
> Is there any way we can get rid of these?
> 
> Thanks,
> -jay
> 

It looks like those are coming out of the policy library? Maybe file a
bug there. I added "oslo" to the subject line to get the team's
attention.

This feels like something we could fix and backport to rocky.

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] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

[Doug Hellmann]

Excerpts from Andrey Kurilin's message of 2018-08-09 13:35:53 +0300:
> Hi Doug!
> 
> I'm ready to port our job to openstack-zuul-jobs repo, but I expect that
> Community will not accept it.
> 
> The result of rally unittests is different between environments with python
> 3.7 final release and python 3.7.0~b3 .
> There is at least one failed test at python 3.7.0~b3 which is not
> reproducible at py27,py34,py35,py36,py37-final ,
> so I'm not sure that it is a good decision to add py37 job based on
> ubuntu-bionic.
> 
> As for Rally, I applied the easiest thing which occurred to me - just use
> external python ppa (deadsnakes) to
> install the final release of Python 3.7.
> Such a way is satisfying for Rally community and it cannot be used as the
> main one for the whole OpenStack.

Yes, I think we don't want to use that approach for most of the jobs.
The point is to test on the Python packaged in the distro.

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][elections] Project Team Lead Election Conclusion and Results

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2018-08-08 10:20:15 +1000:
> Thank you to the electorate, to all those who voted and to all
> candidates who put their name forward for Project Team Lead (PTL) in
> this election. A healthy, open process breeds trust in our decision
> making capability thank you to all those who make this process possible.
> 
> Now for the results of the PTL election process, please join me in
> extending congratulations to the following PTLs:
> 
>  * Adjutant  : Adrian Turjak   
>  * Barbican  : Ade Lee 
>  * Blazar: Pierre Riteau   
>  * Chef OpenStack: Samuel Cassiba  
>  * Cinder: Jay Bryant  
>  * Cloudkitty: Luka Peschke
>  * Congress  : Eric Kao
>  * Cyborg: Li Liu  
>  * Designate : Graham Hayes
>  * Documentation : Petr Kovar  
>  * Dragonflow: [1]
>  * Ec2 Api   : Andrey Pavlov   
>  * Freezer   : [1]
>  * Glance: Erno Kuvaja 
>  * Heat  : Rico Lin
>  * Horizon   : Ivan Kolodyazhny
>  * I18n  : Frank Kloeker   
>  * Infrastructure: Clark Boylan
>  * Ironic: Julia Kreger
>  * Karbor: Pengju Jiao 
>  * Keystone  : Lance Bragstad  
>  * Kolla : Eduardo Gonzalez Gutierrez  
>  * Kuryr : Daniel Mellado  
>  * Loci  : [1]
>  * Magnum: Spyros Trigazis 
>  * Manila: Thomas Barron   
>  * Masakari  : Sampath Priyankara  
>  * Mistral   : Dougal Matthews 
>  * Monasca   : Witek Bedyk 
>  * Murano: Rong Zhu
>  * Neutron   : Miguel Lavalle  
>  * Nova  : Melanie Witt
>  * Octavia   : Michael Johnson 
>  * OpenStackAnsible  : Mohammed Naser  
>  * OpenStackClient   : Dean Troyer 
>  * OpenStackSDK  : Monty Taylor
>  * OpenStack Charms  : Frode Nordahl   
>  * OpenStack Helm: Pete Birley 
>  * Oslo  : Ben Nemec   
>  * Packaging Rpm : [1]
>  * PowerVMStackers   : Matthew Edmonds 
>  * Puppet OpenStack  : Tobias Urdin
>  * Qinling   : Lingxian Kong   
>  * Quality Assurance : Ghanshyam Mann  
>  * Rally : Andrey Kurilin  
>  * RefStack  : [1]
>  * Release Management: Sean McGinnis   
>  * Requirements  : Matthew Thode   
>  * Sahara: Telles Nobrega  
>  * Searchlight   : [1]
>  * Security  : [1]
>  * Senlin: Duc Truong  
>  * Solum : Rong Zhu
>  * Storlets  : Kota Tsuyuzaki  
>  * Swift : John Dickinson  
>  * Tacker: dharmendra kushwaha 
>  * Telemetry : Julien Danjou   
>  * Tricircle : baisen song 
>  * Tripleo   : Juan Osorio Robles  
>  * Trove : [1]
>  * Vitrage   : Ifat Afek   
>  * Watcher   : Alexander Chadin
>  * Winstackers  

Re: [openstack-dev] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

[Doug Hellmann]

Excerpts from Andrey Kurilin's message of 2018-08-08 15:25:01 +0300:
> Thanks Thomas for pointing to the issue, I checked it locally and here is
> an update for openstack/rally (rally framework without in-tree OpenStack
> plugins) project:
> 
> - added unittest job with py37 env

It would be really useful if you could help set up a job definition in
openstack-zuul-jobs like we have for openstack-tox-py36 [1], so that other
projects can easily add the job, too. Do you have time to do that?

Doug

[1] 
http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/jobs.yaml#n354

__
OpenStack Development Mailing 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] Stepping down as coordinator for the Outreachy internships

[Doug Hellmann]

Excerpts from Victoria Martínez de la Cruz's message of 2018-08-07 20:47:28 
-0300:
> Hi all,
> 
> I'm reaching you out to let you know that I'll be stepping down as
> coordinator for OpenStack next round. I had been contributing to this
> effort for several rounds now and I believe is a good moment for somebody
> else to take the lead. You all know how important is Outreachy to me and
> I'm grateful for all the amazing things I've done as part of the Outreachy
> program and all the great people I've met in the way. I plan to keep
> involved with the internships but leave the coordination tasks to somebody
> else.
> 
> If you are interested in becoming an Outreachy coordinator, let me know and
> I can share my experience and provide some guidance.
> 
> Thanks,
> 
> Victoria

Thank you, Victoria. Mentoring new developers is an important
responsibility, and your patient service in working with the Outreachy
program has set a good example.

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] [oslo] proposing Moisés Guimarães for oslo.config core

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-08-01 09:27:09 -0400:
> Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
> during the Rocky cycle to add driver support. Based on that work,
> and a discussion we have had since then about general cleanup needed
> in oslo.config, I think he would make a good addition to the
> oslo.config review team.
> 
> Please indicate your approval or concerns with +1/-1.
> 
> Doug

Normally I would have added moguimar to the oslo-config-core team
today, after a week's wait. Funny story, though. There is no
oslo-config-core team.

oslo.config is one of a few of our libraries that we never set up with a
separate review team. It is managed by oslo-core. We could set up a new
review team for that library, but after giving it some thought I
realized that *most* of the libraries are fairly stable, our team is
pretty small, and Moisés is a good guy so maybe we don't need to worry
about that.

I spoke with Moisés, and he agreed to be part of the larger core team.
He pointed out that the next phase of the driver work is going to happen
in castellan, so it would be useful to have another reviewer there. And
I'm sure we can trust him to be careful with reviews in other repos
until he learns his way around.

So, I would like to amend my original proposal and suggest that we add
Moisés to the oslo-core team.

Please indicate support with +1 or present any concerns you have. I
apologize for the confusion on my part.

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] [goal][python3] more updates to the goal tools

[Doug Hellmann]

Champions,

I have made quite a few changes to the tools for generating the zuul
migration patches today. If you have any patches you generated locally
for testing, please check out the latest version of the tool (when all
of the changes merge) and regenerate them.

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] OpenStack lagging behind 2 major python versions: we need a Python 3.7 gate

[Doug Hellmann]

Excerpts from Thomas Goirand's message of 2018-08-07 16:11:43 +0200:
> On 08/07/2018 03:24 PM, Sean Mooney wrote:
> 
> > i think we as a community will have to decide on the minimum and
> > maximum python 3 versions
> > we support for each release and adjust as we go forward.
> 
> Whatever the OpenStack community decides is not going to change what
> distributions like Debian will do. This type of reasoning lacks a much
> needed humility.

That goes both ways, Thomas. We're in the middle of the RC1 deadline
week for Rocky right now. This is not a great time to be pushing
for new work unrelated to finishing that release.

> > it will also
> > impact the external python lib we can depend on too which is
> > another reason i think thie need to be a comuntiy wide discussion and
> > goal that is informed by what distros are doing but
> > not mandated by what any one distro is doing.
> > regards
> > sean.
> 
> Postponing any attempt to support anything current is always a bad idea.
> I don't see why there's even a controversy when one attempts to fix bugs
> that will, sooner or later, also hit the gate.

The community is not prepared to support 3.7 today. That doesn't
mean we will never support it, just that it is not the most important
thing for us to be doing right now. We'll get 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] Paste unmaintained

[Doug Hellmann]

Excerpts from Thomas Goirand's message of 2018-08-07 16:57:59 +0200:
> On 08/02/2018 04:27 PM, Doug Hellmann wrote:
> > 
> > The last I heard, a few years ago Ian moved away from Python to
> > JavaScript as part of his work at Mozilla. The support around
> > paste.deploy has been sporadic since then, and was one of the reasons
> > we discussed a goal of dropping paste.ini as a configuration file.
> 
> Doug,
> 
> That's nice to have direct dependency, but this doesn't cover
> everything. If using uwsgi, if you want any kind of logging from the
> wsgi application, you need to use pastescript, which itself runtimes
> depends on paste. So, anything which potentially has an API also depends
> indirectly on Paste.

I'm not sure why that would be the case. Surely *any* middleware could
set up logging?

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] [python3] champions, please review the updated process

[Doug Hellmann]

I have updated the README.rst in the goal-tools repository with an
updated process for preparing, proposing, and tracking the zuul
migration patches. I need the other champions to look over the
instructions and let me know if any parts are confusing or incomplete.
Please do that as soon as you can, so we can be prepared to start
generating patches after the final release for Rocky is done.

http://git.openstack.org/cgit/openstack/goal-tools/tree/README.rst#n22

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] [tc] Technical Committee status update for 6 August

[Doug Hellmann]

This is the weekly summary of work being done by the Technical
Committee members. The full list of active items is managed in the
wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Project updates:

- extra ATCs for I18n team: https://review.openstack.org/586751
- move security team repos to the SIG: https://review.openstack.org/586896 

== Leaderless teams after Stein PTL elections ==

We had 7 teams without any volunteers to serve as PTL for the Stein
cycle. The TC is handling each on a case-by-case basis, working
with the project teams and considering the broader context of
activity over the last cycle.

Omer Anson has volunteered to be PTL for the Dragonflow team. Omer
is the current PTL, so I do not anticipate any issues with the TC
confirming him to serve again.

Sam Yaple has agreed to serve as the PTL for the Loci team. Sam is
active in the project, so I do not anticipate any issues with his
confirmation.

Dirk Mueller has volunteered to serve as packaging-rpm team PTL. I do
not anticipate any issues with his confirmation, either.

- https://review.openstack.org/#/c/588617/

Jeremy and Julia are going to work with the RefStack team and Interop
working group to settle the ownership of the repositories currently
owned by the RefStack team. I anticipate the RefStack team being
dissolved when those new owners are found for those repositories.

Dariusz Krol has volunteered to serve as Trove team PTL. The TC
considered Dariusz's status carefully, because he is not currently
a contributor to Trove, but the Trove team seems willing to accept
Dariusz, so I anticipate the TC accepting him as PTL.

- https://review.openstack.org/#/c/588510/

Paul and Chris are working to contact the Winstackers team about
whether they want to find a volunteer to serve as PTL, or if the
team should be dissolved.

In addition to missing the PTL election, the Freezer and Searchlight
teams missed enough deadlines during the cycle for the release
management team to drop them from the Rocky release. We do not want
to continue to list teams as official if the projects are not
maintained and the teams are not active in the community. Given the
apparent lack of participation in community processes, we are
considering removing both teams from governance. We will not be
rushing to make a decision, however, so if you are interested in
either project please join the relevant thread with your input.

- removing both from the rocky release: 
https://review.openstack.org/#/c/588605/ 
- removing freezer from governance: 
http://lists.openstack.org/pipermail/openstack-dev/2018-August/132873.html and 
https://review.openstack.org/#/c/588645/
- removing searchlight from governance: 
http://lists.openstack.org/pipermail/openstack-dev/2018-August/132874.html and 
https://review.openstack.org/#/c/588644/

== Ongoing Discussions ==

Ian has updated his proposals to change the project testing interface
to support PDF generation and documentation translation. These need
to be reviewed by folks familiar with the tools and processes.

- https://review.openstack.org/#/c/572559/
- https://review.openstack.org/#/c/588110/

Sean has posted a new draft of the goal to create automated upgrade
checker tools.

- https://review.openstack.org/#/c/585491/

I have a patch to remove expired extra ATCs from several projects.
"Extra ATC" status is time-limited, just as regular ATC status is. This
patch is just housekeeping to remove some names that have expired.

- https://review.openstack.org/#/c/588586/

The TC is planning 2 meetings during the week of the PTG. The
proposed agendas are up for comment.

- https://etherpad.openstack.org/p/tc-stein-ptg

== TC member actions/focus/discussions for the coming week(s) ==

The PTG is approaching quickly. Please complete any remaining team
health checks.

Besides the items listed above as ongoing discussions, we have
several other governance reviews open without sufficient votes to
be approved. Please review.

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

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

- 09:00 UTC on Tuesdays
- 01:00 UTC on Wednesdays
- 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string 

Re: [openstack-dev] [all][requirements] a plan to stop syncing requirements into projects

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-05-14 08:52:08 -0400:
> Excerpts from Doug Hellmann's message of 2018-03-25 16:04:11 -0400:
> > Excerpts from Doug Hellmann's message of 2018-03-22 16:16:06 -0400:
> > > Excerpts from Doug Hellmann's message of 2018-03-21 16:02:06 -0400:
> > > > Excerpts from Doug Hellmann's message of 2018-03-15 07:03:11 -0400:
> > > > > 
> > > > > TL;DR
> > > > > -
> > > > > 
> > > > > Let's stop copying exact dependency specifications into all our
> > > > > projects to allow them to reflect the actual versions of things
> > > > > they depend on. The constraints system in pip makes this change
> > > > > safe. We still need to maintain some level of compatibility, so the
> > > > > existing requirements-check job (run for changes to requirements.txt
> > > > > within each repo) will change a bit rather than going away completely.
> > > > > We can enable unit test jobs to verify the lower constraint settings
> > > > > at the same time that we're doing the other work.
> > > > 
> > > > The new job definition is in https://review.openstack.org/555034 and I
> > > > have updated the oslo.config patch I mentioned before to use the new job
> > > > instead of one defined in the oslo.config repo (see
> > > > https://review.openstack.org/550603).
> > > > 
> > > > I'll wait for that job patch to be reviewed and approved before I start
> > > > adding the job to a bunch of other repositories.
> > > > 
> > > > Doug
> > > 
> > > The job definition for openstack-tox-lower-constraints [1] was approved
> > > today (thanks AJaegar and pabelenger).
> > > 
> > > I have started proposing the patches to add that job to the repos listed
> > > in openstack/requirements/projects.txt using the topic
> > > "requirements-stop-syncing" [2]. I hope to have the rest of those
> > > proposed by the end of the day tomorrow, but since they have to run in
> > > batches I don't know if that will be possible.
> > > 
> > > The patch to remove the update proposal job is ready for review [3].
> > > 
> > > As is the patch to allow project requirements to diverge by changing the
> > > rules in the requirements-check job [4].
> > > 
> > > We ran into a snag with a few of the jobs for projects that rely on
> > > having service projects installed. There have been a couple of threads
> > > about that recently, but Monty has promised to start another one to
> > > provide all of the necessary context so we can fix the issues and move
> > > ahead.
> > > 
> > > Doug
> > > 
> > 
> > All of the patches to define the lower-constraints test jobs have been
> > proposed [1], and many have already been approved and merged (thank you
> > for your quick reviews).
> > 
> > A few of the jobs are failing because the projects depend on installing
> > some other service from source. We will work out what to do with those
> > when we solve that problem in a more general way.
> > 
> > A few of the jobs failed because the dependencies were wrong. In a few
> > cases I was able to figure out what was wrong, but I can use some help
> > from project teams more familiar with the code bases to debug the
> > remaining failures.
> > 
> > In a few cases projects didn't have python 3 unit test jobs, so I
> > configured the new job to use python 2. Teams should add a step to their
> > python 3 migration plan to update the version of python used in the new
> > job, when that is possible.
> > 
> > I believe we are now ready to proceed with updating the
> > requirements-check job to relax the rules about which changes are
> > allowed [2].
> > 
> > Doug
> > 
> > [1] 
> > https://review.openstack.org/#/q/topic:requirements-stop-syncing+status:open
> > [2] https://review.openstack.org/555402
> 
> We still have about 50 open patches related to adding the
> lower-constraints test job. I'll keep those open until the third
> milestone of the Rocky development cycle, and then abandon the rest to
> clear my gerrit view so it is usable again.
> 
> If you want to add lower-constraints tests to your project and have
> an open patch in the list [1], please take it over and fix the
> settings then approve the patch (the fix usually involves making
> the values in lower-constraints.txt match the values in the various
> requirements.txt files).
> 
> If you don't want the job, please leave a comment on the patch to
> tell me and I will abandon it.
> 
> Doug

As mentioned in my earlier email, I have abandoned the ~30 reviews
that remained open this morning. Please do feel free to restore
those and take them over if you want the job.

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] [nova] tempest-full-py3 rename means we now run that job on test-only changes

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2018-08-04 16:44:26 -0500:
> I've reported a nova bug for this:
> 
> https://bugs.launchpad.net/nova/+bug/1785425
> 
> But I'm not sure what is the best way to fix it now with the zuul v3 
> hotness. We had an irrelevant-files entry in project-config for the 
> tempest-full job but we don't have that for tempest-full-py3, so should 
> we just rename that in project-config (guessing not)? Or should we do 
> something in nova's .zuul.yaml like this (guessing yes):
> 
> https://review.openstack.org/#/c/578878/
> 
> The former is easy and branchless but I'm guessing the latter is what we 
> should do long-term (and would require backports to stable branches).
> 

We don't want to rename the job, because we still want to run both
jobs for a time.

For what it's worth, as soon as Stein opens up I'm going to be
working with the rest of the goal champions to propose patches to
move the zuul settings for almost all jobs out of project-config
and into each project repo, including all of the stable branches.
If you add the settings to the config for nova in project-config
before we start that, those patches will include the new settings,
for the branches where the jobs run.

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] [searchlight][tc] removing searchlight from governance

[Doug Hellmann]

Based on the fact that the Searchlight team missed the Rocky release
and Stein PTL elections, I have proposed a patch to remove the
project from governance. If the project is still being actively
maintained and someone wants to take over leadership, please let
us know here in this thread or on the patch.

Doug

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

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

[openstack-dev] [freezer][tc] removing freezer from governance

[Doug Hellmann]

Based on the fact that the Freezer team missed the Rocky release and
Stein PTL elections, I have proposed a patch to remove the project from
governance. If the project is still being actively maintained and
someone wants to take over leadership, please let us know here in this
thread or on the patch.

Doug

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

__
OpenStack Development Mailing 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] Proposing Zane Bitter as oslo.service core

[Doug Hellmann]

Excerpts from Ben Nemec's message of 2018-08-03 11:58:29 -0500:
> Hi,
> 
> Zane has been doing some good work in oslo.service recently and I would 
> like to add him to the core team.  I know he's got a lot on his plate 
> already, but he has taken the time to propose and review patches in 
> oslo.service and has demonstrated an understanding of the code.
> 
> Please respond with +1 or any concerns you may have.  Thanks.
> 
> -Ben
> 

+1, and thanks, 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

Re: [openstack-dev] Paste unmaintained

[Doug Hellmann]

Excerpts from Stephen Finucane's message of 2018-08-02 15:11:25 +0100:
> tl;dr: It seems Paste [1] may be entering unmaintained territory and we
> may need to do something about it.
> 
> I was cleaning up some warning messages that nova was issuing this
> morning and noticed a few coming from Paste. I was going to draft a PR
> to fix this, but a quick browse through the Bitbucket project [2]
> suggests there has been little to no activity on that for well over a
> year. One particular open PR - "Python 3.7 support" - is particularly
> concerning, given the recent mailing list threads on the matter.
> 
> Given that multiple projects are using this, we may want to think about
> reaching out to the author and seeing if there's anything we can do to
> at least keep this maintained going forward. I've talked to cdent about
> this already but if anyone else has ideas, please let me know.
> 
> Stephen
> 
> [1] https://pypi.org/project/Paste/
> [2] https://bitbucket.org/ianb/paste/
> [3] https://bitbucket.org/ianb/paste/pull-requests/41
> 

The last I heard, a few years ago Ian moved away from Python to
JavaScript as part of his work at Mozilla. The support around
paste.deploy has been sporadic since then, and was one of the reasons
we discussed a goal of dropping paste.ini as a configuration file.

Do we have a real sense of how many of the projects below, which
list Paste in requirements.txt, actually use it directly or rely
on it for configuration?

Doug

$ beagle search --ignore-case --file requirements.txt 'paste[><=! ]'
+++--++
| Repository | Filename 
  | Line | Text   |
+++--++
| airship-armada | requirements.txt 
  |8 | Paste>=2.0.3   |
| airship-deckhand   | requirements.txt 
  |   12 | Paste # MIT|
| anchor | requirements.txt 
  |9 | Paste # MIT|
| apmec  | requirements.txt 
  |6 | Paste>=2.0.2 # MIT |
| barbican   | requirements.txt 
  |   22 | Paste>=2.0.2 # MIT |
| cinder | requirements.txt 
  |   37 | Paste>=2.0.2 # MIT |
| congress   | requirements.txt 
  |   11 | Paste>=2.0.2 # MIT |
| designate  | requirements.txt 
  |   25 | Paste>=2.0.2 # MIT |
| ec2-api| requirements.txt 
  |   20 | Paste # MIT|
| freezer-api| requirements.txt 
  |8 | Paste>=2.0.2 # MIT |
| gce-api| requirements.txt 
  |   16 | Paste>=2.0.2 # MIT |
| glance | requirements.txt 
  |   31 | Paste>=2.0.2 # MIT |
| glare  | requirements.txt 
  |   29 | Paste>=2.0.2 # MIT |
| karbor | requirements.txt 
  |   28 | Paste>=2.0.2 # MIT |
| kingbird   | requirements.txt 
  |7 | Paste>=2.0.2 # MIT |
| manila | requirements.txt 
  |   30 | Paste>=2.0.2 # MIT |
| meteos | requirements.txt 
  |   29 | Paste # MIT|
| monasca-events-api | requirements.txt 
  |6 | Paste # MIT|
| monasca-log-api| requirements.txt 
  |6 | Paste>=2.0.2 # MIT |
| murano | requirements.txt 
  |   28 | Paste>=2.0.2 # MIT |
| neutron| requirements.txt 
  |6 | Paste>=2.0.2 # MIT |
| nova   | requirements.txt 
  |   19 | Paste>=2.0.2 # MIT |
| novajoin   | requirements.txt 
  |6 | Paste>=2.0.2 # MIT |
| oslo.service   | requirements.txt 
  |   

Re: [openstack-dev] [all][election] PTL nominations are now closed

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2018-08-02 10:58:53 +0200:
> Tony Breeds wrote:
> > [...]
> > There are 8 projects without candidates, so according to this
> > resolution[1], the TC will have to decide how the following
> > projects will proceed: Dragonflow, Freezer, Loci, Packaging_Rpm,
> > RefStack, Searchlight, Trove and Winstackers.
> 
> Here is my take on that...
> 
> Packaging_Rpm has a late candidate (Dirk Mueller). We always have a few 
> teams per cycle that miss the election call, that would fall under that.
> 
> Trove had a volunteer (Dariusz Krol), but that person did not fill the 
> requirements for candidates. Given that the previous PTL (Zhao Chao) 
> plans to stay around to help onboarding the new contributors, I'd 
> support appointing Dariusz.
> 
> I suspect Freezer falls in the same bucket as Packaging_Rpm and we 
> should get a candidate there. I would reach out to caoyuan see if they 
> would be interested in steeping up.
> 
> LOCI is also likely in the same bucket. However, given that it's a 
> deployment project, if we can't get anyone to step up and guarantee some 
> level of currentness, we should consider removing it from the "official" 
> list.
> 
> Dragonflow is a bit in the LOCI case. It feels like a miss too, but if 
> it's not, given that it's an add-on project that runs within Neutron, I 
> would consider removing it from the "official" list if we can't find 
> anyone to step up.
> 
> For Winstackers and Searchlight, those are low-activity teams (18 and 13 
> commits), which brings the question of PTL workload for feature-complete 
> projects.

Even for feature-complete projects we need to know how to reach the
maintainers, otherwise I feel like we would consider the project
unmaintained, wouldn't we?

> 
> Finally, RefStack: I feel like this should be wrapped into an 
> Interoperability SIG, since that project team is not producing 
> "OpenStack", but helping fostering OpenStack interoperability. Having 
> separate groups (Interop WG, RefStack) sounds overkill anyway, and with 
> the introduction of SIGs we have been recentering project teams on 
> upstream code production.
> 

__
OpenStack Development Mailing 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][election] PTL nominations are now closed

[Doug Hellmann]

Excerpts from Omer Anson's message of 2018-08-02 12:56:37 +0300:
> Hi,
> 
> I'm sorry for the inconvenience. I completely missed the nomination period.
> Is it possible to send in a late nomination for Dragonflow?

At this point the TC is going to be looking for a volunteer, so if there
is one please let us know.

Doug

> 
> Thanks,
> Omer Anson.
> 
> On Thu, 2 Aug 2018 at 11:59, Thierry Carrez  wrote:
> 
> > Tony Breeds wrote:
> > > [...]
> > > There are 8 projects without candidates, so according to this
> > > resolution[1], the TC will have to decide how the following
> > > projects will proceed: Dragonflow, Freezer, Loci, Packaging_Rpm,
> > > RefStack, Searchlight, Trove and Winstackers.
> >
> > Here is my take on that...
> >
> > Packaging_Rpm has a late candidate (Dirk Mueller). We always have a few
> > teams per cycle that miss the election call, that would fall under that.
> >
> > Trove had a volunteer (Dariusz Krol), but that person did not fill the
> > requirements for candidates. Given that the previous PTL (Zhao Chao)
> > plans to stay around to help onboarding the new contributors, I'd
> > support appointing Dariusz.
> >
> > I suspect Freezer falls in the same bucket as Packaging_Rpm and we
> > should get a candidate there. I would reach out to caoyuan see if they
> > would be interested in steeping up.
> >
> > LOCI is also likely in the same bucket. However, given that it's a
> > deployment project, if we can't get anyone to step up and guarantee some
> > level of currentness, we should consider removing it from the "official"
> > list.
> >
> > Dragonflow is a bit in the LOCI case. It feels like a miss too, but if
> > it's not, given that it's an add-on project that runs within Neutron, I
> > would consider removing it from the "official" list if we can't find
> > anyone to step up.
> >
> > For Winstackers and Searchlight, those are low-activity teams (18 and 13
> > commits), which brings the question of PTL workload for feature-complete
> > projects.
> >
> > Finally, RefStack: I feel like this should be wrapped into an
> > Interoperability SIG, since that project team is not producing
> > "OpenStack", but helping fostering OpenStack interoperability. Having
> > separate groups (Interop WG, RefStack) sounds overkill anyway, and with
> > the introduction of SIGs we have been recentering project teams on
> > upstream code production.
> >
> > --
> > Thierry Carrez (ttx)
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

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

Re: [openstack-dev] [all][election] PTL nominations are now closed

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-08-02 13:13:21 +:
> On 2018-08-02 10:58:53 +0200 (+0200), Thierry Carrez wrote:
> [...]
> > Finally, RefStack: I feel like this should be wrapped into an
> > Interoperability SIG, since that project team is not producing
> > "OpenStack", but helping fostering OpenStack interoperability.
> > Having separate groups (Interop WG, RefStack) sounds overkill
> > anyway, and with the introduction of SIGs we have been recentering
> > project teams on upstream code production.
> 
> That was one of the possibilities I discussed with them during their
> meeting a month ago:
> 
> http://eavesdrop.openstack.org/irclogs/%23refstack/%23refstack.2018-07-03.log.html#t2018-07-03T17:05:43
> 
> Election official hat off and TC Refstack liaison hat on, I think if
> Chris Hoge doesn't volunteer to act as PTL this cycle to oversee
> shutting down the team and reassigning its deliverables, then we
> need to help them fast-track that nowish and not appoint a Stein
> cycle PTL.

This came up at a joint leadership meeting right after we created SIGs
and the Interop WG was reluctant to make any structural changes at the
time because they had just gone through a renaming process for the
working group. Changing "WG" to "SIG" feels much lighter weight, so
maybe we can move ahead with that now.

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] [tc] Technical Committee update for 1 Aug 2018

[Doug Hellmann]

This is the weekly summary of work being done by the Technical
Committee members. The full list of active items is managed in the
wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Approved changes:

- python3-first goal: https://review.openstack.org/#/c/575933/

== Ongoing Discussions ==

Dims started porting the compute:starter-kit tag to be a constellation.
This highlighted an issue with the current definition of that set of
projects and their use of the tools in the base services list.

- https://review.openstack.org/#/c/586212/

We had 7 teams without any volunteers to serve as PTL for the Stein
cycle (Dragonflow, Freezer, Loci, Packaging-RPM, Refstack, Searchlight,
and Winstackers). The Trove team had a volunteer, but that person does
not qualify under our normal rules that say the PTL should be an ATC.
This triggered some discussion of what the PTL's role is, why we have
it, and whether we may need to make some changes in how it is defined
and used.

The TC will be reviewing what to do with those teams over the next week
or two.

- https://wiki.openstack.org/wiki/OpenStack_health_tracker#Status_updates

Thierry posted about the changes to the Summit & PTG and how they will
affect the Stein release cycle. tl;dr: Because the Summit and PTG will
be combined at the end of Stein, the cycle will be a little longer to
allow the release dates to sync with the event.

- http://lists.openstack.org/pipermail/openstack-dev/2018-July/132651.html

== TC member actions/focus/discussions for the coming week(s) ==

The TC members who are liaisons to one of the teams affected by a lack
of PTL candidates should contact the current PTL for those teams to
ensure that they are aware of the problem.

Please review the suggested topics for the TC to discuss at the PTG:

- https://etherpad.openstack.org/p/tc-stein-ptg

The PTG is approaching quickly. Please complete any remaining team
health checks.

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

- 09:00 UTC on Tuesdays
- 01:00 UTC on Wednesdays
- 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string "tc-members" to alert the members to your question.

You will find channel logs with past conversations at
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/

If you expect your topic to require significant discussion or to
need input from members of the community other than the TC, please
start a mailing list discussion on openstack-dev at lists.openstack.org
and use the subject tag "[tc]" to bring it to the attention of TC
members.


__
OpenStack Development Mailing 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][python3] approved python3-first goal for stein

[Doug Hellmann]

The goal to run jobs under python3 first has been approved for Stein
[1].

We are going to be using storyboard for tracking work on the goal,
so I have started creating the stories and tasks. Because of the
complexity of the work, I am setting up 1 story for each team, with
1 task for each repository. For repositories that haven't migrated
to storyboard, the tasks will be associated with the openstack/governance
repository. See [2] for the relevant stories.

The first phase of the work for this goal involves a lot of zuul
reconfiguration, so please do not start on it until after we have
completed the Rocky release.

As the goal document describes, the champions for this goal will
propose the patches to move the zuul settings (we have some nice
tools to do this in a consistent way).  I expect we will start with
that around the time of the PTG. Stand by for more details.

Doug

[1] https://governance.openstack.org/tc/goals/stein/python3-first.html
[2] https://storyboard.openstack.org/#!/search?tags=goal-python3-first

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

Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels

[Doug Hellmann]

Excerpts from Monty Taylor's message of 2018-08-01 09:58:03 -0500:
> On 08/01/2018 08:38 AM, Jeremy Stanley wrote:
> > On 2018-08-01 09:58:48 -0300 (-0300), Rafael Weingärtner wrote:
> >> What about Rocket chat instead of Slack? It is open source.
> >> https://github.com/RocketChat/Rocket.Chat
> >>
> >> Monty, what kind of evaluation would you guys need? I might be
> >> able to help.
> > 
> > Consider reading and possibly resurrecting the infra spec for it:
> > 
> >  https://review.openstack.org/319506
> > 
> > My main concern is how we'll go about authenticating and policing
> > whatever gateway we set up. As soon as spammers and other abusers
> > find out there's an open (or nearly so) proxy to a major IRC
> > network, they'll use it to hide their origins from the IRC server
> > operators and put us in the middle of the problem.
> 
> To be clear -- I was not suggesting running matrix and IRC. I was 
> suggesting investigating running a matrix home server and the 
> permanently moving all openstack channels to it.
> 
> matrix synapse supports federated identity providers with saml and cas 
> support implemented. I would imagine we'd want to configure it to 
> federate to openstackid for logging in to the home server -so that might 
> involve either adding saml support to openstackid or writing an 
> openid-connect driver to synapse.
> 

This matches my expectations. We did talk about supporting a temporary
bridge to IRC, during the migration, but I don't think we need to run an
"open" home server to have that.

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] [oslo] proposing Moisés Guimarães for oslo.config core

[Doug Hellmann]

Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
during the Rocky cycle to add driver support. Based on that work,
and a discussion we have had since then about general cleanup needed
in oslo.config, I think he would make a good addition to the
oslo.config review team.

Please indicate your approval or concerns with +1/-1.

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] Ongoing spam in Freenode IRC channels

[Doug Hellmann]

Excerpts from Andrey Kurilin's message of 2018-08-01 15:21:37 +0300:
> ср, 1 авг. 2018 г. в 14:11, Dmitry Tantsur :
> 
> > On 08/01/2018 12:49 PM, Andrey Kurilin wrote:
> > > Hey Ian and stackers!
> > >
> > > ср, 1 авг. 2018 г. в 8:45, Ian Wienand  > > >:
> > >
> > > Hello,
> > >
> > > It seems freenode is currently receiving a lot of unsolicited traffic
> > > across all channels.  The freenode team are aware [1] and doing their
> > > best.
> > >
> > > There are not really a lot of options.  We can set "+r" on channels
> > > which means only nickserv registered users can join channels.  We
> > have
> > > traditionally avoided this, because it is yet one more barrier to
> > > communication when many are already unfamiliar with IRC access.
> > > However, having channels filled with irrelevant messages is also not
> > > very accessible.
> > >
> > > This is temporarily enabled in #openstack-infra for the time being,
> > so
> > > we can co-ordinate without interruption.
> > >
> > > Thankfully AFAIK we have not needed an abuse policy on this before;
> > > but I guess we are the point we need some sort of coordinated
> > > response.
> > >
> > > I'd suggest to start, people with an interest in a channel can
> > request
> > > +r from an IRC admin in #openstack-infra and we track it at [2]
> > >
> > > Longer term ... suggestions welcome? :)
> > >
> > >
> > > Move to Slack? We can provide auto-sending to emails invitations for
> > joining by
> > > clicking the button on some page at openstack.org .
> > It
> > > will not add more berrier for new contributors and, at the same time,
> > this way
> > > will give some base filtering by emails at least.
> >
> > A few potential barriers with slack or similar solutions: lack of FOSS
> > desktop
> > clients (correct me if I'm wrong),
> 
> 
> The second link from google search gives an opensource client written in
> python https://github.com/raelgc/scudcloud . Also, there is something which
> is written in golang.
> 
> > complete lack of any console clients (ditto),
> >
> 
> Again, google gives several ones as first results -
> https://github.com/evanyeung/terminal-slack
> https://github.com/erroneousboat/slack-term
> 
> serious limits on free (as in beer) tariff plans.
> >
> >
> I can make an assumption that for marketing reasons, Slack Inc can propose
> extended Free plan.
> But anyway, even with default one the only thing which can limit us is
> `10,000 searchable messages` which is bigger than 0 (freenode doesn't store
> messages).
> 
> 
> Why I like slack? because a lot of people are familar with it (a lot of
> companies use it as like some opensource communities, like k8s )
> 
> PS: I realize that OpenStack Community will never go away from Freenode and
> IRC, but I do not want to stay silent.

We are unlikely to select slack because the platform itself is
proprietary, even if there are OSS clients. That said, there have
been some discussions about platforms such as Matrix, which is
similar to slack and also OSS.

I think the main thing that is blocking any such move right now is
the fact that we're lacking someone with time to evaluate the tool
to see what it would take for us to run it. If you're interested in
this, maybe you can work with the infrastructure team to plan and
implement that evaluation?

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][ffe] Critical bug found in python-cinderclient

[Doug Hellmann]

Excerpts from Sean McGinnis's message of 2018-07-31 14:15:08 -0500:
> A critical bug has been found in python-cinderclient that is impacting both
> horizon and python-openstackclient (at least).
> 
> https://bugs.launchpad.net/cinder/+bug/1784703
> 
> tl;dr is, something new was added with a microversion, but support for that 
> was
> done incorrectly such that nothing less than that new microversion would be
> allowed. This patch addresses the issue:
> 
> https://review.openstack.org/587601
> 
> Once that lands we will need a new python-cinderclient release to unbreak
> clients. We may want to blacklist python-cinderclient 4.0.0, but I think at
> least just raising the upper-constraints should get things working again.
> 
> Sean
> 

Both adding the exclusion and changing the upper constraint makes sense,
since it will ensure that bad version never makes it back into the
constraints list.

We don't need to sync the exclusion setting into all of the projects
that depend on the client, so we won't need a new release of any of the
downstream consumers.

We could add the exclusion to OSC on master, just for accuracy's sake.

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] [tc] Technical Committee update for 17 July

[Doug Hellmann]

This is the weekly summary of work being done by the Technical
Committee members. The full list of active items is managed in the
wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Project updates:

- Add ansible-role-openstack-operations to governance
  https://review.openstack.org/#/c/578963/

- Add ansible-role-tripleo-* to TripleO project
  https://review.openstack.org/#/c/579952/1

Other approved changes:

- update the PTI to use tox for building docs
  https://review.openstack.org/#/c/580495/

Office hour logs:

(I sent the update late last week, so we have only had one office hour since 
the last update.)

- 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-07-12.log.html#t2018-07-12T14:59:39

== Ongoing Discussions ==

The Adjutant team application has been approved. Welcome!

- https://review.openstack.org/553643 project team application
- http://lists.openstack.org/pipermail/openstack-dev/2018-July/132308.html 
welcome announcement

Tony and the rest of the election officials are scheduling the Stein
PTL elections.

- https://review.openstack.org/#/c/582109/ stein PTL election preparations

Zane has updated his proposal for diversity requirements or guidance
for new project teams.

- https://review.openstack.org/#/c/567944/

== TC member actions/focus/discussions for the coming week(s) ==

We've made good progress on the health checks. If you anticipate
having any trouble contacting your assigned teams before the PTG
please let me know.

Remember that we agreed to send status updates on initiatives
separately to openstack-dev every two weeks. If you are working on
something for which there has not been an update in a couple of
weeks, please consider summarizing the status.

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

- 09:00 UTC on Tuesdays
- 01:00 UTC on Wednesdays
- 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string "tc-members" to alert the members to your question.

You will find channel logs with past conversations at
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/

If you expect your topic to require significant discussion or to
need input from members of the community other than the TC, please
start a mailing list discussion on openstack-dev at lists.openstack.org
and use the subject tag "[tc]" to bring it to the attention of TC
members.


__
OpenStack Development Mailing 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][tc][release][election][adjutant] Welcome Adjutant as an official project!

[Doug Hellmann]

The Adjutant team's application [1] to become an official project
has been approved. Welcome!

As I said on the review, because it is past the deadline for Rocky
membership, Adjutant will not be considered part of the Rocky
release, but a future release can be part of Stein.

The team should complete the onboarding process for new projects,
including holding PTL elections for Stein, setting up deliverable
files in the openstack/releases repository, and adding meeting
information to eavesdrop.openstack.org.

I have left a comment on the patch setting up the Stein election
to ask that the Adjutant team be included.  We can also add Adjutant
to the list of projects on docs.openstack.org for Stein, after
updating your publishing job(s).

Doug

[1] https://review.openstack.org/553643

__
OpenStack Development Mailing 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][ptl][release] deadline for non-client library releases 19 July

[Doug Hellmann]

The deadline for releasing non-client libraries for Rocky is coming up
next week on 19 July (https://releases.openstack.org/rocky/schedule.html).

We have a few libraries that have no releases at all this cycle,
which makes creating the stable branch problematic. Therefore, if
the PTL or release liaison do not propose a release by next week,
the release team may tag HEAD of master with an appropriate version
number (raising at least the minor value) to provide a place to
create the stable/rocky branch. (See Thread at
http://lists.openstack.org/pipermail/openstack-dev/2018-June/131341.html
for the discussion of this policy. We will need to decide whether
to tag based on whether there are any changes on master for the
repository.)

- automaton
- ceilometermiddleware
- debtcollector
- pycadf
- requestsexceptions
- stevedore

Below is the set of unreleased changes for known deliverables
classified as non-client libraries and that look like they may
warrant a release (i.e., they are not only CI configuration changes).
Any items in the report below that are not also in the list above
will not be tagged by the release team because we already have a
tag we can use to create the stable branch. The unrelease changes
for those deliverables will not be available to Rocky users unless
they are backported to the stable branch.

If you manage one of these deliverables, please review the list and
consider proposing a release before the deadline.

Doug


[ Unreleased changes in openstack/automaton (master) ]

Changes between 1.14.0 and ce03d76

* ce03d76 2018-07-11 09:48:53 +0700 Switch to stestr
* 5d8233a 2018-06-06 14:53:48 -0400 fix tox python3 overrides
* 885b3d4 2018-04-21 02:40:23 +0800 Trivial: Update pypi url to new url
* 67b3093 2018-04-13 15:48:27 -0400 fix list of default virtualenvs
* aa12fe5 2018-04-13 15:48:23 -0400 set default python to python3
* f8623e5 2018-03-24 21:02:01 -0400 add lower-constraints job
* 84a646c 2018-03-15 06:45:10 + Updated from global requirements
* 85b7139 2018-01-24 17:58:52 + Update reno for stable/queens
* 08228a1 2018-01-24 00:48:55 + Updated from global requirements
* 22b2b86 2018-01-17 20:27:45 + Updated from global requirements
* 6191cf6 2018-01-16 04:02:08 + Updated from global requirements



[ Unreleased changes in openstack/ceilometermiddleware (master) ]

Changes between 1.2.0 and 8332b9e

* 8332b9e 2018-06-06 15:27:00 -0400 fix tox python3 overrides
* 2f0efc7 2018-02-01 16:33:52 + Update reno for stable/queens




[ Unreleased changes in openstack/debtcollector (master) ]

Changes between 1.19.0 and 858f15d

* 858f15d 2018-06-06 14:53:48 -0400 fix tox python3 overrides
* 2ee856f 2018-04-21 05:21:26 +0800 Trivial: Update pypi url to new url
* 821478a 2018-04-16 11:16:59 -0400 remove obsolete tox environments
* 03292af 2018-04-16 11:16:59 -0400 set default python to python3
* 9e2a2d1 2018-03-15 06:50:50 + Updated from global requirements
| * d8e616d 2018-03-24 21:02:07 -0400 add lower-constraints job
| * 17ffa68 2018-03-21 18:26:09 +0530 pypy is not checked at gate
|/  
* 19616fc 2018-03-10 13:09:54 + Updated from global requirements
* b9a6777 2018-02-28 01:53:43 +0800 Update links in README
* 0ff121e 2018-01-24 17:59:41 + Update reno for stable/queens
| * 4e6aabb 2018-01-24 00:51:19 + Updated from global requirements
|/  
* dceacf1 2018-01-17 20:30:24 + Updated from global requirements
* 81d2312 2017-11-17 10:09:38 +0100 Remove setting of version/release from 
releasenotes



[ Unreleased changes in openstack/glance_store (master) ]

Changes between 0.24.0 and d50ab63

* d50ab63 2018-07-09 15:42:10 + specify region on creating cinderclient
* 573fde0 2018-06-06 15:27:00 -0400 fix tox python3 overrides
* 5a20d47 2018-06-20 19:40:17 -0400 Deprecate 
store_capabilities_update_min_interval
* 54b7ccb 2016-12-20 16:07:45 +1100 Disable verification for Keystone session 
in Swift




[ Unreleased changes in openstack/ironic-lib (master) ]

Changes between 2.13.0 and 9ba805d

* 9ba805d 2018-07-11 18:16:12 +0700 Remove testrepository
* a809787 2018-07-02 11:39:03 +0200 Expose GPT partitioning fixing method
* 89fbae4 2018-06-27 14:50:06 -0400 Switch to using stestr
* 68f017f 2018-06-27 12:36:05 +0200 Do not run API (functional) tests in the CI
* 4e31bc5 2018-06-07 17:34:53 + Remove unneccessary lambda from 
_test_make_partitions
* e4dda71 2018-06-06 15:27:00 -0400 fix tox python3 overrides



[ Unreleased changes in openstack/kuryr (master) ]

Changes between 0.8.0 and cb6eef2

* 6dc4279 2018-05-11 09:33:19 +0700 Replace deprecated "auth_uri" by 
"www_authenticate_uri"



[ Unreleased changes in openstack/mistral-lib (master) ]

Changes between 0.5.0 and d1ccfd0

* d1ccfd0 2018-06-27 15:11:04 + Fixed the documentation of 'run' params
* df04a2b 2018-06-12 16:07:01 +0100 Add the restructuredtext check to the 
flake8 job
* 37fea13 2018-06-06 15:27:00 -0400 fix tox python3 overrides
* de6805b 2018-05-22 13:18:29 -0700 Switch to using 

[openstack-dev] [release][ptl] Release countdown for week R-6, July 16-20

[Doug Hellmann]

Development Focus
-

Teams should be focused on implementing planned work. Work should be
wrapping up on non-client libraries to meet the lib deadline Thursday,
the 19th.

General Information
---

We are now getting close to the end of the cycle. The non-client library
(typically any lib other than the "python-$PROJECTclient" deliverables)
deadline is 19 July, followed quickly the next Thursday with the final
client library release. Releases for critical fixes will be allowed
after this point, but we will be much more restrictive about what is
allowed if there are more lib release requests after this point. Please
keep this in mind.

When requesting these library releases, you should also include the
stable branching request with the review (as an example, see the
"branches" section here:
http://git.openstack.org/cgit/openstack/releases/tree/deliverables/pike/os-brick.yaml#n2)


Upcoming Deadlines & Dates
--

Final non-client library release deadline: July 19
Final client library release deadline: July 26
Rocky-3 Milestone: July 26

__
OpenStack Development Mailing 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][group-based-policy] Release of openstack/group-based-policy failed

[Doug Hellmann]

Excerpts from Sumit Naiksatam's message of 2018-07-10 13:24:25 -0700:
> Thanks Doug for noticing this. I am guessing this was a transient
> issue. How do we trigger this job again to confirm?

Someone from the infra team with access to the zuul interface can help
you with that.

> 
> On Tue, Jul 10, 2018 at 9:21 AM, Doug Hellmann  wrote:
> > Excerpts from zuul's message of 2018-07-10 06:38:24 +:
> >> Build failed.
> >>
> >> - release-openstack-python 
> >> http://logs.openstack.org/5b/5bbcfd7b41d39339ff9b9f8654681406d2508205/release/release-openstack-python/269f8ce/
> >>  : FAILURE in 6m 31s
> >> - announce-release announce-release : SKIPPED
> >> - propose-update-constraints propose-update-constraints : SKIPPED
> >>
> >
> > The release job failed trying to pip install something due to an SSL
> > error.
> >
> > http://logs.openstack.org/5b/5bbcfd7b41d39339ff9b9f8654681406d2508205/release/release-openstack-python/269f8ce/job-output.txt.gz#_2018-07-10_06_37_26_065386
> >
> > __
> > OpenStack Development Mailing 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] Technical Committee update for 2018-07-10

[Doug Hellmann]

This is the weekly summary of work being done by the Technical
Committee members. The full list of active items is managed in the
wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Other approved changes:

* remove project team diversity tags: https://review.openstack.org/#/c/579870/

Office hour logs:

* 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-07-04.log.html#t2018-07-04T01:00:01
* 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-07-05.log.html#t2018-07-05T15:00:09
* 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-07-10.log.html#t2018-07-10T09:01:41

== Ongoing Discussions ==

The Adjutant team application as the minimum number of votes required to
be approved. It could not be formally accepted until 14 July and I know
we have several TC members traveling this week so I will hold it open
until next week to allow for final votes and discussion.

* https://review.openstack.org/553643

Colleen is going to contact the election officials about scheduling the
elections for the end of Rocky / beginning of Stein.

Project team "health check" discussions are continuing. As Chris
mentioned in his email this week, the point of this process is to have
TC members actively engage with each team to understand any potential
issues they are facing. We have a few teams impacted by the ZTE
situation, and we have a few other teams with some affiliation diversity
concerns that we would like to try to help address. We have also
discovered that some teams are healthier than we expected based on how
obvious (or not) their activity was.

* http://lists.openstack.org/pipermail/openstack-dev/2018-July/132101.html

I have made a few revisions to the python3-first goal based on feedback
on the patch and testing. I expect a few more small updates with links
to examples.

* https://review.openstack.org/575933

I have also proposed a PTI update for the documentation jobs that is a
prerequisite to moving ahead with the python 3 changes during Stein.

* https://review.openstack.org/580495
* http://lists.openstack.org/pipermail/openstack-dev/2018-July/132025.html

== TC member actions/focus/discussions for the coming week(s) ==

Thierry's changes to the Project Team Guide to include a technical
guidance section need reviewers.

* https://review.openstack.org/#/c/578070/1

Zane needs to update the proposal for diversity requirements or guidance
for new project teams based on existing feedback.

* https://review.openstack.org/#/c/567944/

Please vote on the Adjutant team application.
https://review.openstack.org/553643

Remember that we agreed to send status updates on initiatives separately
to openstack-dev every two weeks. If you are working on something for
which there has not been an update in a couple of weeks, please consider
summarizing the status.

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

* 09:00 UTC on Tuesdays
* 01:00 UTC on Wednesdays
* 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string "tc-members" to alert the members to your question.

You will find channel logs with past conversations at
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/

If you expect your topic to require significant discussion or to
need input from members of the community other than the TC, please
start a mailing list discussion on openstack-dev at lists.openstack.org
and use the subject tag "[tc]" to bring it to the attention of TC
members.


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

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2018-07-10 10:59:33 -0500:
> On 18-07-09 15:15:23, Matthew Thode wrote:
> > We have a patch that looks good, can we get it merged?
> > 
> > https://review.openstack.org/#/c/577833/
> > 
> 
> Anyone from taskflow around?  Maybe it's better to just mail the ptl.
> 

We could use more reviewers on taskflow (and have needed them for a
while). Perhaps we can get some of the consuming projects to give it a
little live so the Oslo folks who are less familiar with it feel
confident of the change(s) this close to the final release date for
non-client libraries.

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][group-based-policy] Release of openstack/group-based-policy failed

[Doug Hellmann]

Excerpts from zuul's message of 2018-07-10 06:38:24 +:
> Build failed.
> 
> - release-openstack-python 
> http://logs.openstack.org/5b/5bbcfd7b41d39339ff9b9f8654681406d2508205/release/release-openstack-python/269f8ce/
>  : FAILURE in 6m 31s
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
> 

The release job failed trying to pip install something due to an SSL
error.

http://logs.openstack.org/5b/5bbcfd7b41d39339ff9b9f8654681406d2508205/release/release-openstack-python/269f8ce/job-output.txt.gz#_2018-07-10_06_37_26_065386

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

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

[Doug Hellmann]

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

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

Doug

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

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

[Doug Hellmann]

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

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

Doug

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

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

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

[Doug Hellmann]

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

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

Doug

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

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

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

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

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

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

Happy toxing,
the tox-dev team

--- End forwarded message ---

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

Re: [openstack-dev] [python3][tc][infra][docs] changing the documentation build PTI to use tox

[Doug Hellmann]

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

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

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

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

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

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

> 
> > So, this new PTI definition restores the use of tox and specifies
> > a "docs" environment. I have started defining the relevant jobs [2]
> > and project templates [3], and I will be updating the python3-first
> > transition plan as well.
> > 
> > Let me know if you have any questions about any of that,
> > Doug
> > 
> > [1] https://review.openstack.org/#/c/580495/
> > [2] 
> > https://review.openstack.org/#/q/project:openstack-infra/project-config+topic:python3-first
> > [3] 
> > https://review.openstack.org/#/q/project:openstack-infra/openstack-zuul-jobs+topic:python3-first
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 

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

[openstack-dev] [python3][tc][infra][docs] changing the documentation build PTI to use tox

[Doug Hellmann]

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

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

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

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

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

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

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

Re: [openstack-dev] [cinder][security][api-wg] Adding http security headers

[Doug Hellmann]

Excerpts from Jim Rollenhagen's message of 2018-07-05 12:53:34 -0400:
> On Thu, Jul 5, 2018 at 12:40 PM, Nishant Kumar E <
> nishant.e.ku...@ericsson.com> wrote:
> 
> > Hi,
> >
> >
> >
> > I have registered a blueprint for adding http security headers -
> > https://blueprints.launchpad.net/cinder/+spec/http-security-headers
> >
> >
> >
> > Reason for introducing this change - I work for AT cloud project –
> > Network Cloud (Earlier known as AT integrated Cloud). As part of working
> > there we have introduced this change within all the services as kind of a
> > downstream change but would like to see it a part of upstream community.
> > While we did not face any major threats without this change but during our
> > investigation process we found that if dealing with web services we should
> > maximize the security as much as possible and came up with a list of HTTP
> > security headers that we should include as part of the OpenStack services.
> > I would like to introduce this change as part of cinder to start off and
> > then propagate this to all the services.
> >
> >
> >
> > Some reference links which might give more insight into this:
> >
> >- https://www.owasp.org/index.php/OWASP_Secure_Headers_
> >Project#tab=Headers
> >- https://www.keycdn.com/blog/http-security-headers/
> >- https://securityintelligence.com/an-introduction-to-http-
> >response-headers-for-security/
> >
> > Please let me know if this looks good and whether it can be included as
> > part of Cinder followed by other services. More details on how the
> > implementation will be done is mentioned as part of the blueprint but any
> > better ideas for implementation is welcomed too !!
> >
> 
> Wouldn't this be a job for the HTTP server in front of cinder (or whatever
> service)? Especially "Strict-Transport-Security" as one shouldn't be
> enabling that without ensuring a correct TLS config.
> 
> Bonus points in that upstream wouldn't need any changes, and we won't need
> to change every project. :)
> 
> // jim

Yes, this feels very much like something the deployment tools should
do when they set up Apache or uWSGI or whatever service is in front
of each API WSGI service.

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] [tc] Technical Committee Update for 3 July

[Doug Hellmann]

Excerpts from Hongbin Lu's message of 2018-07-03 22:06:41 -0400:
> >
> > Discussions about affiliation diversity continue in two directions.
> > Zane's proposal for requirements for new project teams has stalled a
> > bit. The work Thierry and Mohammed have done on the diversity tags has
> > brought a new statistics script and a proposal to drop the use of the
> > tags in favor of folding the diversity information into the more general
> > health checks we are doing. Thierry has updated the health tracker page
> >
> 
> Hi,
> 
> If appropriate, I would rather to nominate myself as the liaison for the
> Zun project. I am the first PTL of the project and familiar with the
> current status. I should be more appropriate for doing the health
> evaluation for this project. Please let me know if it is possible for me to
> participant.
> 
> Best regards,
> Hongbin

The point of the health check process is to have the TC actively
reach out to each team to see how things are going and identify
potential issues before they turn into full blown problems. So,
while I'm sure Zane and Thierry would welcome your input, we want
them to draw their own conclusions about the state of the project.

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-announce][ironic] ironic 11.0.0 (rocky)

[Doug Hellmann]

I want to compliment the Ironic team on writing such engaging and
comprehensive release notes. Nice work!

Doug

Excerpts from no-reply's message of 2018-07-05 10:24:19 +:
> We are gleeful to announce the release of:
> 
> ironic 11.0.0: OpenStack Bare Metal Provisioning
> 
> This release is part of the rocky release series.
> 
> The source is available from:
> 
> https://git.openstack.org/cgit/openstack/ironic
> 
> Download the package from:
> 
> https://tarballs.openstack.org/ironic/
> 
> Please report issues through launchpad:
> 
> https://bugs.launchpad.net/ironic
> 
> For more details, please see below.
> 
> 11.0.0
> ^^
> 
> 
> Prelude
> ***
> 
> I R O N I C turns the dial to *11* In preparation for the OpenStack
> Rocky development cycle release, the "ironic" Bare Metal as a Service
> team announces the release of version 11.0. While it is not quite like
> a volume knob, this release lays the foundation for features coming in
> future releases and user experience enhancements. Some of these
> include the BIOS configuration framework, power fault recovery,
> additonal error handling, refactoring, removal of classic drivers, and
> many bug fixes.
> 
> 
> New Features
> 
> 
> * Adds the healthcheck middleware from oslo, configurable via the
>   "[healthcheck]/enabled" option. This middleware adds a status check
>   at */healthcheck*. This is useful for load balancers to determine if
>   a service is up (and add or remove it from rotation), or for
>   monitoring tools to see the health of the server. This endpoint is
>   unauthenticated, as not all load balancers or monitoring tools
>   support authenticating with a health check endpoint.
> 
> * Adds support to abort the inspection of a node in the "inspect
>   wait" state, as long as this operation is supported by the inspect
>   interface in use. A node in the "inspect wait" state accepts the
>   "abort" provisioning verb to initiate the abort process. This
>   feature is supported by the "inspector" inspect interface and is
>   available starting with API version 1.41.
> 
> * Adds support for reading and changing the node's "bios_interface"
>   field and enables the GET endpoints to check BIOS settings, if they
>   have already been cached. This requires a compatible
>   "bios_interface" to be set. This feature is available starting with
>   API version 1.40.
> 
> * The new ironic configuration setting "[deploy]/default_boot_mode"
>   allows the operator to set the default boot mode when ironic can't
>   pick boot mode automatically based on node configuration, hardware
>   capabilities, or bare-metal machine configuration.
> 
> * Adds support to the "redfish" management interface for reading and
>   setting bare metal node's boot mode.
> 
> * Adds new Power Distribution Unit (PDU) "snmp" driver type -
>   BayTech MRP27.
> 
> * Adds new "auto" type of the "driver_info/snmp_driver" setting
>   which makes ironic automatically select a suitable SNMP driver type
>   based on the "SNMPv2-MIB::sysObjectID" value as reported by the PDU
>   being managed.
> 
> * Adds SNMPv3 message authentication and encryption features to
>   ironic "snmp" hardware type. To enable these features, the following
>   parameters should be used in the node's "driver_info":
> 
>   * "snmp_user"
> 
>   * "snmp_auth_protocol"
> 
>   * "snmp_auth_key"
> 
>   * "snmp_priv_protocol"
> 
>   * "snmp_priv_key"
> 
>   Also adds support for the "context_engine_id" and "context_name"
>   parameters of SNMPv3 message at ironic "snmp" hardware type. They
>   can be configured in the node's "driver_info".
> 
> * Add "?detail=" boolean query to the API list endpoints to provide
>   a more RESTful alternative to the existing "/nodes/detail" and
>   similar endpoints. The default is False. Now these API requests are
>   possible:
> 
>   * "/nodes?detail=True"
> 
>   * "/ports?detail=True"
> 
>   * "/chassis?detail=True"
> 
>   * "/portgroups?detail=True"
> 
> * Adds "external" storage interface which is short for "externally
>   managed". This adds logic to allow the Bare Metal service to
>   identify when a BFV scenario is being requested based upon the
>   configuration set for "volume targets".
> 
>   The user must create the entry, and no syncronizaiton with a Block
>   Storage service will occur. Documentation
>   (https://docs.openstack.org/ironic/latest/admin/boot-from-
>   volume.html#use-without-cinder) has been updated to reflect how to
>   use this interface.
> 
> * Adds the "[deploy]enable_ata_secure_erase" option which allows an
>   operator to disable ATA Secure Erase for all nodes being managed by
>   the conductor. This setting defaults to "True" which aligns with the
>   prior behavior of the Bare Metal service.
> 
> * Adds new parameter fields to driver_info, which will become
>   mandatory in Stein release:
> 
>   * "xclarity_manager_ip": IP address of the XClarity Controller.
> 
>   * "xclarity_username": Username for the XClarity 

Re: [openstack-dev] [tc] Technical Committee Update for 3 July

[Doug Hellmann]

Excerpts from Chris Dent's message of 2018-07-03 19:31:43 +0100:
> On Tue, 3 Jul 2018, Doug Hellmann wrote:
> 
> > Chris and Thierry have been discussing a technical vision for OpenStack.
> >
> > * https://etherpad.openstack.org/p/tech-vision-2018
> 
> Just so it's clear and credit where credit (or blame!) is due: Zane
> has been a leading part of this too.
> 

Thanks, Chris.

Zane, I apologize for the oversight.

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] [tc] Technical Committee Update for 3 July

[Doug Hellmann]

This is the weekly summary of work being done by the Technical
Committee members. The full list of active items is managed in the
wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Approved changes:

* add a note about tracking cycle goals after a cycle ends:
  https://review.openstack.org/#/c/577149/

Office hour logs from last week:

* http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-27-01.00.html
* http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-28-15.00.html
* http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-07-03-09.01.html

In the absence of any feedback about using the meeting bot to record the
office hours, we will continue to do so, for now.

== Ongoing Discussions ==

The Adjutant team application is still under discussion.

* https://review.openstack.org/553643 project team application

Discussions about affiliation diversity continue in two directions.
Zane's proposal for requirements for new project teams has stalled a
bit. The work Thierry and Mohammed have done on the diversity tags has
brought a new statistics script and a proposal to drop the use of the
tags in favor of folding the diversity information into the more general
health checks we are doing. Thierry has updated the health tracker page
with information about all of the teams based on the most recent run of
the scripts.

* Zane's proposal for requirements for new projects:
* https://review.openstack.org/#/c/567944/
* Thierry's proposal to drop the tags:
* https://review.openstack.org/#/c/579870/
* Team "fragility" scripts: https://review.openstack.org/#/c/579142/

Thierry proposed changes to the Project Team Guide to include a
technical guidance section.

* https://review.openstack.org/#/c/578070/1

Chris and Thierry have been discussing a technical vision for OpenStack.

* https://etherpad.openstack.org/p/tech-vision-2018
* 
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-06-26.log.html#t2018-06-26T09:09:57

== TC member actions/focus/discussions for the coming week(s) ==

Please vote on the Adjutant team application.
https://review.openstack.org/553643

Project team "health check" interviews continue. Our goal is to check in
with each team between now and the PTG, and record notes in the wiki.

* https://wiki.openstack.org/wiki/OpenStack_health_tracker

Remember that we agreed to send status updates on initiatives separately
to openstack-dev every two weeks. If you are working on something for
which there has not been an update in a couple of weeks, please consider
summarizing the status.

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

* 09:00 UTC on Tuesdays
* 01:00 UTC on Wednesdays
* 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad
at:https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string "tc-members" to alert the members to your question.

If you expect your topic to require significant discussion or to
need input from members of the community other than the TC, please
start a mailing list discussion on openstack-dev at lists.openstack.org
and use the subject tag "[tc]" to bring it to the attention of TC
members.


__
OpenStack Development Mailing 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] autodoc and tox-siblings

[Doug Hellmann]

Excerpts from Takashi Yamamoto's message of 2018-07-03 13:12:53 +0900:
> hi,
> 
> - networking-midonet uses autodoc in their doc.
> build-openstack-sphinx-docs runs it.
> - build-openstack-sphinx-docs doesn't use tox-siblings. thus the job
> uses released versions of dependencies. eg. neutron, neutron-XXXaas,
> os-vif, etc
> - released versions of dependencies and networking-midonet master are
> not necessarily compatible
> - a consequence: https://bugs.launchpad.net/networking-midonet/+bug/1779801
>   (in this case, neutron-lib and neutron are not compatible)
> 
> possible solutions i can think of:
> - stop using autodoc (i suspect i have to do this for now)
> - make intermediate releases of neutron and friends
> - finish neutron-lib work and stop importing neutron etc (ideal but we
> have not reached this stage yet)
> - make doc job use tox-siblings (as it used to do in tox_install era)
> 
> any suggestions?
> 

As part of the python3-first goal planning we determined that our
current PTI defines the API between zuul and our jobs at the wrong
level, and that is going to make it more difficult for us to support
different versions of python on different branches.

I plan to write up a governance change ASAP to have the PTI expect
to call "tox -e docs" to build the documentation and then define a
new job that works that way. It sounds like that change will also
help in the case you have, since the new job will be able to support
tox-siblings.

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] [sqlalchemy][db][oslo.db][mistral] Is there a recommended MySQL driver for OpenStack projects?

[Doug Hellmann]

Excerpts from Renat Akhmerov's message of 2018-07-03 18:33:44 +0700:
> Hi,
> 

> We’ve tried to address the bug [1] which is essentially caused
> by the fact that we saw that MySQLDb driver wasn’t compatible with
> eventlet’s green threads. In a nutshell, when we used the “eventlet”
> RPC executor (see [2]), the system would get stuck once in a while
> when dispatching green between green threads when it tried to hit
> Mysql, but since the driver wasn’t eventlet friendly it didn’t work.
> For that reason we had to use the “blocking” RPC executor so far
> for Mistral Engine that deals with DB transactions.

If you have a scaling issue that may be solved by eventlet, that's
one thing, but please don't adopt eventlet just because a lot of
other projects have.  We've tried several times to minimize our
reliance on eventlet because new releases tend to introduce bugs.

Have you tried the 'threading' executor?

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] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2018-06-28 17:05:09 +0200:
> On 06/27/2018 03:17 AM, Ghanshyam Mann wrote:
> > Users (Not Gate) will face below issues:
> > - User cannot use PluginNR with Tempest <19.0.0 (where that new interface 
> > was not present). And there is no PluginNR release/tag as this is 
> > unreleased and not branched software.
> > - User cannot find a PluginIR particular tag/release which can work with 
> > tempest <19.0.0 (where that new interface was not present). Only way for 
> > user to make it work is to manually find out the PluginIR tag/commit before 
> > PluginIR started consuming the new interface.
> 
> In these discussions I always think: how is it solved outside of the 
> openstack 
> world. And the solutions seem to be:
> 1. for PluginNR - do releases
> 2. for PluginIR - declare their minimum version of tempest in requirements.txt
> 
> Why isn't it sufficient for us?

It is. We just haven't been doing it; in part I think because most
developers interact with the plugins via the CI system and don't realize
they are also "libraries" that need to be released so that refstack
users can install them.

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][stable][docs] updating openstackdocstheme in stable branches

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2018-06-27 12:42:47 +1000:
> On Tue, Jun 26, 2018 at 09:03:40AM -0400, Doug Hellmann wrote:
> > Requirements team,
> > 
> > At some point in the next few months we're going to want to raise
> > the constraint on openstackdocstheme in all of the old branches so
> > we can take advantage of a new feature for showing the supported
> > status of each version of a project. That feature isn't implemented
> > yet, but I thought it would be good to discuss in advance the need
> > to update the dependency and how to do it.
> > 
> > The theme is released under an independent release model and does
> > not currently have stable branches.  It depends on pbr and dulwich,
> > both of which should already be in the requirements and constraints
> > lists (dulwich is a dependency of reno).
> 
> The only possible gottcha is if openstackdocstheme relies on a feature
> in any of pbr or dulwich which isn't in the version currently in
> upper-constratints.txt.  If that happens we can easily bump those
> constraints also.

Good point. I don't expect either to be the case, but I'll verify that
before going ahead.

> > I think that means the simplest thing to do would be to just update
> > the constraint for the theme in the stable branches. Does that seem
> > right?
> 
> Yup that seems to be all there is to it.  Once the release happens the
> bot will propose the constraints bump on master which someone will need
> to cherry-pick onto the stable branches.

I'm sure we can find someone from the documentation team to do that.

Thanks!
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] [python3] building tools for the transition

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-06-20 11:34:10 -0400:
> I want to thank Nguyễn Trí Hải, Ma Lei, and Huang Zhiping for
> agreeing to be a part of the goal champion team for the python3
> goal for Stein.
> 
> The next step for us is to build some tools to make the process a
> little easier.
> 
> One of the aspects of this goal that makes it difficult is that we
> need to change so many repositories. There are more than 480
> repositories associated with official project teams. I do not think
> we want to edit their zuul configurations by hand. :-)
> 
> It would be ideal if we had a script that could read the
> openstack-infra/project-config/zuul.d/projects.yaml file to find
> the project settings for a repository and copy those settings into
> the right settings file within the repository. We could then review
> the patch locally before proposing the change to gerrit.  A second
> script to remove the settings from the project-config file, and
> then submit that second change as a patch that has a Depends-On
> listed for the first patch would also be useful.
> 
> Another aspect that makes it difficult is that zuul is very flexible
> with how it reads its configuration files. The configuration can
> be in .zuul.yaml, zuul.yaml, .zuul.d/*.yaml, or zuul.d/*.yaml.
> Projects have not been consistent with the way they have named their
> files, and that will make writing a script to automate editing them
> more difficult. For example, I found automaton/.zuul.yaml,
> rally/zuul.yaml, oslo.config/.zuul.d, and python-ironicclient/zuul.d.
> 
> When I was working on adding the lower-constraints jobs, I created some
> tools in https://github.com/dhellmann/openstack-requirements-stop-sync
> to help create the patches, and we may be able to reuse some of that
> code to make similar changes for this goal.
> https://github.com/dhellmann/openstack-requirements-stop-sync/blob/master/make_patches.sh
> is the script that makes the patches, and
> https://github.com/dhellmann/openstack-requirements-stop-sync/blob/master/add_job.py
> is the python script that edits the YAML file.
> 
> The task for this goal is a little more complicated, since we are
> not just adding 1 template to the existing project settings.  We
> may have to add several templates and jobs to the existing settings,
> merging the two sets together, and removing branch specifiers at
> the same time. And we may need to do that in several branches.
> 
> Would a couple of you have time to work on the script to prepare
> the patches? We can work in the openstack/goal-tools repository so
> that we can collaborate on the code in an official OpenStack
> repository (instead of using my GitHub project).
> 
> Doug

I started working on these tools today. Given the complexity, for now
the two commands only print the expected settings. The 'jobs extract'
command shows which job settings should be copied from project-config to
the zuul settings in a given branch of a repository, and 'jobs retain'
shows which jobs settings should remain in place.

Please look over the changeset
(https://review.openstack.org/#/c/578194/) and leave review comments if
you have them.

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] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-06-26 11:19:05 -0400:

> 29 out of 40 repos that have "tempest" in the name have not been
> tagged via the releases repo. Not all of those are plugins. Here's
> a list:
> 
> $ for repo in $(grep openstack/ reference/projects.yaml | grep tempest |
> cut -f2- -d- | cut -f2 -d' ') ; do (echo -n $repo; cd ../releases/; if
> grep -q $repo deliverables/*/*.yaml ; then echo ' FOUND'; else
> echo ' NOT FOUND'; fi); done
> 
> openstack/barbican-tempest-plugin NOT FOUND
> openstack/blazar-tempest-plugin NOT FOUND
> openstack/cinder-tempest-plugin NOT FOUND
> openstack/cloudkitty-tempest-plugin NOT FOUND
> openstack/congress-tempest-plugin NOT FOUND
> openstack/designate-tempest-plugin FOUND
> openstack/ec2api-tempest-plugin NOT FOUND
> openstack/freezer-tempest-plugin NOT FOUND
> openstack/heat-tempest-plugin NOT FOUND
> openstack/tempest-horizon NOT FOUND
> openstack/ironic-tempest-plugin FOUND
> openstack/networking-generic-switch-tempest-plugin NOT FOUND
> openstack/keystone-tempest-plugin NOT FOUND
> openstack/kuryr-tempest-plugin FOUND
> openstack/magnum-tempest-plugin NOT FOUND
> openstack/manila-tempest-plugin NOT FOUND
> openstack/mistral-tempest-plugin NOT FOUND
> openstack/monasca-tempest-plugin FOUND
> openstack/murano-tempest-plugin NOT FOUND
> openstack/neutron-tempest-plugin NOT FOUND
> openstack/octavia-tempest-plugin NOT FOUND
> openstack/charm-tempest NOT FOUND
> openstack/openstack-ansible-os_tempest FOUND
> openstack/puppet-tempest FOUND
> openstack/tempest FOUND
> openstack/tempest-plugin-cookiecutter NOT FOUND
> openstack/tempest-lib NOT FOUND
> openstack/tempest-stress NOT FOUND
> openstack/python-tempestconf FOUND
> openstack/senlin-tempest-plugin NOT FOUND
> openstack/solum-tempest-plugin NOT FOUND
> openstack/telemetry-tempest-plugin NOT FOUND
> openstack/tempest-tripleo-ui NOT FOUND
> openstack/tripleo-common-tempest-plugin NOT FOUND
> openstack/trove-tempest-plugin NOT FOUND
> openstack/vitrage-tempest-plugin FOUND
> openstack/watcher-tempest-plugin NOT FOUND
> openstack/oswin-tempest-plugin FOUND
> openstack/zaqar-tempest-plugin NOT FOUND
> openstack/zun-tempest-plugin FOUND

I have proposed https://review.openstack.org/578141 to update the
deliverable files for rocky to include the plugins.

I left out openstack/ec2api-tempest-plugin because it doesn't look like
ec2-api has been tagged in quite a while.

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] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Doug Hellmann]

Excerpts from Matthew Treinish's message of 2018-06-26 10:37:54 -0400:
> On Tue, Jun 26, 2018 at 10:12:30AM -0400, Doug Hellmann wrote:
> > Excerpts from Matthew Treinish's message of 2018-06-26 09:52:09 -0400:
> > > On Tue, Jun 26, 2018 at 08:53:21AM -0400, Doug Hellmann wrote:
> > > > Excerpts from Andrea Frittoli's message of 2018-06-26 13:35:11 +0100:
> > > > > On Tue, 26 Jun 2018, 1:08 pm Thierry Carrez,  
> > > > > wrote:
> > > > > 
> > > > > > Dmitry Tantsur wrote:

> > > As for this whole thread I don't understand any of the points being 
> > > brought up
> > > in the original post or any of the follow ons, things seem to have been 
> > > confused
> > > from the start. The ask from users at the summit was simple. When a new 
> > > OpenStack
> > > release is pushed we push a tempest release to mark that (the next one 
> > > will be
> > > 19.0.0 to mark Rocky). Users were complaining that many plugins don't 
> > > have a
> > > corresponding version to mark support for a new release. So when trying 
> > > to run
> > > against a rocky cloud you get tempest 19.0.0 and then a bunch of plugins 
> > > for
> > > various services at different sha1s which have to be manually looked up 
> > > based
> > > on dates. All users wanted at the summit was a tag for plugins like 
> > > tempest
> > > does with the first number in:
> > > 
> > > https://docs.openstack.org/tempest/latest/overview.html#release-versioning
> > > 
> > > which didn't seem like a bad idea to me. I'm not sure the best mechanism 
> > > to
> > > accomplish this, because I agree with much of what plugin maintainers were
> > > saying on the thread about wanting to control their own releases. But the
> > > desire to make sure users have a tag they can pull for the addition or
> > > removal of a supported release makes sense as something a plugin should 
> > > do.
> > 
> > We don't coordinate versions across projects anywhere else, for a
> > bunch of reasons including the complexity of coordinating the details
> > and the confusion it causes when the first version of something is
> > 19.0.0. Instead, we list the compatible versions of everything
> > together on a series-specific page on releases.o.o. That seems to
> > be enough to help anyone wanting to know which versions of tools
> > work together. The data is also available in YAML files, so it's easy
> > enough to consume by automation.
> > 
> > Would that work for tempest and it's plugins, too?
> 
> That is exactly what I had in mind. I wasn't advocating all plugins use the 
> same
> version number for releases, for the same reasons we don't do that for service
> projects anymore. Just that there is a release for a plugin when they add
> support for a new service release so that users can know which version to
> install.
>
> > Is the problem that the versions are not the same, or that some of the
> > plugins are not being tagged at all?
> > 
> 
> While I don't pay attention to all the plugins, the impression I got was that
> it was the latter and some plugins aren't pushing releases at all. Or if they
> are there is no clear version to use for a specific openstack release.

OK, that should be easy enough to work out a solution to. The release
team can remind project teams to tag their tempest plugin(s) when they
prepare their other releases at the end of the cycle, for example.

29 out of 40 repos that have "tempest" in the name have not been
tagged via the releases repo. Not all of those are plugins. Here's
a list:

$ for repo in $(grep openstack/ reference/projects.yaml | grep tempest |
cut -f2- -d- | cut -f2 -d' ') ; do (echo -n $repo; cd ../releases/; if
grep -q $repo deliverables/*/*.yaml ; then echo ' FOUND'; else
echo ' NOT FOUND'; fi); done

openstack/barbican-tempest-plugin NOT FOUND
openstack/blazar-tempest-plugin NOT FOUND
openstack/cinder-tempest-plugin NOT FOUND
openstack/cloudkitty-tempest-plugin NOT FOUND
openstack/congress-tempest-plugin NOT FOUND
openstack/designate-tempest-plugin FOUND
openstack/ec2api-tempest-plugin NOT FOUND
openstack/freezer-tempest-plugin NOT FOUND
openstack/heat-tempest-plugin NOT FOUND
openstack/tempest-horizon NOT FOUND
openstack/ironic-tempest-plugin FOUND
openstack/networking-generic-switch-tempest-plugin NOT FOUND
openstack/keystone-tempest-plugin NOT FOUND
openstack/kuryr-tempest-plugin FOUND
openstack/magnum-tempest-plugin NOT FOUND
openstack/manila-tempest-plugin NOT FOUND
openstack/mistral-tempest-plugin NOT FOUND
openstack/monasca-tempest-plugin FOUND
openstack/murano-tem

Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Doug Hellmann]

Excerpts from Matthew Treinish's message of 2018-06-26 09:52:09 -0400:
> On Tue, Jun 26, 2018 at 08:53:21AM -0400, Doug Hellmann wrote:
> > Excerpts from Andrea Frittoli's message of 2018-06-26 13:35:11 +0100:
> > > On Tue, 26 Jun 2018, 1:08 pm Thierry Carrez,  
> > > wrote:
> > > 
> > > > Dmitry Tantsur wrote:
> > > > > [...]
> > > > > My suggestion: tempest has to be compatible with all supported 
> > > > > releases
> > > > > (of both services and plugins) OR be branched.
> > > > > [...]
> > > > I tend to agree with Dmitry... We have a model for things that need
> > > > release alignment, and that's the cycle-bound series. The reason tempest
> > > > is branchless was because there was no compatibility issue. If the split
> > > > of tempest plugins introduces a potential incompatibility, then I would
> > > > prefer aligning tempest to the existing model rather than introduce a
> > > > parallel tempest-specific cycle just so that tempest can stay
> > > > release-independent...
> > > >
> > > > I seem to remember there were drawbacks in branching tempest, though...
> > > > Can someone with functioning memory brain cells summarize them again ?
> > > >
> > > 
> > > 
> > > Branchless Tempest enforces api stability across branches.
> > 
> > I'm sorry, but I'm having a hard time taking this statement seriously
> > when the current source of tension is that the Tempest API itself
> > is breaking for its plugins.
> > 
> > Maybe rather than talking about how to release compatible things
> > together, we should go back and talk about why Tempest's API is changing
> > in a way that can't be made backwards-compatible. Can you give some more
> > detail about that?
> > 
> 
> Well it's not, if it did that would violate all the stability guarantees
> provided by Tempest's library and plugin interface. I've not ever heard of
> these kind of backwards incompatibilities in those interfaces and we go to
> all effort to make sure we don't break them. Where did the idea that
> backwards incompatible changes where being introduced come from?

In his original post, gmann said, "There might be some changes in
Tempest which might not work with older version of Tempest Plugins."
I was surprised to hear that, but I'm not sure how else to interpret
that statement.

> As for this whole thread I don't understand any of the points being brought up
> in the original post or any of the follow ons, things seem to have been 
> confused
> from the start. The ask from users at the summit was simple. When a new 
> OpenStack
> release is pushed we push a tempest release to mark that (the next one will be
> 19.0.0 to mark Rocky). Users were complaining that many plugins don't have a
> corresponding version to mark support for a new release. So when trying to run
> against a rocky cloud you get tempest 19.0.0 and then a bunch of plugins for
> various services at different sha1s which have to be manually looked up based
> on dates. All users wanted at the summit was a tag for plugins like tempest
> does with the first number in:
> 
> https://docs.openstack.org/tempest/latest/overview.html#release-versioning
> 
> which didn't seem like a bad idea to me. I'm not sure the best mechanism to
> accomplish this, because I agree with much of what plugin maintainers were
> saying on the thread about wanting to control their own releases. But the
> desire to make sure users have a tag they can pull for the addition or
> removal of a supported release makes sense as something a plugin should do.

We don't coordinate versions across projects anywhere else, for a
bunch of reasons including the complexity of coordinating the details
and the confusion it causes when the first version of something is
19.0.0. Instead, we list the compatible versions of everything
together on a series-specific page on releases.o.o. That seems to
be enough to help anyone wanting to know which versions of tools
work together. The data is also available in YAML files, so it's easy
enough to consume by automation.

Would that work for tempest and it's plugins, too?

Is the problem that the versions are not the same, or that some of the
plugins are not being tagged at all?

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][requirements][docs] sphinx update to 1.7.4 from 1.6.5

[Doug Hellmann]

Excerpts from Lance Bragstad's message of 2018-06-25 22:51:37 -0500:
> Thanks a bunch for digging into this, Tony. I'll follow up with the
> oauthlib maintainers and see if they'd be interested in these changes
> upstream. If so, I can chip away at it. For now we'll have to settle for
> not treating warnings as errors to unblock our documentation gate [0].
> 
> [0] https://review.openstack.org/#/c/577974/

How are docstrings from a third-party library making their way into the
keystone docs and breaking the build?

Doug

> 
> On 06/25/2018 07:27 PM, Tony Breeds wrote:
> > On Mon, Jun 25, 2018 at 05:42:00PM -0500, Lance Bragstad wrote:
> >> Keystone is hitting this, too [0]. I attempted the same solution that
> >> Tony posted, but no luck. I've even gone so far as removing every
> >> comment from the module to see if that helps narrow down the problem
> >> area, but sphinx still trips. The output from the error message isn't
> >> very descriptive either. Has anyone else had issues fixing this for
> >> python comments, not just docstrings?
> >>
> >> [0] https://bugs.launchpad.net/keystone/+bug/1778603
> > I did a little digging for the keystone problem and it's due to a
> > missing ':' in 
> > https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/request_validator.py#L819-L820
> >
> > So the correct way to fix this is to correct that in oauthlib, get it
> > released and use that.
> >
> > I hit additional problems in that enabling -W in oauthlib, to pevent
> > this happening in the future, lead me down a rabbit hole I don't really
> > have cycles to dig out of.
> >
> > Here's a dump of where I got to[1].  Clearly it mixes "fixes" with
> > debugging but it isn't too hard to reproduce and someone that knows more
> > Sphinx will be able to understand the errors better than I can.
> >
> >
> > [1] http://paste.openstack.org/show/724271/
> >
> > Yours Tony.
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [requirements][stable][docs] updating openstackdocstheme in stable branches

[Doug Hellmann]

Requirements team,

At some point in the next few months we're going to want to raise
the constraint on openstackdocstheme in all of the old branches so
we can take advantage of a new feature for showing the supported
status of each version of a project. That feature isn't implemented
yet, but I thought it would be good to discuss in advance the need
to update the dependency and how to do it.

The theme is released under an independent release model and does
not currently have stable branches.  It depends on pbr and dulwich,
both of which should already be in the requirements and constraints
lists (dulwich is a dependency of reno).

I think that means the simplest thing to do would be to just update
the constraint for the theme in the stable branches. Does that seem
right?

If we can make that happen before we start the zuul configuration
porting work that we're going to do as part of the python3-first
goal, then we can take advantage of those patches to trigger doc
rebuilds in all of the projects.

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] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Doug Hellmann]

Excerpts from Andrea Frittoli's message of 2018-06-26 13:35:11 +0100:
> On Tue, 26 Jun 2018, 1:08 pm Thierry Carrez,  wrote:
> 
> > Dmitry Tantsur wrote:
> > > [...]
> > > My suggestion: tempest has to be compatible with all supported releases
> > > (of both services and plugins) OR be branched.
> > > [...]
> > I tend to agree with Dmitry... We have a model for things that need
> > release alignment, and that's the cycle-bound series. The reason tempest
> > is branchless was because there was no compatibility issue. If the split
> > of tempest plugins introduces a potential incompatibility, then I would
> > prefer aligning tempest to the existing model rather than introduce a
> > parallel tempest-specific cycle just so that tempest can stay
> > release-independent...
> >
> > I seem to remember there were drawbacks in branching tempest, though...
> > Can someone with functioning memory brain cells summarize them again ?
> >
> 
> 
> Branchless Tempest enforces api stability across branches.

I'm sorry, but I'm having a hard time taking this statement seriously
when the current source of tension is that the Tempest API itself
is breaking for its plugins.

Maybe rather than talking about how to release compatible things
together, we should go back and talk about why Tempest's API is changing
in a way that can't be made backwards-compatible. Can you give some more
detail about that?

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] [Openstack-sigs] [PTG] Updates!

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-06-25 16:01:11 +:
> On 2018-06-25 11:26:29 -0400 (-0400), Doug Hellmann wrote:
> > Excerpts from Thierry Carrez's message of 2018-06-25 17:15:44 +0200:
> > > Doug Hellmann wrote:
> > > > Are we planning to have space for goal teams to answer
> > > > implementation questions?
> > > 
> > > At previous PTGs the "goal rooms" ended up not being used (or very very 
> > > poorly-attended), so our current plan was to not allocate specific 
> > > space, but leverage the "Ask me anything" project help room to answer 
> > > those questions as well. It shall be a large room, so plenty of space to 
> > > do that... and probably nicer compared to waiting in a smaller, 
> > > dedicated but mostly empty room.
> > > 
> > > That said, if we have people signed up to run a specific room, and 
> > > people interested in joining that, I'm happy allocating space on Monday 
> > > or Tuesday for that...
> > > 
> > > Otherwise there is always the option to schedule in reservable space 
> > > using ptgbot on the fly :)
> > > 
> > 
> > OK. Given the complexity of the zuul configuration changes for the
> > python3 goal, I anticipated some questions. I will be prepared to
> > talk to people about it regardless, and maybe we won't need a
> > separate room.
> 
> I think the up side to the current plan is that there are likely to
> also be Zuulies in that same room answering Zuulish sorts of
> questions anyway, so easier to get input on goal-specific topics
> where there is such an overlap.

OK, that makes a lot of sense. I didn't see anything on the list
here that looked like an "ask me anything" room but maybe I missed
it or this list was just project teams? Either way, as long as we have
some space, it's fine.

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][requirements] we need to talk about eventlet

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2018-06-25 10:19:50 -0500:
> On 18-06-25 10:58:26, Doug Hellmann wrote:
> > Excerpts from Matthew Thode's message of 2018-06-25 09:38:28 -0500:
> > > On 18-06-25 08:59:23, Doug Hellmann wrote:
> > > > Excerpts from Matthew Thode's message of 2018-06-24 02:42:23 -0500:
> > > > > The short of it is that we are currently using eventlet 0.20.0.  The 
> > > > > bot
> > > > > proposes 0.22.1 which fails updates, I think we need to start bugging
> > > > > projects that fail the cross test jobs.  What do you think?
> > > > > 
> > > > 
> > > > By "bugging" do you mean we should file bugs, or something else?
> > > > 
> > > 
> > > Yes, to start, it'd look something like this.
> > > 
> > > https://bugs.launchpad.net/openstack-requirements/+bug/1749574
> > 
> > OK, tracking issues like that will work. You might also need a
> > storyboard story for projects that have already migrated.
> > 
> 
> Ya, I'm not sure what to do there.  Requirements hasn't migrated because
> other projects haven't migrated (we really need to be on both systems
> unfortunately).  Is it possible to half migrate?
> 

That's a question for the SB team, although I'm not sure I see why it's
needed. If you're going to have a story and a LP bug, couldn't you just
link to one from the other to avoid having to tag the requirements repo
twice?

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] [Openstack-sigs] [PTG] Updates!

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2018-06-25 17:15:44 +0200:
> Doug Hellmann wrote:
> > Are we planning to have space for goal teams to answer
> > implementation questions?
> 
> At previous PTGs the "goal rooms" ended up not being used (or very very 
> poorly-attended), so our current plan was to not allocate specific 
> space, but leverage the "Ask me anything" project help room to answer 
> those questions as well. It shall be a large room, so plenty of space to 
> do that... and probably nicer compared to waiting in a smaller, 
> dedicated but mostly empty room.
> 
> That said, if we have people signed up to run a specific room, and 
> people interested in joining that, I'm happy allocating space on Monday 
> or Tuesday for that...
> 
> Otherwise there is always the option to schedule in reservable space 
> using ptgbot on the fly :)
> 

OK. Given the complexity of the zuul configuration changes for the
python3 goal, I anticipated some questions. I will be prepared to
talk to people about it regardless, and maybe we won't need a
separate room.

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] [oslo][python3] testing the python3-first goal steps with oslo libraries

[Doug Hellmann]

We have already started some of the work to move Oslo to python3-first,
and I would like to work through the remaining steps as a way of testing
the goal documentation. Please take a look at the documentation [1] and
let me know if you have any concerns or questions about us doing that.

Thanks,
Doug

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

__
OpenStack Development Mailing 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][requirements] we need to talk about eventlet

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2018-06-25 09:38:28 -0500:
> On 18-06-25 08:59:23, Doug Hellmann wrote:
> > Excerpts from Matthew Thode's message of 2018-06-24 02:42:23 -0500:
> > > The short of it is that we are currently using eventlet 0.20.0.  The bot
> > > proposes 0.22.1 which fails updates, I think we need to start bugging
> > > projects that fail the cross test jobs.  What do you think?
> > > 
> > 
> > By "bugging" do you mean we should file bugs, or something else?
> > 
> 
> Yes, to start, it'd look something like this.
> 
> https://bugs.launchpad.net/openstack-requirements/+bug/1749574

OK, tracking issues like that will work. You might also need a
storyboard story for projects that have already migrated.

> 
> > Which version of eventlet is actually being used in the various
> > distros?
> > 
> 
> For Gentoo it's 0.20.1 right now, but that's mainly because I haven't
> updated it myself (because Openstack).
> 

__
OpenStack Development Mailing 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] Technical Committee update for 25 June

[Doug Hellmann]

This is the weekly summary of work being done by the Technical
Committee members. The full list of active items is managed in the
wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Other approved changes:

* add champion section to goal template https://review.openstack.org/575934
* a "castellan-compatible key store" is now part of the base services
  list
  
https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services

Office hour logs from last week:

* http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-19-09.00.html
* http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-20-01.09.html
* http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-21-15.00.html

A few folks expressed concern that using the meeting bot to record the
office hours made them more like a meeting. It would be useful to have
some feedback from the community about whether having the logs separate
is helfpul, or if linking to the timestamp in the regular channel logs
would be sufficient.


== Ongoing Discussions ==

The Adjutant team application was updated.

* https://review.openstack.org/553643

Thierry started drafting a "technical design tenets" chapter for the
project team guide as a place to explain topics like base services and
other things we expect to be common development patterns in the
community.

* https://storyboard.openstack.org/#!/story/2002611

== TC member actions/focus/discussions for the coming week(s) ==

Project team "health check" interviews continue. Our goal is to check in
with each team between now and the PTG, and record notes in the wiki.

* https://wiki.openstack.org/wiki/OpenStack_health_tracker

Remember that we agreed to send status updates on initiatives separately
to openstack-dev every two weeks. If you are working on something for
which there has not been an update in a couple of weeks, please consider
summarizing the status.

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

* 09:00 UTC on Tuesdays
* 01:00 UTC on Wednesdays
* 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad
at:https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string "tc-members" to alert the members to your question.

If you expect your topic to require significant discussion or to
need input from members of the community other than the TC, please
start a mailing list discussion on openstack-dev at lists.openstack.org
and use the subject tag "[tc]" to bring it to the attention of TC
members.


__
OpenStack Development Mailing 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] [PTG] Updates!

[Doug Hellmann]

Are we planning to have space for goal teams to answer
implementation questions?

Doug

Excerpts from Kendall Nelson's message of 2018-06-20 11:24:38 -0700:
> Hello Everyone!
> 
> Wanted to give you some updates on PTG4 planning. We have finalized the
> list of SIGs/ Groups/WGs/Teams that are attending. They are as follows:
> 
>-
> 
>Airship
>-
> 
>API SIG
>-
> 
>Barbican/Security SIG
>-
> 
>Blazar
>-
> 
>Chef OpenStack
>-
> 
>Cinder
>-
> 
>Cyborg
>-
> 
>Designate
>-
> 
>Documentation
>-
> 
>Edge Computing Group
>-
> 
>First Contact SIG
>-
> 
>Glance
>-
> 
>Heat
>-
> 
>Horizon
>-
> 
>Infrastructure
>-
> 
>Interop WG
> 
> 
>-
> 
>Ironic
>-
> 
>Kata
>-
> 
>Keystone
>-
> 
>Kolla
>-
> 
>LOCI
>-
> 
>Manila
>-
> 
>Masakari
>-
> 
>Mistral
>-
> 
>Monasca
>-
> 
>Neutron
>-
> 
>Nova
>-
> 
>Octavia
>-
> 
>OpenStack Ansible
>-
> 
>OpenStack Charms
>-
> 
>OpenStack Helm
>-
> 
>OpenStackClient
> 
> 
> 
>-
> 
>Operator Meetup
>Puppet OpenStack
>-
> 
>QA
>-
> 
>Oslo
>-
> 
>Public Cloud WG
>-
> 
>Release Management
>-
> 
>Requirements
>-
> 
>Sahara
>-
> 
>Scientific SIG
>-
> 
>Self-Healing SIG
>-
> 
>SIG- K8s
>-
> 
>StarlingX
>-
> 
>Swift
>-
> 
>TC
>-
> 
>TripleO
>-
> 
>Upgrades SIG
>-
> 
>Watcher
>-
> 
>Zuul (pending confirmation)
> 
> Thierry and I are working on placing them into a strawman schedule to
> reduce conflicts between related or overlapping groups. We should have more
> on what that will look like and a draft for you all to review in the next
> few weeks.
> 
> We also wanted to remind you all of the Travel Support Program. We are
> again doing a two phase selection. The first deadline is approaching: July
> 1st. At this point we have less than a dozen applicants so if you need it
> or even think you need it, I urge you to apply here[1].
> 
> Also! Reminder that we have a finite number of rooms in the hotel block so
> please book early to make sure you get the discounted rate before they run
> out. You can book those rooms here[2] (pardon the ugly URL).
> 
> Can't wait to see you all there!
> 
> -Kendall Nelson (diablo_rojo)
> 
> P.S. Gonna try to do a game night again since you all seemed to enjoy it so
> much last time :)
> 
> [1]
> https://openstackfoundation.formstack.com/forms/travelsupportptg_denver_2018
> 
> [2]
> https://www.marriott.com/meeting-event-hotels/group-corporate-travel/groupCorp.mi?resLinkData=Project%20Teams%20Gathering%2C%20Openstack%5Edensa%60opnopna%7Copnopnb%60149.00%60USD%60false%604%609/5/18%609/18/18%608/20/18=resvlink_mobi=yes

__
OpenStack Development Mailing 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][requirements] we need to talk about eventlet

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2018-06-24 02:42:23 -0500:
> The short of it is that we are currently using eventlet 0.20.0.  The bot
> proposes 0.22.1 which fails updates, I think we need to start bugging
> projects that fail the cross test jobs.  What do you think?
> 

By "bugging" do you mean we should file bugs, or something else?

Which version of eventlet is actually being used in the various
distros?

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][horizon] Release of openstack/xstatic-angular-material failed

[Doug Hellmann]

Excerpts from zuul's message of 2018-06-25 12:14:34 +:
> Build failed.
> 
> - xstatic-check-version 
> http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/
>  : FAILURE in 1m 31s
> - release-openstack-python release-openstack-python : SKIPPED
> - announce-release announce-release : SKIPPED
> - propose-update-constraints propose-update-constraints : SKIPPED
> 

"git tag version (1.1.5.1) does not match package version (1.1.5.0)"

http://logs.openstack.org/59/592a9d4c90f37cd33c6f861120f41ac8a67d909b/release/xstatic-check-version/a501dba/job-output.txt.gz#_2018-06-25_12_14_11_034599

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

Re: [openstack-dev] [heat] Need new release of heat-translator library

[Doug Hellmann]

Excerpts from Tung Doan's message of 2018-06-21 00:35:38 +0200:
>  I agree with Bobh. Considering both Heat Translator and Tosca Parser under
> the management of Tacker could affect other projects. We have recently
> announced OpenStack Apmec [1] (MEC Orchestration Service) which
> consumed these two projects as well.
> In case Heat PTL does not have enough bandwidth to take care of the release
> of these two projects. I just wonder whether it is reasonable to release
> them when having only the approval of their PTL.
> 
> [1] https://github.com/openstack/apmec/tree/master/apmec

According to
https://governance.openstack.org/tc/reference/projects/heat.html the
Heat PTL *is* the PTL for heat-translators. Any internal team structure
that implies otherwise is just that, an internal team structure.

I'm really unclear on what the problem is here. The PTL requested a
release; it looked fine; I approved it; it was completed.

The release team tries to facilitate releases happening as quickly
as possible so we don't block work anyone else is trying to do.
There was no apparent reason to wait for this one.  If the teams
using heat-translator want to coordinate on when releases happen
for some reason, then please deal with that before requesting the
releases (and use a W-1 on the patch if you want us to hold off
until you get approval).  The release team has said we do not want
to have to keep up with separate liaisons for individual deliverables
because it's too much to for us to track.

In the mean time, releases are cheap and we can have as many of
them as we want, so if there are additional features in the pipeline
that will be ready to be released soon we can just do that when
they merge.

And if changes are going into heat-translator that might break
consuming projects, we should deal with that the way we do in other
libraries and set up cross-project gating to try to catch the
problems ahead of time. (Maybe that testing is already in place?)
We can also use the constraint system to block "bad" releases if
they do happen. But it's generally better for us to be releasing
libraries and tools as often as possible, so that any breaking
changes come as part of a small set and so new features are available
shortly after they are implemented.

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] [heat] Need new release of heat-translator library

[Doug Hellmann]

Excerpts from Zane Bitter's message of 2018-06-20 12:07:49 -0400:
> On 20/06/18 11:40, Rico Lin wrote:
> > I send a release patch now https://review.openstack.org/#/c/576895/
> > Also, add Bob Haddleton to this ML who is considering as PTL for 
> > heat-translator team
> 
> Is it time to consider moving the heat-translator and tosca-parser repos 
> from being deliverables of Heat to deliverables of Tacker? The current 
> weird structure dates from the days of the experiment with OpenStack 
> 'Programs' (vs. Projects).
> 
> Heat cores don't really have time to be engaging with heat-translator, 
> and Tacker is clearly the major user and the thing that keeps getting 
> blocked on needing patches merged and releases made.

It sounds like it. I had no idea there was any reason to look to anyone
other than the Heat PTL or liaison for approval of that release. A WIP
on the patch would have been OK, too, but if the Tacker team is really
the one responsible we should update the repo governance.

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] [oslo][osc][cliff][tacker] New release of cmd2 break cliff and tacker client

[Doug Hellmann]

Excerpts from super user's message of 2018-06-20 15:49:25 +0900:
> Hi everyone,
> 
> New release of cmd2 0.9.0 seems to break cliff and python-tackerclient.
> 
> The cmd2 library changed the way it handles parsing input commands. It now
> uses a different library, which means the values passed to the commands are
> no longer PyParsing objects and are instead Statement objects. These
> objects do not have a “parsed” property, so the receiving code needs to
> work with them differently.
> 
> The patch https://review.openstack.org/571524 tries to fix this in the
> places within cliff where it was failing in interactive mode.
> 
> Please consider reviewing this patch and have a new release for cliff so
> that the python-tackerclient pass the py35 tests.
> 
> Thank you,
> Nguyen Hai

That patch is now merged and I have requested a release of cliff
(https://review.openstack.org/576897).

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