Re: [openstack-dev] [all][oslo] Retiring openstack/pylockfile

[Doug Hellmann]

Excerpts from ChangBo Guo's message of 2017-09-30 11:07:33 +0800:
> pylockfile was  deprecated  about two years ago in [1] and it is not used
> in any OpenStack Projects now [2] , we would like to retire it according
> to steps of retiring a project[3].
> 
> 
> [1]c8798cedfbc4d738c99977a07cde2de54687ac6c#diff-88b99bb28683bd5b7e3a204826ead112
> [2] http://codesearch.openstack.org/?q=pylockfile=nope==
> [3]https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project

+1

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

Re: [openstack-dev] [tc][docs][release] Updating the PTI for docs and tarballs

[Doug Hellmann]

Excerpts from Monty Taylor's message of 2017-09-30 10:20:08 -0500:
> Hey everybody,
> 
> Oh goodie, I can hear you say, let's definitely spend some time 
> bikeshedding about specific command invocations related to building docs 
> and tarballs!!!
> 
> tl;dr I want to change the PTI for docs and tarball building to be less 
> OpenStack-specific
> 
> The Problem
> ===
> 
> As we work on Zuul v3, there are a set of job definitions that are 
> rather fundamental that can totally be directly shared between Zuul 
> installations whether those Zuuls are working with OpenStack content or 
> not. As an example "tox -epy27" is a fairly standard thing, so a Zuul 
> job called "tox-py27" has no qualities specific to OpenStack and could 
> realistically be used by anyone who uses tox to manage their project.
> 
> Docs and Tarballs builds for us, however, are the following:
> 
> tox -evenv -- python setup.py sdist
> tox -evenv -- python setup.py build_sphinx
> 
> Neither of those are things that are likely to work outside of 
> OpenStack. (The 'venv' tox environment is not a default tox thing)
> 
> I'm going to argue neither of them are actually providing us with much 
> value.
> 
> Tarball Creation
> 
> 
> Tarball creation is super simple. setup_requires is already handled out 
> of band of everything else. Go clone nova into a completely empty system 
> and run python setup.py sdist ... and it works. (actually, nova is big. 
> use something smaller like gertty ...)
> 
> docker run -it --rm python bash -c 'git clone \
>   https://git.openstack.org/openstack/gertty && cd gertty \
>   && python setup.py sdist'
> 
> There is not much value in that tox wrapper - and it's not like it's 
> making it EASIER to run the command. In fact, it's more typing.
> 
> I propose we change the PTI from:
> 
>tox -evenv python setup.py sdist
> 
> to:
> 
>python setup.py sdist
> 
> and then change the gate jobs to use the non-tox form of the command.
> 
> I'd also like to further change it to be explicit that we also build 
> wheels. So the ACTUAL commands that the project should support are:
> 
>python setup.py sdist
>python setup.py bdist_wheel
> 
> All of our projects support this already, so this should be a no-op.
> 
> Notes:
> 
> * Python projects that need to build C extensions might need their pip 
> requirements (and bindep requirements) installed in order to run 
> bdist_wheel. We do not support that broadly at the moment ANYWAY - so 
> I'd like to leave that as an outlier and handle it when we need to 
> handle it.
> 
> * It's *possible* that somewhere we have a repo that has somehow done 
> something that would cause python setup.py sdist or python setup.py 
> bdist_wheel to not work without pip requirements installed. I believe we 
> should consider that a bug and fix it in the project if we find such a 
> thing - but since we use pbr in all of the OpenStack projects, I find it 
> extremely unlikely.
> 
> Governance patch submitted: https://review.openstack.org/508693
> 
> Sphinx Documentation
> 
> 
> Doc builds are more complex - but I think there is a high amount of 
> value in changing how we invoke them for a few reasons.
> 
> a) nobody uses 'tox -evenv -- python setup.py build_sphinx' but us
> b) we decided to use sphinx for go and javascript - but we invoke sphinx 
> differently for each of those (since they naturally don't have tox), 
> meaning we can't just have a "build-sphinx-docs" job and even share it 
> with ourselves.
> c) readthedocs.org is an excellent Open Source site that builds and 
> hosts sphinx docs for projects. They have an interface for docs 
> requirements documented and defined that we can align. By aligning, 
> projects can use migrate between docs.o.o and readthedocs.org and still 
> have a consistent experience.
> 
> The PTI I'd like to propose for this is more complex, so I'd like to 
> describe it in terms of:
> 
> - OpenStack organizational requirements
> - helper sugar for developers with per-language recommendations
> 
> I believe the result can be a single in-tree doc PTI that applies to 
> python, go and javascript - and a single Zuul job that applies to all of 
> our projects AND non-OpenStack projects as well.
> 
> Organizational Requirements
> ---
> 
> Following readthedocs.org logic we can actually support a wider range of 
> schemes technically, but there is human value in having consistency on 
> these topics across our OpenStack repos.
> 
> * docs live in doc/source
> * Python requirements needed by Sphinx to build the docs live in 
> doc/requirements.txt
> 
> If the project is python:
> 
> * doc/requirements.txt can assume the project will have been installed
> * The following should be set in setup.cfg:
> 
>[build_sphinx]
>source-dir = doc/source
>build-dir = doc/build
> 
> Doing the above allows the following commands to work cleanly in 
> automation no matter what the 

Re: [openstack-dev] [docs][ptls][install] Install guide vs. tutorial

[Doug Hellmann]

Excerpts from Petr Kovar's message of 2017-09-29 21:09:02 +0200:
> On Tue, 26 Sep 2017 18:53:04 -0500
> Jay S Bryant  wrote:
> 
> > 
> > 
> > On 9/25/2017 3:47 AM, Alexandra Settle wrote:
> > >   
> > >  > I completely agree consistency is more important, than bike 
> > > shedding over the
> > >  > name :)
> > >  > To be honest, it would be easier to change everything to ‘guide’ – 
> > > seeing as
> > >  > all our URLs are ‘install-guide’.
> > >  > But that’s the lazy in me speaking.
> > >  >
> > >  > Industry wise – there does seem to be more of a trend towards 
> > > ‘guide’ rather
> > >  > than ‘tutorial’. Although, that is at a cursory glance.
> > >  >
> > >  > I am happy to investigate further, if this matter is of some 
> > > contention to
> > >  > people?
> > >  
> > >  This is the first time I'm hearing about "Install Tutorial". I'm 
> > > also lazy, +1
> > >  with sticking to install guide.
> > >  
> > > Just to clarify: https://docs.openstack.org/install-guide/ The link is 
> > > “install-guide” but the actual title on the page is “OpenStack 
> > > Installation Tutorial”.
> > >
> > > Apologies if I haven’t been clear enough in this thread! Context always 
> > > helps :P
> > >
> > Oy!  The URL says guide but the page says tutorial?  That is even more 
> > confusing.  I think it would be good to make it consistent and just with 
> > guide then.  All for your laziness when it leads to consistency.  :-)
> 
> Yes, this inconsistency in document naming is totally something we need
> to change, hopefully based on the outcome of this discussion.
> 
> At the PTG, I was leaning towards "tutorial" because previously, the docs
> team chose that term to distinguish an installation HOWTO (describing
> installing a PoC environment from packages) from a more general guide on
> installation (possibly documenting different methods that different
> audiences can use).
> 
> But I could go with both.
> 
> Cheers,
> pk
> 

Everyone seems rather flexible on this, so I think we just need someone
to pick a name.

Using "tutorial" will involve renaming the directory containing all of
the content and updating the way that is published in openstack-manuals.

Using "guide" will involve changing the contents of the documents
inside a few files in openstack-manuals to match where it is already
published, and we can do that with sed.

My vote is to do the simple thing, and change the file contents:
https://review.openstack.org/508608

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][oslo.policy][glance] Bug: Glance doesn't send correctly authorization request to Oslo policy

[Doug Hellmann]

The Glance team has weekly meetings just like the Oslo team. You’ll find the 
details about the time and agenda on eavesdrop.openstack.org 
<http://eavesdrop.openstack.org/>. I think it would make sense to add an item 
to the agenda for their next meeting to discuss this issue, and ask for someone 
to help guide you in fixing it. If the Oslo team needs to get involved after 
there is someone from Glance helping, then we can find the right person.

Brian Rosmaita (rosmaita on IRC) is the Glance team PTL. I’ve copied him on 
this email to make sure he notices this thread.

Doug

> On Sep 29, 2017, at 11:24 AM, ruan...@orange.com wrote:
> 
> Not yet, we are not familiar with the Glance team.
> Ruan
> 
> -Original Message-----
> From: Doug Hellmann [mailto:d...@doughellmann.com] 
> Sent: vendredi 29 septembre 2017 16:26
> To: openstack-dev
> Subject: Re: [openstack-dev] [Oslo][oslo.policy][glance] Bug: Glance doesn't 
> send correctly authorization request to Oslo policy
> 
> Excerpts from ruan.he's message of 2017-09-29 12:56:12 +:
>> Hi folks,
>> We are testing the http_check function in Oslo policy, and we figure out a 
>> bug: https://bugs.launchpad.net/glance/+bug/1720354.
>> We believe that this is due to the Glance part since it doesn't well prepare 
>> the authorization request (body) to Oslo policy.
>> Can we put this topic for the next Oslo meeting?
>> Thanks,
>> Ruan HE
>> 
> 
> Do you have someone from the Glance team helping already?
> 
> 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
> 
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 
> __
> OpenStack Development Mailing 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][infra] Zuul v3 migration update

[Doug Hellmann]

Excerpts from Clark Boylan's message of 2017-09-28 18:40:41 -0700:
> On Wed, Sep 27, 2017, at 03:24 PM, Monty Taylor wrote:
> > Hey everybody,
> > 
> > We're there. It's ready.
> > 
> > We've worked through all of the migration script issues and are happy 
> > with the results. The cutover trigger is primed and ready to go.
> > 
> > But as it's 21:51 UTC / 16:52 US Central it's a short day to be 
> > available to respond to the questions folks may have... so we're going 
> > to postpone one more day.
> > 
> > Since it's all ready to go we'll be looking at flipping the switch first 
> > thing in the morning. (basically as soon as the West Coast wakes up and 
> > is ready to go)
> > 
> > The project-config repo should still be considered frozen except for 
> > migration-related changes. Hopefully we'll be able to flip the final 
> > switch early tomorrow.
> > 
> > If you haven't yet, please see [1] for information about the transition.
> > 
> > [1] https://docs.openstack.org/infra/manual/zuulv3.html
> > 
> 
> Its done! Except for all the work to make jobs run properly. Early today

Woo!

> (PDT) we converted everything over to our auto generated Zuulv3 config.
> Since then we've been working to address problems in job configs.
> 
> These problems include:
> Missing inclusion of the requirements repo for constraints in some
> jobs
> Configuration of python35 unittest jobs in some cases
> Use of sudo checking not working properly
> Multinode jobs not having multinode nodesets
> 
> Known issues we will continue to work on:
> Multinode devstack and grenade jobs are not working quite right
> Releasenote jobs not working due to use of origin/ refs in git

This problem should be fixed by the reno enhancement in
https://review.openstack.org/#/c/508324/, which I will release when I'm
given the all-clear for the release tagging jobs.

> It looks like we may not have job branch exclusions in place for all
> cases
> The zuul-cloner shim may not work in all cases. We are tracking down
> and fixing the broken corner cases.
> 
> Keep in mind that with things in flux, there is a good chance that
> changes enqueued to the gate will fail. It is a good idea to check
> recent check queue results before approving changes.
> 
> I don't think we've found any deal breaker problems at this point. I am
> sure there are many more than I have listed above. Please feel free to
> ask us about any errors. For the adventurous, fixing problems is likely
> a great way to get familiar with the new system. You'll want to start by
> fixing errors in openstack-infra/openstack-zuul-jobs/playbooks/legacy.
> Once that stabilizes the next step is writing native job configs within
> your project tree. Documentation can be found at
> https://docs.openstack.org/infra/manual/zuulv3.html. I expect we'll
> spend the next few days ironing out the transition.
> 
> Thank you for your patience,
> Clark
> 

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

Re: [openstack-dev] [Oslo][oslo.policy][glance] Bug: Glance doesn't send correctly authorization request to Oslo policy

[Doug Hellmann]

Excerpts from ruan.he's message of 2017-09-29 12:56:12 +:
> Hi folks,
> We are testing the http_check function in Oslo policy, and we figure out a 
> bug: https://bugs.launchpad.net/glance/+bug/1720354.
> We believe that this is due to the Glance part since it doesn't well prepare 
> the authorization request (body) to Oslo policy.
> Can we put this topic for the next Oslo meeting?
> Thanks,
> Ruan HE
> 

Do you have someone from the Glance team helping already?

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] [packaging][all] Sample Config Files in setup.cfg

[Doug Hellmann]

Excerpts from Jesse Pretorius's message of 2017-09-28 17:17:55 +:
> On 9/28/17, 5:11 PM, "Doug Hellmann" <d...@doughellmann.com> wrote:
> 
> > In the past we had trouble checking those files into git and gating
> > against the results being "up to date" or not changing in any way
> > because configuration options that end up in the file are defined in
> > libraries used by the services. So as long as the implementation you're
> > considering does not check configuration files into git, but generates
> > them and then inserts them into the package, it should be fine.
> 
> I’m guessing that the aut-generated files you’re referring to are the .conf 
> files? For the most part, those are being left out of my proposed patches 
> unless the project team specifically requests their inclusion. My patches are 
> focused on the far more static files - policy.json if it exists (yes, the 
> policy-in-code will remove those in time), api-paste, rootwrap.conf and the 
> rootwrap.d contents. As far as I know none of these are auto-generated. If 
> they are, I’m all ears to learn how!
> 

Ah, yes, I was talking about oslo.config files but those other files
are more static and shouldn't present the same issue.

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] oslo.config secret store drivers

[Doug Hellmann]

I have updated the old oslo.config drivers spec [1] to remove a bunch of
the information about etcd and focus on the secret store use case we
discussed at the PTG in queens. I think this work is a prerequisite for
the plaintext secrets spec [2] work, because castellan already depends
on oslo.config so we can't have oslo.config invoke castellan directly.

As it stands, the spec itself probably needs some more work.  I can
assist with the design, implementation advice, and code reviews,
but I don't expect to have time to do the implementation work myself
this cycle. If you are interested in helping, please leave a comment
on the review [1].

Doug

[1] https://review.openstack.org/#/c/454897
[2] https://review.openstack.org/#/c/474304

__
OpenStack Development Mailing 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] [docs][ptls][all] documentation retention policy changes

[Doug Hellmann]

At the Queens PTG in Denver the documentation team members present
discussed a new retention policy for content published to
docs.openstack.org. I have a spec up for review to document that
policy and the steps needed to implement it. This policy will affect
all projects, now that most of the documentation is managed by
project teams. Please take a few minutes to review it, or at the
very least have your documentation team liaison do so.

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

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] [packaging][all] Sample Config Files in setup.cfg

[Doug Hellmann]

Excerpts from Jesse Pretorius's message of 2017-09-28 14:50:24 +:
> There’s some history around this discussion [1], but times have changed and 
> the purpose of the patches I’m submitting is slightly different [2] as far as 
> I can see – it’s a little more focused and less intrusive.
> 
> The projects which deploy OpenStack from source or using python wheels 
> currently have to either carry templates for api-paste, policy and rootwrap 
> files or need to source them from git during deployment. This results in some 
> rather complex mechanisms which could be radically simplified by simply 
> ensuring that all the same files are included in the built wheel. 
> Distribution packagers typically also have mechanisms in place to fetch the 
> files from the source repo when building the packages – including the files 
> through pbr’s data_files for packagers may or may not be beneficial, 
> depending on how the packagers do their build processes.
> 
> In neutron [3], glance [4], designate [5] and sahara [6] the use of the 
> data_files option in the files section of setup.cfg is established and has 
> been that way for some time. However, there have been issues in the past 
> implementing something similar – for example in keystone there has been a bit 
> of a yoyo situation where a patch was submitted, then reverted.
> 
> I’ve been proposing patches [7] to try to make the implementation across 
> projects consistent and projects have, for the most part, been happy to go 
> ahead and merge them. However concern has been raised that we may end up 
> going through another yo-yo experience and therefore I’ve been asked to raise 
> this on the ML.
> 
> Do any packagers or deployment projects have issues with this implementation? 
> If there are any issues, what’re your suggestions to resolve them?
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-June/097123.html
> [2] https://launchpad.net/bugs/1718356
> [3] 
> https://github.com/openstack/neutron/blob/d3c393ff6b5fbd0bdaabc8ba678d755ebfba08f7/setup.cfg#L24-L39
> [4] 
> https://github.com/openstack/glance/blob/02cd5cba70a8465a951cb813a573d390887174b7/setup.cfg#L20-L21
> [5] 
> https://github.com/openstack/designate/blob/25eb143db04554d65efe2e5d60ad3afa6b51d73a/setup.cfg#L30-L37
> [6] 
> https://github.com/openstack/sahara/blob/cff43d6f1eee5c68af16c6f655f4d019669224d9/setup.cfg#L28-L29
> [7] 
> https://review.openstack.org/#/q/topic:bug/1718356+(status:open+OR+status:merged)
> 

In the past we had trouble checking those files into git and gating
against the results being "up to date" or not changing in any way
because configuration options that end up in the file are defined in
libraries used by the services. So as long as the implementation you're
considering does not check configuration files into git, but generates
them and then inserts them into the package, it should be 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] [release][ptl] Improving the process for release marketing

[Doug Hellmann]

Excerpts from Jay S Bryant's message of 2017-09-26 18:39:34 -0500:
> On 9/26/2017 4:33 PM, Anne Bertucio wrote:
> 
> > Release marketing is a critical part of sharing what’s new in each release, 
> > and we want to rework how the marketing community and projects work 
> > together to make the release communications happen.
> >
> > Having multiple, repetetive demands to summarize "top features" during 
> > release time can be pestering and having to recollect the information each 
> > time isn't an effective use of time. Being asked to make polished, 
> > "press-friendly" messages out of release notes can feel too far outside of 
> > the PTL's focus areas or skills. At the same time, for technical content 
> > marketers, attempting to find the key features from release notes, ML 
> > posts, specs, Roadmap, etc., means interesting features are sometimes 
> > overlooked. Marketing teams don't have the latest on what features landed 
> > and with what caveats.
> >
> > To address this gap, the Release team and Foundation marketing team propose 
> > collecting information as part of the release tagging process. Similar to 
> > the existing (unused) "highlights" field for an individual tag, we will 
> > collect some text in the deliverable file to provide highlights for the 
> > series (about 3 items). That text will then be used to build a landing page 
> > on release.openstack.org that shows the "key features" flagged by PTLs that 
> > marketing teams should be looking at during release communication times. 
> > The page will link to the release notes, so marketers can start there to 
> > gather additional information, eliminating repetitive asks of PTLs. The 
> > "pre selection" of features means marketers can spend more time diving into 
> > release note details and less sifting through them.
> >
> > To supplement the written information, the marketing community is also 
> > going to work together to consolidate follow up questions and deliver them 
> > in "press corps" style (i.e. a single phone call to be asked questions from 
> > multiple parties vs. multiple phone calls from individuals).
> >
> > We will provide more details about the implementation for the highlights 
> > page when that is ready, but want to gather feedback about both aspects of 
> > the plan early.
> >
> > Thanks for your input,
> > Anne Bertucio and Sean McGinnis
> >
> >
> >
> >
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Anne and Sean,
> 
> Thank you for starting this effort.  I have been amazed how many times I 
> have been asked for the same information since the end of Pike.  I think 
> that having a more automated process for this would be very helpful.
> 
> One request would be that the process allow for more than just a 'one 
> liner' on key features.  If this is being targeted at marketing people 
> we will need to be able to provide more information.  So, if we could 
> have something like little commit messages where there is a summary of 
> what the highlight is and then can provide a bit more verbose 
> explanation (a few sentences) I think that would make this addition more 
> helpful.

I was planning on the usual "embed RST in YAML" pattern. The amount
of detail you leave will then be completely up to you.

Doug

> 
> I look forward to hearing more about this!
> 
> 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

Re: [openstack-dev] [Release-job-failures][infra] Release of openstack-infra/zuul-sphinx failed

[Doug Hellmann]

I assume someone has already noticed that this release failed, but I'm
forwarding it to the dev list just in case.

Excerpts from jenkins's message of 2017-09-25 14:46:58 +:
> Build failed.
> 
> - zuul-sphinx-tarball 
> http://logs.openstack.org/fc/fca979f1eaaed60af404e74c51c0ad67710e18cf/release/zuul-sphinx-tarball/312a264/
>  : SUCCESS in 1m 49s
> - zuul-sphinx-tarball-signing 
> http://logs.openstack.org/fc/fca979f1eaaed60af404e74c51c0ad67710e18cf/release/zuul-sphinx-tarball-signing/1b71335/
>  : FAILURE in 40s
> - zuul-sphinx-pypi-both-upload 
> http://logs.openstack.org/fc/fca979f1eaaed60af404e74c51c0ad67710e18cf/release/zuul-sphinx-pypi-both-upload/2826256/
>  : FAILURE in 7s
> - zuul-sphinx-announce-release zuul-sphinx-announce-release : SKIPPED
> - propose-zuul-sphinx-update-constraints 
> propose-zuul-sphinx-update-constraints : SKIPPED
> 

__
OpenStack Development Mailing 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] patches for simple typo fixes

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-09-25 09:42:08 -0400:
> On 09/25/2017 09:28 AM, Doug Hellmann wrote:
> 
> > I'm less concerned with the motivation of someone submitting the
> > patches than I am with their effect. Just like the situation we had
> > with the bug squash days a year or so ago, if we had a poorly timed
> > set of these trivial patches coming in at our feature freeze deadline,
> > it would be extremely disruptive. So to me the fact that we're
> > seeing them in large batches means we have people who are not fully
> > engaged with the community and don't understand the impact they're
> > having. My goal is to reach out and try to improve that engagement,
> > and try to help them become more fully constructive contributors.
> 
> I think that quantifying how big that impact is would be good before
> deciding it needs to be a priority to act upon. There are lots of things
> that currently swamp our system, and on my back of the envelope math and
> spot checking on resources used, these really aren't a big concern.
> 
> But it's harder to see that until we really start accounting for CI time
> by project / person, and what kinds of things really do consume the system.
> 
> -Sean
> 

Yes, that will be part of the work of the new group looking into the
problem. The idea is to roll this specific problem up with a bunch of
other things related to new contributors so we have a group actively
thinking about better onboarding and engagement from a bunch of
different angles. Watch the SIG mailing list for details.

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] [infra][docs][i18n][ptls] PDFs for project-specific docs with unified doc builds

[Doug Hellmann]

[Topic tags added to subject line]

Excerpts from Ian Y. Choi's message of 2017-09-22 07:29:23 +0900:
> Hello,
> 
> "Build PDF docs from rst-based guide documents" [1] was implemented in Ocata
> cycle, and I have heard that there were a small conversation at the 
> Denver PTG
> regarding getting PDFs for project-specific docs setup to help translations.
> 
> In my opinion, it would be a nice idea to extend [1] to project-specific
> docs with unified doc builds. It seems that unified doc builds have been
> much enhanced with [2]. Now I think having PDF build functionalities in 
> unified
> doc builds would be a way to easily have PDFs for project-specific docs.
> 
> Would someone have any idea on this or help it with some good pointers?

The job-template for the unified doc build job is in
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/openstack-publish-jobs.yaml#n22

It uses the "docs" macro, which invokes the script
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/run-docs.sh

I think we would want to place any new logic for extending the build in
that script, although we should coordinate any changes with the Zuul v3
rollout because as part of that I have seen some suggestions to change
the expected interface for building documentation and we want to make
sure any changes we make will work with the updated interface.

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] patches for simple typo fixes

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-09-25 08:24:18 -0400:
> On 09/25/2017 07:56 AM, Chris Dent wrote:
> > On Fri, 22 Sep 2017, Paul Belanger wrote:
> > 
> >> This is not a good example of encouraging anybody to contribute to the
> >> project.
> > 
> > Yes. This entire thread was a bit disturbing to read. Yes, I totally
> > agree that mass patches that do very little are a big cost to
> > reviewer and CI time but a lot of the responses sound like: "go away
> > you people who don't understand our special culture and our
> > important work".
> > 
> > That's not a good look.
> > 
> > Matt's original comment is good in and of itself: I saw a thing,
> > let's remember to curtail this stuff and do it in a nice way.
> > 
> > But then we generate a long thread about it. It's odd to me that
> > these threads sometimes draw more people out then discussions about
> > actually improving the projects.
> > 
> > It's also odd that if OpenStack were small and differently
> > structured, any self-respecting maintainer would be happy to see
> > a few typo fixes and generic cleanups. Anything to push the quality
> > forward is nice. But because of the way we do review and because of
> > the way we do CI these things are seen as expensive distractions[1].
> > We're old and entrenched enough now that our tooling enforces our
> > culture and our culture enforces our tooling.
> > 
> > [1] Note that I'm not denying they are expensive distractions nor
> > that they need to be managed as such. They are, but a lot of that
> > is on us.
> 
> I was trying to ignore the thread in the hopes it would die out quick.
> But torches and pitchforks all came out from the far corners, so I'm
> going to push back on that a bit.
> 
> I'm not super clear why there is always so much outrage about these
> patches. They are fixing real things. When I encounter them, I just
> approve them to get them merged quickly and not backing up the review
> queue, using more CI later if they need rebasing. They are fixing real
> things. Maybe there is a CI cost, but the faster they are merged the
> less likely someone else is to propose it in the future, which keeps
> down the CI cost. And if we have a culture of just fixing typos later,
> then we spend less CI time on patches the first time around with 2 or 3
> iterations catching typos.
> 
> I think the concern is the ascribed motive for why people are putting
> these up. That's fine to feel that people are stat padding (and that too
> many things are driven off metrics). But, honestly, that's only
> important if we make it important. Contributor stats are always going to
> be pretty much junk stats. They are counting things to be the same which
> are wildly variable in meaning (number of patches, number of Lines of
> Code).
> 
> My personal view is just merge things that fix things that are wrong,
> don't care why people are doing it. If it gets someone a discounted
> ticket somewhere, so be it. It's really not any skin off our back in the
> process.
> 
> If people are deeply concerned about CI resources, step one is to get
> some better accounting into the existing system to see where resources
> are currently spent, and how we could ensure that time is fairly spread
> around to ensure maximum productivity by all developers.
> 
> -Sean
> 

I'm less concerned with the motivation of someone submitting the
patches than I am with their effect. Just like the situation we had
with the bug squash days a year or so ago, if we had a poorly timed
set of these trivial patches coming in at our feature freeze deadline,
it would be extremely disruptive. So to me the fact that we're
seeing them in large batches means we have people who are not fully
engaged with the community and don't understand the impact they're
having. My goal is to reach out and try to improve that engagement,
and try to help them become more fully constructive contributors.

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] Garbage patches for simple typo fixes

[Doug Hellmann]

Excerpts from Qiming Teng's message of 2017-09-23 23:55:34 +0800:
> To some extent, I think Zhipeng is right. There are times we as a
> community have to do something beyond mentoring new developers. One of
> the reasons behind these patches are from the management chain of those
> companies. They need numbers, and they don't care what kind of
> contributions were made. They don't bother read these emails.
> 
> Another fact is that some companies are doing such things not just in the
> OpenStack community. Their developers are producing tons of low-quality
> "patches" to play this as a game in other communities as well. If we
> don't place a STOP sign, things will never get improved. By not doing
> something, we are hurting everyone, including those developers who could
> have done more meaningful contributions, though their number of patches
> may decrease.
> 
> Just my 2 cents.
> 
> - Qiming 

This may be true. Before we create harsh processes, however, we
need to collect the data to show that other attempts to provide
guidance have not worked.  We have a lot of anecdotal information
right now. We need to collect that and summarize it. If the results
show that there are clear abuses, rather than misunderstandings,
then we can use the data to design effective blocks without hurting
other contributors or creating a reputation that our community is
not welcoming.

Doug

> 
> On Sat, Sep 23, 2017 at 08:34:18AM +0800, Zhipeng Huang wrote:
> > Hi Paul,
> > 
> > Unfortunately I know better on this matter and it is not the matter of
> > topic dispute as many people on this thread who has been disturbed and
> > annoyed by the padding/trolling.
> > 
> > So yes I'm sticking with stupid because it hurts the OpenStack community as
> > a whole and hurts the reputation of the dev community from my country which
> > in large are great people with good hearts and skills.
> > 
> > I'm not giving even an inch of the benefit of doubt to these padding
> > activities and people behind it.
> > 
> > 
> > On Sat, Sep 23, 2017 at 8:16 AM, Paul Belanger 
> > wrote:
> > 
> 

__
OpenStack Development Mailing 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] Garbage patches for simple typo fixes

[Doug Hellmann]

Excerpts from Huang Zhiteng's message of 2017-09-23 10:00:00 +0800:
> On Sat, Sep 23, 2017 at 8:34 AM, Zhipeng Huang  wrote:
> > Hi Paul,
> >
> > Unfortunately I know better on this matter and it is not the matter of topic
> > dispute as many people on this thread who has been disturbed and annoyed by
> > the padding/trolling.
> >
> > So yes I'm sticking with stupid because it hurts the OpenStack community as
> > a whole and hurts the reputation of the dev community from my country which
> > in large are great people with good hearts and skills.
> >
> > I'm not giving even an inch of the benefit of doubt to these padding
> > activities and people behind it.
> Hi Zhipeng,
> 
> Not sure how much you have been involved in the dev community in
> China, but it's now a good time to talk to those companies (in public
> or private) and ask them to stop encourage their developers to submit
> such changes.

I would prefer to set up a system where we can have those sorts of
conversations in private, to encourage people to contribute
constructively instead of shaming them.

Doug

> 
> >
> >
> > On Sat, Sep 23, 2017 at 8:16 AM, Paul Belanger 
> > wrote:
> >>
> >> On Fri, Sep 22, 2017 at 10:26:09AM +0800, Zhipeng Huang wrote:
> >> > Let's not forget the epic fail earlier on the "contribution.rst fix"
> >> > that
> >> > almost melt down the community CI system.
> >> >
> >> > For any companies that are doing what Matt mentioned, please be aware
> >> > that
> >> > the dev community of the country you belong to is getting hurt by your
> >> > stupid activity.
> >> >
> >> > Stop patch trolling and doing something meaningful.
> >> >
> >> Sorry, but I found this comment over the line. Just because you disagree
> >> with
> >> the $topic at hand, doesn't mean you should default to calling it
> >> 'stupid'. Give
> >> somebody the benefit of not knowing any better.
> >>
> >> This is not a good example of encouraging anybody to contribute to the
> >> project.
> >>
> >> -Paul
> >>
> >> > On Fri, Sep 22, 2017 at 10:21 AM, Matt Riedemann 
> >> > wrote:
> >> >
> >> > > I just wanted to highlight to people that there seems to be a series
> >> > > of
> >> > > garbage patches in various projects [1] which are basically doing
> >> > > things
> >> > > like fixing a single typo in a code comment, or very narrowly changing
> >> > > http
> >> > > to https in links within docs.
> >> > >
> >> > > Also +1ing ones own changes.
> >> > >
> >> > > I've been trying to snuff these out in nova, but I see it's basically
> >> > > a
> >> > > pattern widespread across several projects.
> >> > >
> >> > > This is the boilerplate comment I give with my -1, feel free to employ
> >> > > it
> >> > > yourself.
> >> > >
> >> > > "Sorry but this isn't really a useful change. Fixing typos in code
> >> > > comments when the context is still clear doesn't really help us, and
> >> > > mostly
> >> > > seems like looking for padding stats on stackalytics. It's also a
> >> > > drain on
> >> > > our CI environment.
> >> > >
> >> > > If you fixed all of the typos in a single module, or in user-facing
> >> > > documentation, or error messages, or something in the logs, or
> >> > > something
> >> > > that actually doesn't make sense in code comments, then maybe, but
> >> > > this
> >> > > isn't one of those things."
> >> > >
> >> > > I'm not trying to be a jerk here, but this is annoying to the point I
> >> > > felt
> >> > > the need to say something publicly.
> >> > >
> >> > > [1] https://review.openstack.org/#/q/author:%255E.*inspur.*
> >> > >
> >> > > --
> >> > >
> >> > > Thanks,
> >> > >
> >> > > Matt
> >> > >
> >> > >
> >> > > __
> >> > > OpenStack Development Mailing List (not for usage questions)
> >> > > Unsubscribe:
> >> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Zhipeng (Howard) Huang
> >> >
> >> > Standard Engineer
> >> > IT Standard & Patent/IT Product Line
> >> > Huawei Technologies Co,. Ltd
> >> > Email: huangzhip...@huawei.com
> >> > Office: Huawei Industrial Base, Longgang, Shenzhen
> >> >
> >> > (Previous)
> >> > Research Assistant
> >> > Mobile Ad-Hoc Network Lab, Calit2
> >> > University of California, Irvine
> >> > Email: zhipe...@uci.edu
> >> > Office: Calit2 Building Room 2402
> >> >
> >> > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
> >>
> >> >
> >> > __
> >> > OpenStack Development Mailing 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 

Re: [openstack-dev] Garbage patches for simple typo fixes

[Doug Hellmann]

Excerpts from Ildiko Vancsa's message of 2017-09-22 13:20:31 -0600:
> Hi All,
> 
> Another forum we try to put emphasis on this is the Upstream Institute 
> trainings we have before the Summits and on some smaller events as well.
> 
> We usually try to spend some quality time on review best practices and on 
> metrics as well. The aim is to make people realize that if they need practice 
> with the process the project repositories are not the place for that and also 
> to let them know that we see the patterns and they get negative recognition 
> for it.
> 
> The only issue with that is I’m not sure we always have the right audience, 
> like people might not contribute after all neither they give the knowledge 
> and heads up to their colleagues in the company who do. :( Regardless of this 
> we will continue to highlight these and if you have suggestion on what else 
> we should mention or how to better articulate it we are open to ideas.
> 
> We were also thinking about collecting ideas and suggestions for people who 
> would take on mentoring in projects, like what and how to do. Do you see this 
> activity being part of that too? Could we say something like if we have a few 
> people per project who are willing to coach and mentor people we can have a 
> small set of guidelines for them on how to start the communication for these 
> cases? Or would this rather be handled centrally?
> 
> As for those who are practicing we have sandbox repositories/projects in all 
> the tools which might worth highlighting.
> 
> The new Contributor Portal can also be a good place to highlight 
> corresponding best practices and point out behaviors we disagree with.

It makes sense to repeat this information in a few places, with
references to an extensive explanation in the project team guide.
I don't think that would have helped in the current cases, but it
won't hurt in the future.

Doug

> 
> Thanks,
> Ildikó
> IRC: ildikov
> 
> > On 2017. Sep 22., at 12:47, Doug Hellmann <d...@doughellmann.com> wrote:
> > 
> > Excerpts from Davanum Srinivas (dims)'s message of 2017-09-22 13:47:06 
> > -0400:
> >> Doug,
> >> Howard (cc'ed) already did a bunch of reaching out especially on
> >> wechat. We should request his help.
> >> 
> >> Howard,
> >> Can you please help with communications and follow up?
> >> 
> >> Thanks,
> >> Dims
> > 
> > Thanks, Dims and Howard,
> > 
> > I think the problem has reached a point where it would be a good
> > idea to formalize our approach to outreach. We should track the
> > patches or patch series identified as problematic, so reviewers
> > know not to bother with them. We can also track who is contacting
> > whom (and how) so we don't have a bunch of people replicating work
> > or causing confusion for people who are trying to contribute. Having
> > that information will also help us figure out when we need to
> > escalate by finding the right managers to be talking to.
> > 
> > Let's put together a small team to manage this instead of letting
> > it continue to cause frustration for everyone.
> > 
> > Doug
> > 
> >> 
> >> On Fri, Sep 22, 2017 at 1:43 PM, Doug Hellmann <d...@doughellmann.com> 
> >> wrote:
> >>> Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500:
> >>>> On 9/22/2017 7:10 AM, Tom Barron wrote:
> >>>>> FWIW I think it is better not to attribute motivation in these cases.
> >>>>> Perhaps the code submitter is trying to pad stats, but perhaps they are
> >>>>> just a new contributor trying to learn the process with a "harmless"
> >>>>> patch, or just a compulsive clean-upper who hasn't thought through the
> >>>>> costs in reviewer time and CI resources.
> >>>> 
> >>>> I agree. However, the one that set me off last night was a person from
> >>>> one company who I've repeatedly -1ed the same types of patches in nova
> >>>> for weeks, including on stable branches, and within 10 minutes of each
> >>>> other across several repos, so it's clearly part of some daily routine.
> >>>> That's what prompted me to send something to the mailing list.
> >>>> 
> >>> 
> >>> As fungi points out, education and communication are likely to be
> >>> our best solution. Maybe one approach is to identify the companies
> >>> and individuals involved and find one of our community members to
> >>> contact them directly via email.  We would want the person 

Re: [openstack-dev] [requirements][stable] EOL tags and upper-constraints.txt in tox.ini

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2017-09-21 20:20:22 -0500:
> On Thu, Sep 21, 2017 at 12:13:23PM -0400, Doug Hellmann wrote:
> > Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400:
> > > On Wed, Sep 20, 2017 at 06:08:22PM -0400, Doug Hellmann wrote:
> > > 
> > > > I like the idea. I'm not sure why, if the constraints file is only used
> > > > for the dependency installation step, we still need tox_install.sh?
> > > 
> > > Right now that isn't true, when we get something like my idea
> > > implemented we'd still need the tox_install.sh in projects that need
> > > services (not published on pypi) like horizon plugins or neutron stadium
> > > projects.   Fixing that issue is a totally different discussion, one I
> > > started at the PTG but I need to let those conversations settle and do
> > > research on wasy to fix that.
> > > 
> > > > If
> > > > that's just to avoid updating the URL when we create branches, I can
> > > > live with continuing to do that step if we figure out some other way to
> > > > minimize the open race window.
> > > 
> > > So lets check we're on the same page with the race window point.  At the
> > > moment the process looks like:
> > > 1. projects tag RC1 and when generate a stable/series branch.
> > > 2. We generate a reviews that updates .gitreview
> > > 3. We generate a reviews that updates .tox.ini
> > > 4. time passes
> > > 5. requirements creates a stable/series branch
> > > 6. requirements thaws
> > > 
> > > Now the race is that if projects merge the patch from step 3 before step
> > > 5 they're broken (on stable/series) because there isn't a
> > > 'stable/series' in the requirements repo.  There are some additional 
> > > issues
> > > for cycle-trailing projects but nothing radically different.
> > > 
> > > Correct?
> > > 
> > > Assuming I have that right  In the new world:
> > > 
> > > 0. requirements publish master.txt and series.txt
> > > 1. projects tag RC1 and when generate a stable/series branch.
> > > 2. We generate a reviews that updates .gitreview
> > > 3. We generate a reviews that updates .tox.ini
> > > 4. time passes
> > > 5. requirements creates a stable/series branch
> > > 6. requiremenst now publish series.txt, new_series.txt and master.txt
> > > 6. requirements thaws
> > 
> > Where in that sequence do we make the change so that we're not
> > publishing to series.txt from the new stable branch in requirements and
> > from master in requirements? Between step 4 and 5? Or is the job smart
> > enough to not do that?
> 
> Right now the job is dumb, but yes we'd teach the job to detect that's
> it's a stable branch and only publish it's series branch.  We also teach
> the job to not publish to $series.txt if that stable branch exists.
> 
> So I think the publish job looks like:
> 
> ---
> # preamble
> # typed directly into email so be warned ;P
> # We probably want to check if ZUUL_BRANCH is the correct variable to
> # use.
> case "$ZUUL_BRANCH" in
> stable/*)
> series=$(basename "$ZUUL_BRANCH")
> git show origin/$ZUUL_BRANCH:upper-constraints.txt > 
> publish/constraints/upper/${series}.txt
> ;;
> master)
> for series in queens master ; do
> if ! git rev-parse origin/stable/${series} ; then
> git show origin/master:upper-constraints.txt > 
> publish/constraints/upper/${series}.txt
> fi
> done
> ;;
> esac
> # postample
> ---
> 
> So using the queens release as an example:
> 
> Jan 22 - Jan 26R-5 Requirements freeze
> NOTES: openstack/requirements (master) publishes 
> {queens,master}.txt
> Jan 29 - Feb 02R-4  
> Feb 05 - Feb 09R-3RC1 target week
> ACTIONS: Projects create stable/queens branches
> ACTIONS: Generate .gitreview and UPPER_CONSTRAINTS changes
> ACTIONS: Projects merge .gitreview and UPPER_CONSTRAINTS 
> changes
> Feb 12 - Feb 16R-2
> ACTIONS: Projects create stable/queens branch for 
> openstack/requirements
> ACTIONS: Generate .gitreview and UPPER_CONSTRAINTS changes
> ACTIONS: Projects merge .gitreview and UPPER_CONSTRAINTS 
> changes
> ACTIONS: Make sure master publishes {rocky,master}.txt
>  (optionally add the S relea

Re: [openstack-dev] Garbage patches for simple typo fixes

[Doug Hellmann]

Excerpts from Davanum Srinivas (dims)'s message of 2017-09-22 13:47:06 -0400:
> Doug,
> Howard (cc'ed) already did a bunch of reaching out especially on
> wechat. We should request his help.
> 
> Howard,
> Can you please help with communications and follow up?
> 
> Thanks,
> Dims

Thanks, Dims and Howard,

I think the problem has reached a point where it would be a good
idea to formalize our approach to outreach. We should track the
patches or patch series identified as problematic, so reviewers
know not to bother with them. We can also track who is contacting
whom (and how) so we don't have a bunch of people replicating work
or causing confusion for people who are trying to contribute. Having
that information will also help us figure out when we need to
escalate by finding the right managers to be talking to.

Let's put together a small team to manage this instead of letting
it continue to cause frustration for everyone.

Doug

> 
> On Fri, Sep 22, 2017 at 1:43 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> > Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500:
> >> On 9/22/2017 7:10 AM, Tom Barron wrote:
> >> > FWIW I think it is better not to attribute motivation in these cases.
> >> > Perhaps the code submitter is trying to pad stats, but perhaps they are
> >> > just a new contributor trying to learn the process with a "harmless"
> >> > patch, or just a compulsive clean-upper who hasn't thought through the
> >> > costs in reviewer time and CI resources.
> >>
> >> I agree. However, the one that set me off last night was a person from
> >> one company who I've repeatedly -1ed the same types of patches in nova
> >> for weeks, including on stable branches, and within 10 minutes of each
> >> other across several repos, so it's clearly part of some daily routine.
> >> That's what prompted me to send something to the mailing list.
> >>
> >
> > As fungi points out, education and communication are likely to be
> > our best solution. Maybe one approach is to identify the companies
> > and individuals involved and find one of our community members to
> > contact them directly via email.  We would want the person doing
> > that to be willing to explain all of the reasons the community does
> > not want the sort of activity we are rejecting and to provide
> > guidance about more useful contributions (Matt's comment is a great
> > start on both). I imagine that conversation would take a good deal
> > of patience, especially after the second or third time, but a personal
> > touch frequently makes all the difference in these sorts of cases.
> >
> > If we have someone willing to step into that sort of role, I would
> > be happy to help craft the initial contact messages and advise as
> > needed.
> >
> > Does anyone want to volunteer to work with me and actually send the
> > emails?
> >
> > 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] Garbage patches for simple typo fixes

[Doug Hellmann]

Excerpts from Matt Riedemann's message of 2017-09-22 08:26:31 -0500:
> On 9/22/2017 7:10 AM, Tom Barron wrote:
> > FWIW I think it is better not to attribute motivation in these cases.
> > Perhaps the code submitter is trying to pad stats, but perhaps they are
> > just a new contributor trying to learn the process with a "harmless"
> > patch, or just a compulsive clean-upper who hasn't thought through the
> > costs in reviewer time and CI resources.
> 
> I agree. However, the one that set me off last night was a person from 
> one company who I've repeatedly -1ed the same types of patches in nova 
> for weeks, including on stable branches, and within 10 minutes of each 
> other across several repos, so it's clearly part of some daily routine. 
> That's what prompted me to send something to the mailing list.
> 

As fungi points out, education and communication are likely to be
our best solution. Maybe one approach is to identify the companies
and individuals involved and find one of our community members to
contact them directly via email.  We would want the person doing
that to be willing to explain all of the reasons the community does
not want the sort of activity we are rejecting and to provide
guidance about more useful contributions (Matt's comment is a great
start on both). I imagine that conversation would take a good deal
of patience, especially after the second or third time, but a personal
touch frequently makes all the difference in these sorts of cases.

If we have someone willing to step into that sort of role, I would
be happy to help craft the initial contact messages and advise as
needed.

Does anyone want to volunteer to work with me and actually send the
emails?

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][oslo.config][all] who asked me about versioning or deprecating default values for config options?

[Doug Hellmann]

Last week at the PTG someone asked me about best practices for
changing or deprecating default values for configuration options.
Unfortunately I failed to make any notes at the time and I'm
embarrassed to say that I don't remember who it was or exactly what
the use case was. If that was you, could you let me know?  Another
potentially related case came up, and I think I have an approach
that works for both situations, but before I throw around a lot of
details I want to make sure I've thought it through.

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] Garbage patches for simple typo fixes

[Doug Hellmann]

Excerpts from Tom Barron's message of 2017-09-22 08:10:35 -0400:
> 
> On 09/21/2017 10:21 PM, Matt Riedemann wrote:
> > I just wanted to highlight to people that there seems to be a series of
> > garbage patches in various projects [1] which are basically doing things
> > like fixing a single typo in a code comment, or very narrowly changing
> > http to https in links within docs.
> > 
> > Also +1ing ones own changes.
> > 
> > I've been trying to snuff these out in nova, but I see it's basically a
> > pattern widespread across several projects.
> > 
> > This is the boilerplate comment I give with my -1, feel free to employ
> > it yourself.
> > 
> > "Sorry but this isn't really a useful change. Fixing typos in code
> > comments when the context is still clear doesn't really help us, and
> > mostly seems like looking for padding stats on stackalytics. It's also a
> > drain on our CI environment.
> > 
> > If you fixed all of the typos in a single module, or in user-facing
> > documentation, or error messages, or something in the logs, or something
> > that actually doesn't make sense in code comments, then maybe, but this
> > isn't one of those things."
> > 
> > I'm not trying to be a jerk here, but this is annoying to the point I
> > felt the need to say something publicly.
> > 
> > [1] https://review.openstack.org/#/q/author:%255E.*inspur.*
> > 
> 
> The boilerplate is helpful but have we considered putting something
> along these lines in official documentation so that reviewers can just
> point to it? It should then be clear to all that negative reviews on
> these grounds are not simply a function of the individual reviewer's
> judgment or personality.

That's a good idea. How about adding a "Contribution Guidelines" section
to https://docs.openstack.org/project-team-guide/open-development.html
with this and other tips?

> FWIW I think it is better not to attribute motivation in these cases.
> Perhaps the code submitter is trying to pad stats, but perhaps they are
> just a new contributor trying to learn the process with a "harmless"
> patch, or just a compulsive clean-upper who hasn't thought through the
> costs in reviewer time and CI resources.

Good points.

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] [skip-level-upgrades][fast-forward-upgrades] PTG summary

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2017-09-21 17:10:52 +0200:
> Sean Dague wrote:
> > Agreed. We're already at 5 upgrade tags now?
> > 
> > I think honestly we're going to need a picture to explain the
> > differences between them. Based on the confusion that kept seeming to
> > come during discussions at the PTG, I think we need to circle around and
> > figure out if there are different ways to explain this to have greater
> > clarity.
> 
> In the TC/SWG room we reviewed the tags, and someone suggested that any
> tag that doesn't even have one project to apply it to should probably be
> removed.
> 
> That would get us rid of 3 of them: supports-accessible-upgrade,
> supports-zero-downtime-upgrade, and supports-zero-impact-upgrade (+
> supports-api-interoperability which has had little support so far).
> 
> They can always be resurrected when a project reaches new heights?
> 

On the other hand, some of those were meant to be aspirational, so not
documenting them may mean no one is thinking about them 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] [requirements][stable] EOL tags and upper-constraints.txt in tox.ini

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2017-09-21 08:36:39 -0400:
> On Wed, Sep 20, 2017 at 06:08:22PM -0400, Doug Hellmann wrote:
> 
> > I like the idea. I'm not sure why, if the constraints file is only used
> > for the dependency installation step, we still need tox_install.sh?
> 
> Right now that isn't true, when we get something like my idea
> implemented we'd still need the tox_install.sh in projects that need
> services (not published on pypi) like horizon plugins or neutron stadium
> projects.   Fixing that issue is a totally different discussion, one I
> started at the PTG but I need to let those conversations settle and do
> research on wasy to fix that.
> 
> > If
> > that's just to avoid updating the URL when we create branches, I can
> > live with continuing to do that step if we figure out some other way to
> > minimize the open race window.
> 
> So lets check we're on the same page with the race window point.  At the
> moment the process looks like:
> 1. projects tag RC1 and when generate a stable/series branch.
> 2. We generate a reviews that updates .gitreview
> 3. We generate a reviews that updates .tox.ini
> 4. time passes
> 5. requirements creates a stable/series branch
> 6. requirements thaws
> 
> Now the race is that if projects merge the patch from step 3 before step
> 5 they're broken (on stable/series) because there isn't a
> 'stable/series' in the requirements repo.  There are some additional issues
> for cycle-trailing projects but nothing radically different.
> 
> Correct?
> 
> Assuming I have that right  In the new world:
> 
> 0. requirements publish master.txt and series.txt
> 1. projects tag RC1 and when generate a stable/series branch.
> 2. We generate a reviews that updates .gitreview
> 3. We generate a reviews that updates .tox.ini
> 4. time passes
> 5. requirements creates a stable/series branch
> 6. requiremenst now publish series.txt, new_series.txt and master.txt
> 6. requirements thaws

Where in that sequence do we make the change so that we're not
publishing to series.txt from the new stable branch in requirements and
from master in requirements? Between step 4 and 5? Or is the job smart
enough to not do that?

Where in the sequence do we add new_series.txt? Also between 4 and 5?

> In this scenario We've removed the race as there is a series.txt file
> available befoer the project and requirements branch.
> 
> Also[1] if, right now, projects used queens.txt we wouldn't need to
> update tox.ini when we branch stable/queens, but we would need to update
> master.  This is a point of confusion that we'll need to document and
> possible check for somewhere in our tools.
> 
> Yours Tony.
> 
> [1] This just occurred to me

__
OpenStack Development Mailing 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] publish upper-constraints.txt periodic vs post

[Doug Hellmann]

Excerpts from Matthew Thode's message of 2017-09-21 10:43:50 -0500:
> On 17-09-20 14:09:15, Tony Breeds wrote:
> > On Wed, Sep 20, 2017 at 01:43:51PM -0400, Tony Breeds wrote:
> > 
> > > The solution I thought we decide on at the PTG is:
> > >  * Add a post job to all branches that publish a constraints/$series.txt
> > >to $server (I don't mind if it's releases.o.o or tarballs.o.o).
> > 
> > Actually we might be better to do this daily from the periodic pipeline.
> > In our CI we always gate with what is in git so that wouldn't be
> > impacted.  The question is do we need external consumers to be "up to
> > the minute" or is a days lag acceptable?
> > 
> > I kinda feel like it's okay to be a little laggy.
> > 
> > Yours Tony.
> 
> I don't think this should be periodic, I'll try to argue the point via a
> pros/cons listing.  I think we should be trying to have users use
> upper-constraints via what is currently known as stable, to me that
> means more often than once a day.
> 
> I'm probably a bit biased, so feel free to update :D
> 
> pros - periodic
> * simple update schedule (once a day)
> * easier on infra (publish just once vs up to 20-30 times a day)
> 
> cons - periodic
> * point in time (once a day) does not guarantee that that point works
>   while we try to ensure all projects are not impacted by changes, we
>   are not perfect
> * we would be making it harder for people to use upper-constraints externally
>   for one thing (via longer turn around time)
> * some projects may be using upper-constraints.txt from the url only
> 
> pros - post
> * upper-constraints are available via published location immediately
> * sets good precident for end users/devs to use it
> 
> cons - post
> * both breaks and fixes quick
> * more load on infra to publish (20-30 times a day)
> 

Another point against a periodic job is that it would be a change from
what we're doing now, where constraints are updated as soon as the git
cache is updated.

I think we should publish using a post-merge job. The job isn't
expensive, right? It's just copying some files out of git onto the
web server?

Do we really land 20-30 changes to the constraints list on an average
day?

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] EOL tags and upper-constraints.txt in tox.ini

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2017-09-20 17:18:51 -0400:
> On Wed, Sep 20, 2017 at 04:51:21PM -0400, Doug Hellmann wrote:
> > Excerpts from Jeremy Stanley's message of 2017-09-20 18:59:50 +:
> > > On 2017-09-20 14:46:32 -0400 (-0400), Tony Breeds wrote:
> > > [...]
> > > > I'd like to find a solution that doesn't need a tox_install.sh
> > > [...]
> > > 
> > > This wart came up when discussing Zuul v3 job translations... what
> > > would be ideal is if someone has the bandwidth to work upstream in
> > > tox to add a constraints file option agreeable to its maintainer so
> > > that we don't have to override install-command to add it in all our
> > > configs.
> > 
> > One of the reasons we need a script is to modify the constraint list to
> > remove the current library from the list if it is present. I'm not sure
> > that special logic would be something the tox maintainers would want.
> 
> My proposal is that if 'constraints' is enabled then it's only used for
> the deps install.  Since that should get everything that $project needs
> if it's omitted during that phase it wont hurt us *and* removes the
> needs for that aspect of the tox_install.sh
> 
> In my head it looks like:
> ---
> [testenv]
> usedevelop = True
> # constraints = 
> {env:UPPER_CONSTRAINTS_FILE:https://tarballs.openstack.org/constraints/master.txt}
> constraints = 
> {env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt}
> install_command = pip install {constraints} {opts} {packages}
> deps = -r{toxinidir}/requirements.txt
>-r{toxinidir}/test-requirements.txt
> ---
> 
> It wont remove tox_install.sh but it will reduce the number of projects
> that needs it.  For example oslso.* and os-* shouldn't need a
> tox_install.sh it we can make the above happen.
> 
> 
> Yours Tony.

I like the idea. I'm not sure why, if the constraints file is only used
for the dependency installation step, we still need tox_install.sh? If
that's just to avoid updating the URL when we create branches, I can
live with continuing to do that step if we figure out some other way to
minimize the open race window.

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] EOL tags and upper-constraints.txt in tox.ini

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2017-09-20 18:59:50 +:
> On 2017-09-20 14:46:32 -0400 (-0400), Tony Breeds wrote:
> [...]
> > I'd like to find a solution that doesn't need a tox_install.sh
> [...]
> 
> This wart came up when discussing Zuul v3 job translations... what
> would be ideal is if someone has the bandwidth to work upstream in
> tox to add a constraints file option agreeable to its maintainer so
> that we don't have to override install-command to add it in all our
> configs.

One of the reasons we need a script is to modify the constraint list to
remove the current library from the list if it is present. I'm not sure
that special logic would be something the tox maintainers would want.

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] EOL tags and upper-constraints.txt in tox.ini

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2017-09-20 18:35:23 +:
> On 2017-09-20 14:24:32 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > it doesn't really solve the problem of having to update the
> > branches every time we open one. Having tox_install.sh figure out
> > the URL from the .gitreview file addresses that, but it may be too
> > magic for some folks. I don't know if we have generally agreed to
> > let anything other than git-review look at that file.
> 
> Further, git-review has grown additional magic to allow it to figure
> out sane values for defaultbranch when omitted from the .gitreview
> file, so having other tools depend on that implementation detail
> could come back to bite us down the road.

It sounds like we want git-review to have a mode that prints the
branch to which the change would be proposed, without actually
proposing anything. Our scripts could then use 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] [skip-level-upgrades][fast-forward-upgrades] PTG summary

[Doug Hellmann]

Excerpts from Dan Smith's message of 2017-09-20 10:09:54 -0700:
> >> - Modify the `supports-upgrades`[3] and `supports-accessible-upgrades`[4] 
> >> tags
> >>
> >>I have yet to look into the formal process around making changes to
> >>these tags but I will aim to make a start ASAP.
> > 
> > We've previously tried to avoid changing assert tag definitions because
> > we then have to re-review all of the projects that already have the tags
> > to ensure they meet the new criteria. It might be easier to add a new
> > tag for assert:supports-fast-forward-upgrades with the criteria that are
> > unique to this use case.
> 
> We already have a confusing array of upgrade tags, so I would really 
> rather not add more that overlap in complicated ways. Most of the change 
> here is clarification of things I think most people assume, so I don't 
> think the validation effort will be a lot of work.
> 
> --Dan

OK, I'll wait to see what the actual updates look like before commenting
further, but it sounds like working on the existing tag definitions is a
good first step.

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] EOL tags and upper-constraints.txt in tox.ini

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2017-09-20 13:43:51 -0400:
> On Wed, Sep 20, 2017 at 01:08:45PM -0400, Doug Hellmann wrote:
> > Excerpts from Jeremy Stanley's message of 2017-09-20 13:36:38 +:
> > > On 2017-09-20 08:41:14 -0400 (-0400), Doug Hellmann wrote:
> > > [...]
> > > > Is there any reason not to use the published files for all regular
> > > > builds, instead of having tox.ini point to a git URL? Maybe only for
> > > > regular builds off of stable branches?
> > > 
> > > I'm not sure what you mean by "regular builds" but the plan as I
> > 
> > s/regular/non-CI/
> > 
> > > understood it was to switch from git.o.o URLs to releases.o.o URLs
> > > in the tox.ini files in all branches of projects already consuming
> > > constraints files that way.
> > > 
> > > As early as now (if we already had the publication job in place) we
> > > could update them all in master branches to retrieve something like
> > > https://releases.openstack.org/constraints/queens-upper-constraints.txt
> > > and then once stable/queens is branched in all repos (including the
> > > requirements repo), switch the job to begin publishing to a URL for
> > > rocky and push tox.ini updates to master branches switching the URL
> > > to that as early in the cycle as possible. Alternatively, we could
> > > publish master and queens copies (identical initially) and expect
> > > the master branch tox.ini files to refer to master but then switch
> > > them to queens on the stable/queens branch during RC. It just comes
> > > down to which the stable/requirements/release teams think makes the
> > > most sense from a procedural perspective.
> > 
> > We should think through which of those approaches is going to result in
> > the least amount of synchronization. We do have a window in which to
> > make changes in a given branch for consuming projects, but making the
> > relevant changes in the requirements repository seems like it could be
> > error prone, especially because we try to branch it after the other
> > repositories.
> 
> The solution I thought we decide on at the PTG is:
>  * Add a post job to all branches that publish a constraints/$series.txt
>to $server (I don't mind if it's releases.o.o or tarballs.o.o).
>  * On the master branch we publish both master.txt and $series.txt
>(currently queens.txt) when we fork rocky from master we update the
>publish job to publish master and rocky.txt.As Doug points out
>there is a timing race here but it;s much smaller than the one we
>have now.

Yes, I think that would work. It adds another manual step to the release
process (to update the job) but that can technically be done as soon as
we know the next release name because we can publish from master to as
many different future names as we want.

We're starting to have a fair amount of automation that relies on
knowing the names of the release series and their statuses. I wonder if
we can produce a central library of some sort to give us that
information in a consumable format so we only have to update it in one
place.

>  * We update the projects to use the static (non-git) URL for the
>constraints files.
>  * We update the release tools to generate the new style URL.
> 
> Optionally, and this requires discussion, we use a custom tox_install.sh
> to extract the branch from .gitreview and generate the URL which would
> remove the need for the last step.  There are clearly pros and cons to
> that so I'm not advocating for it now.
> 
> Those constraints files would never be removed but they'd stop getting
> updated when we EOL the requirements branch.
> 
> How does that sound?

That solves the problem of having the constraints file disappear after
the EOL, but it doesn't really solve the problem of having to update the
branches every time we open one. Having tox_install.sh figure out the
URL from the .gitreview file addresses that, but it may be too magic for
some folks. I don't know if we have generally agreed to let anything
other than git-review look at that file.

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] EOL tags and upper-constraints.txt in tox.ini

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2017-09-20 13:36:38 +:
> On 2017-09-20 08:41:14 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > Is there any reason not to use the published files for all regular
> > builds, instead of having tox.ini point to a git URL? Maybe only for
> > regular builds off of stable branches?
> 
> I'm not sure what you mean by "regular builds" but the plan as I

s/regular/non-CI/

> understood it was to switch from git.o.o URLs to releases.o.o URLs
> in the tox.ini files in all branches of projects already consuming
> constraints files that way.
> 
> As early as now (if we already had the publication job in place) we
> could update them all in master branches to retrieve something like
> https://releases.openstack.org/constraints/queens-upper-constraints.txt
> and then once stable/queens is branched in all repos (including the
> requirements repo), switch the job to begin publishing to a URL for
> rocky and push tox.ini updates to master branches switching the URL
> to that as early in the cycle as possible. Alternatively, we could
> publish master and queens copies (identical initially) and expect
> the master branch tox.ini files to refer to master but then switch
> them to queens on the stable/queens branch during RC. It just comes
> down to which the stable/requirements/release teams think makes the
> most sense from a procedural perspective.

We should think through which of those approaches is going to result in
the least amount of synchronization. We do have a window in which to
make changes in a given branch for consuming projects, but making the
relevant changes in the requirements repository seems like it could be
error prone, especially because we try to branch it after the other
repositories.

In any case, I like whichever approach can be made to work and will
leave bikeshedding on URLs paths to the reviews that implement the
one we pick.

If it would be useful, I would be happy to help advise anyone who
wants to modify the release automation scripts to handle this new
case.

Doug

> Remember also that the timing on this doesn't require extreme
> precision and there are no chicken-and-egg/catch-22 problems
> associated with updating because the URLs in question are merely a
> fallback method for when the constraints file is not already
> provided locally. In the CI system, we directly provide constraints
> files so that we can respect depends-on to requirements repo changes
> and the like, so in practice this fallback is primarily for the
> convenience of developers running tox locally.

__
OpenStack Development Mailing 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] [skip-level-upgrades][fast-forward-upgrades] PTG summary

[Doug Hellmann]

Excerpts from Lee Yarwood's message of 2017-09-20 14:29:12 +0100:
> My thanks again to everyone who attended and contributed to the
> skip-level upgrades track over the first two days of last weeks PTG.
> I've included a short summary of our discussions below with a list of
> agreed actions for Queens at the end.
> 
> tl;dr s/skip-level/fast-forward/g
> 
> https://etherpad.openstack.org/p/queens-PTG-skip-level-upgrades
> 
> Monday - Define and rename
> --
> 
> During our first session [1] we briefly discussed the history of the
> skip-level upgrades effort within the community and the various
> misunderstandings that have arisen from previous conversations around
> this topic at past events.
> 
> We agreed that at present the only way to perform upgrades between N and
> N+>=2 releases of OpenStack was to upgrade linearly through each major
> release, without skipping between the starting and target release of the
> upgrade.
> 
> This is contrary to previous discussions on the topic where it had been
> suggested that releases could be skipped if DB migrations for these
> releases were applied in bulk later in the process. As projects within
> the community currently offer no such support for this it was agreed to
> continue to use the supported N to N+1 upgrade jumps, albeit in a
> minimal, offline way.
> 
> The name skip-level upgrades has had an obvious role to play in the
> confusion here and as such the renaming of this effort was discussed at
> length. Various suggestions are listed on the pad but for the time being
> I'm going to stick with the basic `fast-forward upgrades` name (FFOU,
> OFF, BOFF, FFUD etc were all close behind). This removes any notion of
> releases being skipped and should hopefully avoid any further confusion
> in the future.
>  
> Support by the projects for offline upgrades was then discussed with a
> recent Ironic issue [2] highlighted as an example where projects have
> required services to run before the upgrade could be considered
> complete. The additional requirement of ensuring both workloads and the
> data plane remain active during the upgrade was also then discussed. It
> was agreed that both the `supports-upgrades` [3] and
> `supports-accessible-upgrades` [4] tags should be updated to reflect
> these requirements for fast-forward upgrades.
> 
> Given the above it was agreed that this new definition of what
> fast-forward upgrades are and the best practices associated with them
> should be clearly documented somewhere. Various operators in the room
> highlighted that they would like to see a high level document outline
> the steps required to achieve this, hopefully written by someone with
> past experience of running this type of upgrade.
> 
> I failed to capture the names of the individuals who were interested in
> helping out here. If anyone is interested in helping out here please
> feel free to add your name to the actions either at the end of this mail
> or at the bottom of the pad.
> 
> In the afternoon we reviewed the current efforts within the community to
> implement fast-forward upgrades, covering TripleO, Charms (Juju) and
> openstack-ansible. While this was insightful to many in the room there
> didn't appear to be any obvious areas of collaboration outside of
> sharing best practice and defining the high level flow of a fast-forward
> upgrade.
> 
> Tuesday - NFV, SIG and actions
> --
> 
> Tuesday started with a discussion around NFV considerations with
> fast-forward upgrades. These ranged from the previously mentioned need
> for the data plane to remain active during the upgrade to the restricted
> nature of upgrades in NFV environments in terms of time and number of
> reboots.
> 
> It was highlighted that there are some serious as yet unresolved bugs in
> Nova regarding the live migration of instances using SR-IOV devices.
> This currently makes the moving of workloads either prior to or during
> the upgrade particularly difficult.
> 
> Rollbacks were also discussed and the need for any best practice
> documentation around fast-forward upgrades to include steps to allow the
> recovery of environments if things fail was also highlighted.
> 
> We then revisited an idea from the first day of finding or creating a
> SIG for this effort to call home. It was highlighted that there was a
> suggestion in the packaging room to create a Deployment / Lifecycle SIG.
> After speaking with a few individuals later in the week I've taken the
> action to reach out on the openstack-sigs mailing list for further
> input.
> 
> Finally, during a brief discussion on ways we could collaborate and share
> tooling for fast-forward upgrades a new tool to migrate configuration
> files between N to N+>=2 releases was introduced [5]. While interesting
> it was seen as a more generic utility that could also be used between N
> to N+1 upgrades.  AFAIK the authors joined the Oslo room shortly after
> this session ended to gain more 

Re: [openstack-dev] [all] dashboard query changes since upgrade

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-09-19 09:35:26 -0400:
> On 09/19/2017 09:00 AM, Sean Dague wrote:
> > I've been iterating through gerrit dashboards this morning trying to
> > figure out why they no longer show any changes.
> > 
> > It looks like the query: label:Code-Review>=-2,self now matches changes
> > you haven't voted on. Previously (probably to a bug) this only matched
> > patches where you had a -2,-1,+1,+2 vote on them.
> > 
> > I'll be poking around today to figure out what the options are to get
> > equivalent functionality is out of the system, then update the gerrit
> > dashboards in gerrit-dash-creator based on that.
> 
> It appears that reviewedby:self actually works like we were hacking the
> old one to work. I've pushed through a bulk fix for most of the
> dashboards here - https://review.openstack.org/#/c/505247/
> 
> However local versions will need local patching.
> 
> -Sean
> 

I updated the TC review dashboard in https://review.openstack.org/505723
to produce:

https://review.openstack.org/#/dashboard/?foreach=project%3Aopenstack%2Fgovernance+is%3Aopen=Technical+Committee+Inbox+items=owner%3Aself+Vote+Items+I+have+not+voted+in+yet=topic%3Aformal%2Dvote+NOT+reviewedby%3Aself+NOT+owner%3Aself+Vote+Items=topic%3Aformal%2Dvote+Items+I+Haven%27t+Voted+On=path%3A%5Egoals%2F.%2A+NOT+reviewedby%3Aself+NOT+owner%3Aself+Items=path%3A%5Egoals%2F.%2A+Haven%27t+Voted+on+this+Draft=NOT+reviewedby%3Aself+NOT+owner%3Aself+at+Least+One+Objection=NOT+reviewedby%3Aself+NOT+owner%3Aself+label%3ACode%2DReview%3C%3D%2D1

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] [docs][ptls][install] Install guide vs. tutorial

[Doug Hellmann]

Excerpts from Sean McGinnis's message of 2017-09-19 16:57:40 -0500:
> > > On 9/19/17, 2:43 PM, "Eric Fried"  wrote:
> > >
> > > Alex-
> > > 
> > > Regardless of what the dictionary might say, people associate the 
> > > word
> > > "Tutorial" with a set of step-by-step instructions to do a thing.
> > > "Guide" would be a more general term.
> > > 
> > > I think of a "Tutorial" as being a *single* representative path 
> > > through
> > > a process.  A "Guide" could supply different alternatives.
> > > 
> > > I expect a "Tutorial" to get me from start to finish.  A "Guide" 
> > > might
> > > help me along the way, but could be sparser.
> > > 
> > > In summary, I believe the word "Tutorial" implies a very specific
> > > thing, so we should use it if and only if the doc is exactly that.
> 
> I don't think we'll get consensus on this, as my association with those words
> do not match Eric's. :)
> 
> For me, a tutorial is something that teaches. So after I've gone through a
> tutorial I would expect to have learned how installs work and would just know
> these things (with an occasional need to reference a few points) going 
> forward.
> 
> A guide to me is something that I know I will use whenever I need to do
> something. So for me, having an installation guide is what I would expect
> from this as every time I need to do a package based install, I am going to 
> pull
> up the guide to go through it.
> 
> Sean
> 

One of the other distinctions I remember being made when this came
up last week was that the documentation we have about installation
only includes information about one of many possible ways to install
the components that it covers.

What do other projects call the document that explains similar
information? Is there some sort of general consensus in the rest of the
open source community about what term to use?

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] EOL tags and upper-constraints.txt in tox.ini

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2017-09-20 12:30:59 +:
> On 2017-09-20 07:11:51 -0500 (-0500), Matthew Thode wrote:
> > On 17-09-20 13:35:44, Michal Pryc wrote:
> > > EOL releases for the nova component (checked neutron as well,
> > > possibly many other components) have wrong pointers to the
> > > upper-constraints.txt files as they are referencing
> > > stable/branch rather then branch-eol
> [...]
> > I think this is an error in our process that should be fixed
> > (newton is going EOL soon).
> [...]
> 
> As you may recall, at the PTG we also discussed a solution to this
> problem (under the auspices of solving the reverse scenario during
> the RC period for upcoming releases): specifically, publishing
> branch series constraints files to the releases site. EOL'd projects
> can refer to those at a static URL indefinitely rather than being at
> the mercy of branch/tag changes in the Git repository.

Is there any reason not to use the published files for all regular
builds, instead of having tox.ini point to a git URL? Maybe only for
regular builds off of 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] [Release-job-failures][ara] Release of openstack/ara failed

[Doug Hellmann]

Excerpts from jenkins's message of 2017-09-19 19:10:12 +:
> Build failed.
> 
> - ara-tarball 
> http://logs.openstack.org/89/89289c511c8c48c8409dd1fb997fc24e64d1dae6/release/ara-tarball/a75a87f/
>  : SUCCESS in 3m 17s
> - ara-tarball-signing 
> http://logs.openstack.org/89/89289c511c8c48c8409dd1fb997fc24e64d1dae6/release/ara-tarball-signing/f812ce9/
>  : FAILURE in 41s
> - ara-pypi-both-upload 
> http://logs.openstack.org/89/89289c511c8c48c8409dd1fb997fc24e64d1dae6/release/ara-pypi-both-upload/b3367cd/
>  : SUCCESS in 19s
> - hook-ara-rtfd 
> http://logs.openstack.org/89/89289c511c8c48c8409dd1fb997fc24e64d1dae6/release/hook-ara-rtfd/574ecf9/
>  : SUCCESS in 4s
> 

I think we're still under release freeze until the infra team gives us
the all-clear, but when that's done the ara team may want to re-release
this version (or at least coordinate with the infra team to re-run the
failed signing 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] Should we be using subprocess32?

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2017-09-14 16:18:35 -0600:
> On Tue, Sep 12, 2017 at 11:29:22AM -0700, Joshua Harlow wrote:
> > Hi folks,
> > 
> > I know there is a bunch of usage of subprocess in openstack and especially
> > since there is heavy usage of python 2.7 it made me wonder if we should try
> > to move to subprocess32 to avoid some of the bugs that seem to exist (maybe
> > distributors backported them?):
> > 
> > For example a major one (seems to be):
> > 
> > - https://github.com/google/python-subprocess32/commit/6ef1fea55
> > 
> > """Popen.wait() is now thread safe so that multiple
> > 
> >   threads may be calling wait() or poll() on a Popen instance at the same
> > time
> >   without losing the Popen.returncode value.
> > """
> > 
> > That one concerns me slightly, because I know that certain openstack
> > projects do use threads (and not eventlet monkey-patched green-thread
> > hybrids).
> > 
> > TLDR; should we (could we?) switch?
> 
> We could.  It wouldn't be hard to propose a change to the requirements
> repo and that could be used to test what breaks.
> 
> As to should we I'm not convinced.  It does give us a slightly more
> modern subprocess module but it hasn't been updated in nearly 2 years.
> I get that it's a backport from 3.3 which isn't getting updated but ...
> 
> Also it means adding something like:
> if os.name == 'posix' and sys.version_info[0] < 3:
> import subprocess32 as subprocess
> else:
> import subprocess
> 
> All over the place which isn't so great.
> 
> So overall I'm not certain it's worth it.
> 
> Yours Tony.

We might get more value by continuing the migration to python 3 so we
can drop python 2 support.

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] [docs][neutron] checking link integrity in the gate

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2017-09-06 19:00:05 +:
> On 2017-09-06 14:46:54 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > To be clear, if you can get Sphinx's linkchecker builder to work,
> > that's a great option for this. I just don't think you really want
> > to run it for every check or gate job that builds the docs.
> 
> Running a periodic pipeline job to find links as they become stale
> might be a viable option though, as long as someone is going to pay
> attention to failures for that.

Sure, that's a good option.

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] [docs][neutron] checking link integrity in the gate

[Doug Hellmann]

Excerpts from Alexandra Settle's message of 2017-09-06 17:47:44 +:
> 
> 
> On 9/6/17, 12:10 PM, "Doug Hellmann" <d...@doughellmann.com> wrote:
> 
> Excerpts from Doug Hellmann's message of 2017-09-05 13:53:40 -0400:
> > Excerpts from Boden Russell's message of 2017-09-05 11:25:34 -0600:
> > > 
> > > On 9/5/17 11:03 AM, Doug Hellmann wrote:
> > > > Is eventlet being initialized (or partially initialized) when a 
> module
> > > > from the application is imported for the auto-generated API
> > > > documentation?
> > > More than likely :)
> > > But even if they are, what's the fix/workaround?
> > > 
> > 
> > Ensure that it is fully initialized, or not initialized at all, I would
> > think. I'm sure Sphinx does not expect to be running under eventlet.
> > 
> > I see a comment in neutron's doc/source/conf.py about another issue with
> > eventlet and some of the test code. I would start by configuring pbr to
> > ignore the test code when generating class documentation and see if that
> > eliminates both problems. See "autodoc_tree_excludes" in
> > https://docs.openstack.org/pbr/latest/user/using.html#pbr for details.
> > 
> > If that doesn't help, then I would try to find a way to avoid
> > initializing eventlet at all. For example, set an environment variable
> > in doc/source/conf.py and then look for it in
> > neutron/common/eventlet_utils.py and skip the call to
> > eventlet.monkey_patch().
> > 
> > If neither of those options work, we can continue thinking of other
> > ideas.
> > 
> > Doug
> > 
> 
> Something to watch out for when using link check in CI: It's a path for
> someone outside of your team to break your gate, just by renaming a web
> page. It might be more useful to schedule regular manual runs and
> updates.
> 
> The docs team may have suggestions for how they handle that on the main
> docs.o.o site and the guides they manage.
> 
> Previously we have run a spider over our repo. Specifically, I know Andreas 
> has successfully used https://github.com/alecxe/broken-links-checker.git 
> 
> Hopefully this helps. I was thinking we needed to do the same thing over the 
> manuals repo now we have finalized most of the migration.
> 

To be clear, if you can get Sphinx's linkchecker builder to work, that's
a great option for this. I just don't think you really want to run it
for every check or gate job that builds the docs.

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] tracking policy community goal for queens

[Doug Hellmann]

Excerpts from Lance Bragstad's message of 2017-09-06 12:51:47 -0500:
> Hey all,
> 
> I reused some of Doug's doc-migration tooling to create a burndown chart

To give credit where due, I in turn copied that stuff from something
Sean Dague had for the API ref initiative.

Doug

> specifically for policy work in Queens [0][1]. As some of you might
> know, I've attempted to update projects that are not impacted by the
> goal [2]. Another reminder that we will be having two sessions dedicated
> to helping projects accomplish the goal this upcoming Monday and Tuesday
> at the PTG (still unsure about room assignment) [3]. The first session
> will be Monday from 9:00 to 12:00. The second session will be Tuesday
> afternoon from 14:30 to 17:00. We have a dedicated etherpad for tracking
> policy-and-docs-in-code work [4], so don't hesitate to add your name to it.
> 
> If your project is already working on moving policy [0], please be sure
> to track it using the topic suggested in the goal
> (policy-and-docs-in-code). The burndown chart looks for patches matching
> that topic.
> 
> Thanks!
> 
> 
> [0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
> [1] https://www.lbragstad.com/policy-burndown/
> [2]
> https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:policy-and-docs-in-code
> [3] https://etherpad.openstack.org/p/keystone-queens-ptg
> [4] https://etherpad.openstack.org/p/policy-queens-ptg

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

Re: [openstack-dev] [docs][neutron] checking link integrity in the gate

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-09-05 13:53:40 -0400:
> Excerpts from Boden Russell's message of 2017-09-05 11:25:34 -0600:
> > 
> > On 9/5/17 11:03 AM, Doug Hellmann wrote:
> > > Is eventlet being initialized (or partially initialized) when a module
> > > from the application is imported for the auto-generated API
> > > documentation?
> > More than likely :)
> > But even if they are, what's the fix/workaround?
> > 
> 
> Ensure that it is fully initialized, or not initialized at all, I would
> think. I'm sure Sphinx does not expect to be running under eventlet.
> 
> I see a comment in neutron's doc/source/conf.py about another issue with
> eventlet and some of the test code. I would start by configuring pbr to
> ignore the test code when generating class documentation and see if that
> eliminates both problems. See "autodoc_tree_excludes" in
> https://docs.openstack.org/pbr/latest/user/using.html#pbr for details.
> 
> If that doesn't help, then I would try to find a way to avoid
> initializing eventlet at all. For example, set an environment variable
> in doc/source/conf.py and then look for it in
> neutron/common/eventlet_utils.py and skip the call to
> eventlet.monkey_patch().
> 
> If neither of those options work, we can continue thinking of other
> ideas.
> 
> Doug
> 

Something to watch out for when using link check in CI: It's a path for
someone outside of your team to break your gate, just by renaming a web
page. It might be more useful to schedule regular manual runs and
updates.

The docs team may have suggestions for how they handle that on the main
docs.o.o site and the guides they manage.

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] [docs][neutron] checking link integrity in the gate

[Doug Hellmann]

Excerpts from Boden Russell's message of 2017-09-05 11:25:34 -0600:
> 
> On 9/5/17 11:03 AM, Doug Hellmann wrote:
> > Is eventlet being initialized (or partially initialized) when a module
> > from the application is imported for the auto-generated API
> > documentation?
> More than likely :)
> But even if they are, what's the fix/workaround?
> 

Ensure that it is fully initialized, or not initialized at all, I would
think. I'm sure Sphinx does not expect to be running under eventlet.

I see a comment in neutron's doc/source/conf.py about another issue with
eventlet and some of the test code. I would start by configuring pbr to
ignore the test code when generating class documentation and see if that
eliminates both problems. See "autodoc_tree_excludes" in
https://docs.openstack.org/pbr/latest/user/using.html#pbr for details.

If that doesn't help, then I would try to find a way to avoid
initializing eventlet at all. For example, set an environment variable
in doc/source/conf.py and then look for it in
neutron/common/eventlet_utils.py and skip the call to
eventlet.monkey_patch().

If neither of those options work, we can continue thinking of other
ideas.

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] [docs][neutron] checking link integrity in the gate

[Doug Hellmann]

Excerpts from Boden Russell's message of 2017-09-05 10:51:09 -0600:
> We've (neutron) run into a few cases where our doc links become
> outdated/invalid and are dead. These dead links are not detected in the
> doc build today, but is something we might be interested in enabling.
> 
> I'm no sphinx expert, but best I can tell that's done with the
> "linkcheck" builder [1]. I've tried munking with this, but sporadically
> get an eventlet error [2] followed by an indefinite hang; I've yet to
> find a way around this even if setting linkcheck_workers to 1.
> 
> Also note that most project's doc/Makefile have a linkcheck target, but
> that's also failing.
> 
> Does anyone know the best way to have our links checked during the doc
> build?
> 
> Thanks
> 
> [1]
> http://www.sphinx-doc.org/en/stable/config.html#options-for-the-linkcheck-builder
> [2] http://paste.openstack.org/show/620423/
> 

Is eventlet being initialized (or partially initialized) when a module
from the application is imported for the auto-generated API
documentation?

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] [docs] adopting whereto as official tool maintained by docs team

[Doug Hellmann]

As part of the work for the doc-migration project this cycle, we have
expanded the way we use redirects to allow project teams to have
htaccess files in tree. Since redirects can be tricky to test without a
live server, I put together a tool that we can use in CI to do some
minimal validation. It takes as input an htaccess file and another file
of test values, and reports if any test path does not redirect in the
expected way or if any redirect rule is untested. I'm sure we can
improve on it from there.

The tool is already being used to test the htaccess file in
openstack-manuals. We need to add it to the requirements list before
we can use it in other builds that follow the requirements management
processes[1].

I would also like the docs team to take up maintenance of the tool so
I'm not doing it on my own [2]. If anyone has any concerns about doing
that, please let me know.

Doug

[1] https://review.openstack.org/499584
[2] https://review.openstack.org/499581

__
OpenStack Development Mailing 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] [relmgt] Libraries published to pypi with YYYY.X.Z versions

[Doug Hellmann]

Excerpts from Claudiu Belu's message of 2017-08-29 14:09:32 +:
> Hello,
> 
> As many of you know, during Kilo, the neutron vendor decomposition happened, 
> which lead to the birth of many networking-* libraries, including 
> networking-hyperv. When it was time for us to make a release for that cycle, 
> pretty much every networking-* project followed the release version number at 
> that time, which was 2015.1.0. After Kilo, the versioning changed to the 
> current format.
> 
> networking-hyperv currently contains the "hyperv" mechanism_driver, which is 
> needed in order to bind neutron ports to Hyper-V compute nodes using 
> neutron-hyperv-agent L2 agents.
> 
> Now, my main issue is that networking-hyperv==2015.1.0 is currently on Pypi, 
> and whenever someone upgrades networking-hyperv through pip (pip install -U 
> networking-hyperv), it "upgrades" to 2015.1.0. And even if it isn't already 
> installed, networking-hyperv==2015.1.0 is installed, as that is considered 
> the "latest" version:
> 
> (test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv
> 
> (test) ubuntu@ubuntu:~$ pip install networking-hyperv
> ...
> (test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv
> networking-hyperv==2015.1.0
> 
> This is a common pitfall for people using pip to install / upgrade 
> networking-hyperv. It's actually become a ritual for new developers to 
> mistakenly install the "latest" version. :)
> 
> Now, my question is: could we / should we unpublish the 2015.1.0 version?
> 
> [1] Kolla using pip package "networking-hyperv>=5.0.0,<6.0.0"  
> https://review.openstack.org/#/c/498409/1
> [1] #openstack-release: 
> http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T08:19:28
> [2] #openstack-release: 
> http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-29.log.html#t2017-08-29T13:20:36
> 
> 
> Best regards,
> 
> Claudiu Belu

Thierry mentioned in #openstack-release that this issue did come
up when we originally changed to using SemVer. However, at that
time we only had service projects using date-based versions and we
did not support installing those from PyPI. Distribution packages
updated their epoch setting, which allowed them to reset the rest
of the version number to an apparently lower value and still have
it considered as newer.  Python packaging doesn't have that sort
of ability, unfortunately.

If that 2015 version is no longer maintained, then deleting it from
PyPI may be the most effective way to avoid this particular support
issue, even though that is normally not something we recommend.

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] [oslo] schedule for Denver PTG is ready !

[Doug Hellmann]

Excerpts from ChangBo Guo's message of 2017-08-28 23:14:05 +0800:
> Please check  for the draft in [1], we can adjust if you have conflicts
> with other discussions.
> 
> We have specific cross projects coding event  in the Tuesday afternoon, for
> more details please
> check [2] and [3],  please join us if you're free from 1:00 PM to 3: PM on
> Tuesday.
> 
> [1] https://etherpad.openstack.org/p/oslo-ptg-queens
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2017-August/121345.html
> [3] https://etherpad.openstack.org/p/oslo-queens-tasks
> 

I think we can drop the discussion of retiring oslosphinx from the
schedule. We had no objections, and the way forward is clear (see the
other thread [4] for details).

Doug

[4] http://lists.openstack.org/pipermail/openstack-dev/2017-August/121564.html

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

Re: [openstack-dev] [oslo] scheduling oslosphinx for retirement at the start of queens

[Doug Hellmann]

> On Jul 10, 2017, at 9:10 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> 
> Oslo team,
> 
> With all documentation now moving to use the openstackdocs theme,
> I propose that we retire the oslosphinx repository during Queens.
> We should go ahead and create the stable/pike branch at the end of
> this cycle, so that we have a way to deal with bugs in existing
> pike releases, but I think we can retire the repository at any point
> after that.

After looking into the retirement process, and discussing it with fungi, I 
think we’re going to have to wait to do anything for now. 

It will be complicated to remove the contents of the master branch now without 
following the full retirement process, and that will make it impossible for us 
to maintain stable releases for the library through the end of Pike's support 
lifetime (because the gate jobs will all be turned off). So for now 
https://review.openstack.org/#/c/498543/1 marks the library as obsolete and 
https://bugs.launchpad.net/oslosphinx/+bug/1713543 will help us remember to 
follow the retirement process later.

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] [docs] Re: Install guide testing

[Doug Hellmann]

Excerpts from Andreas Jaeger's message of 2017-08-25 16:05:41 +0200:
> On 2017-08-25 15:40, Roger Luethi wrote:
> > I don't know what will get changed or created until the release, but
> > what I can find right now in terms of installation instructions is this:
> > 
> > https://docs.openstack.org/pike/install/
> > 
> > leading to the "OpenStack Installation Tutorial":
> > 
> > https://docs.openstack.org/install-guide/
> > 
> > plus many project-specific instructions:
> > 
> > https://docs.openstack.org//pike/install/
> > 
> > The OpenStack Installation Tuturial is labelled "Installation Guide
> > 15.0", same as Ocata (Newton was 0.1). The URL is not versioned, even
> > though there will be changes between releases (the instructions for
> > enabling the OpenStack repository are updated every release, and there
> > are bound to be other differences). I wonder how that will be handled
> > in the future.
> 
> The introductory document needs little changes for each release, it will
> cover several releases. I just pushed two changes up to update that
> document.

Right. We should clean up the version number (either update it or not
show it) but we tried to retain only content that would change
very little or for which we could easily add operating system
version-specific conditionals to the steps.

> > I have not read all of the new "OpenStack Installation Tutorial", but
> > looking at the table of contents, there seems to be a gap between
> > "Environment"->"Memcached" and "Launch an instance". Where do we tell the
> > readers which project-specific guides to follow, and in what order? Both
> > pieces of information are rather crucial for a successful installation.
> 
> https://review.openstack.org/497813

I've +2ed that patch as a good start. We've talked about documenting
some "constellation" configurations for setting up clouds with
different purposes running different services. That page may be a
good place to do that, or it may just be that we link to those
constellations when they are available elsewhere. We can figure out
the best way to do that when someone volunteers to do the work.

> > I expect users will find confusing that clicking the "Next" arrow on a
> > distro-specific page (say, [1]) will often take them to the same page,
> > just for a different distro. In the keystone install-guide, clicking on
> > the Next arrow can result in skipped pages (depending on the distro,
> > e.g. [2]). I realize that distro-specific instructions are not easily
> > implemented with the new setup, but maybe the doc team could suggest
> > a way to handle distro-specific paths for all projects.
> 
> 
> We discussed this several times and found no good solution. In
> openstack-manuals we build several documents - this would complicate the
> project repos significantly. Also, there's so much duplication that
> skipping over distros is just a small part,

Yes, we're still open to suggestions but in the absence of a solution
we've placed a higher priority on the other remaining work.

Doug

> 
> Andreas
> 
> > Roger
> > 
> > [1] https://docs.openstack.org/install-guide/environment-messaging-obs.html
> > [2] https://bugs.launchpad.net/keystone/+bug/1712335
> > 
> > __
> > OpenStack Development Mailing 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] [docs] [ptls] Install guide testing

[Doug Hellmann]

Excerpts from Alexandra Settle's message of 2017-08-25 08:57:51 +:
> Hi everyone,
> 
> The documentation team is searching for volunteers to help test and verify 
> the OpenStack installation instructions here: 
> https://docs.openstack.org/install-guide/
> 
> Previously this action has been undertaken by a series of volunteers, mostly 
> from the documentation team. However due to the migration, and a significant 
> drop in contributors, we are now seeking new individuals to help us complete 
> this task.
> 
> We will be tracking any work here: 
> https://wiki.openstack.org/wiki/Documentation/PikeDocTesting You can see what 
> we have previously done for testing here: 
> https://wiki.openstack.org/wiki/Documentation/OcataDocTesting
> 
> PTLs of cinder/keystone/horizon/neutron/nova/glance – Previously the 
> documentation team performed the testing tasks for your respective projects 
> as they lived within the openstack-manuals repo. We appreciate that you may 
> or may not have the resources to continue this effort, but it would be great 
> if your teams are able. Please let me know if you are able to so we can 
> verify the instructions of these projects :)
> 
> Thanks,
> 
> Alex

Thanks for starting this thread, Alex.  I want to add a little
background for folks only now catching up with the state of the
migration initiative and documentation for Pike.

At the start of the Pike cycle we lost most of our technical writers.
By the time of the summit in Boston, it wasn't clear (at least to
me) if we would have *any* writers left at the start of the Queens
cycle.  Luckily it seems we will, but without knowing that a few
months ago I encouraged the docs team to make some decisions about
prioritizing work that will leave us in a less than ideal, but
recoverable, state for Pike.

We started by emphasizing the need to move all of the existing
content to a new home so it could be maintained by more owners --
this was the aspect of the migration spec that most of you will be
familiar with, and with over 1100 reviews tagged 'doc-migration' I
think it's safe to say this was the bulk of the work.

We did not completely address two important aspects of managing that
content after the migration: translations and testing.

We looked into translations far enough to know that it would be
possible to set up the jobs and build project docs in multiple
languages. We're already doing this for some other sphinx-based
docs, so we would have a pattern to work from.

I had hoped that if we had time after the import was done, we could
develop a plan for end-of-cycle-testing. That didn't happen, so we
will have to come up with a plan and execute it during Queens. No
one thinks this is a good outcome, but it's where we are. If you're
interested in helping with that work, I expect it will be a big
part of what the docs team discusses at the PTG. Spoiler alert: I
will be advocating distributing the responsibility for verifying
instructions to the project teams.

Doug

PS - By the way, most projects are finished with the migration, but
I see on the dashboard[1] that we still have quite a few open reviews
and a few missing pages. At this point, the missing docs will need
to be backported to the stable/pike branches for those projects.
Let me know if you need help approving things in the stable branches.

[1] https://doughellmann.com/doc-migration/

__
OpenStack Development Mailing 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] [docs] Updating the docs team mission statement

[Doug Hellmann]

Excerpts from Jay S Bryant's message of 2017-08-22 11:06:37 -0500:
> 
> On 8/22/2017 7:30 AM, Doug Hellmann wrote:
> > Excerpts from Doug Hellmann's message of 2017-08-08 08:11:25 -0400:
> >> Excerpts from Thierry Carrez's message of 2017-08-08 12:28:58 +0200:
> >>> Petr Kovar wrote:
> >>>> Hi all,
> >>>>
> >>>> With the core docs suite moving from openstack-manuals to individual
> >>>> project repos as per
> >>>> http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html,
> >>>> it's also time to update the docs team mission statement from
> >>>> https://governance.openstack.org/tc/reference/projects/documentation.html.
> >>>>
> >>>> What are everybody's thoughts on what should the new mission statement
> >>>> say now that most OpenStack docs maintenance is in the hands of project
> >>>> teams?
> >>>>
> >>>> One idea is for the docs team to act as a focused group of editors and
> >>>> maintain a common set of guidelines, recommended practices (style
> >>>> guidelines come to mind, for instance), and requirements (such as a 
> >>>> common
> >>>> docs and publishing structure shared across projects).
> >>> I would say something like:
> >>>
> >>> The docs team provides guidance, assistance, tooling, and style guides
> >>> enabling OpenStack project teams to produce consistent, accurate, and
> >>> high-quality documentation.
> >>>
> >> Thanks for starting this thread, Petr.
> >>
> >> To make it easier to compare, here's the current mission statement:
> >>
> >>Provide documentation for core OpenStack projects to promote
> >>OpenStack.  Develop and maintain tools and processes to ensure
> >>quality, accurate documentation. Treat documentation like OpenStack
> >>code.
> >>
> >> Thierry's suggestion highlights some of the changes I see coming
> >> for the docs team. I would like to hear from some of the other team
> >> members about what they think about that.
> >>
> >> Doug
> > This thread died out, but I think it's important that we make some
> > progress on the discussion before the PTG because the outcome is
> > going to influence the work we do there.
> >
> > One way we could approach it is to make a list of all of the things
> > that the team is currently doing (or has been doing, up to Pike)
> > and then review that list to consider which of those things, if the
> > team was not already doing them, you would be willing to start doing
> > today.  That should establish a pattern for the types of tasks and
> > initiatives the team thinks it can manage, and help us focus the
> > mission statement.
> >
> > So, what does the docs team "do" or "make" today?
> >
> > 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
> Doug,
> 
> I think this is a good idea.  Rather than writing a mission statement 
> and try to get what we do to fit it, we should look at what everyone is 
> doing and can do and then work to craft the statement from that.
> 
> One important part in the process, however, would be to look at how that 
> compares to what was previously being done and make sure that there 
> aren't gaps.  It is an opportunity to make sure we don't let anything 
> slip through the cracks.
> 
> Jay
> 

It's also an opportunity to identify things that should be dropped, or
moved to another team. But yes, let's start by understanding what's
actually happening today.

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][oslo][all] Clean up oslo deprecated stuff !

[Doug Hellmann]

Excerpts from ChangBo Guo's message of 2017-08-22 20:44:18 +0800:
> 2017-08-22 20:37 GMT+08:00 Doug Hellmann <d...@doughellmann.com>:
> 
> > Excerpts from ChangBo Guo's message of 2017-08-22 15:24:44 +0800:
> > > Hi ALL,
> > >
> > > We discussed a little about how to avoid breaking consuming projects'
> > gate
> > > in oslo weekly meeting last week.  The easy improvement is that clean up
> > > deprecated stuff in oslo at the beginning of Queens.  I collected
> > > deprecated stuff  in [1].  This need Oslo team and other team work
> > > toghether. I think we can start the work when cycle Queens is open. I
> > also
> > > reserved a room in PTG
> > > for 2 hours to do hacking.[2]
> > >
> > >
> > > [1] https://etherpad.openstack.org/p/oslo-queens-tasks
> > > [2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
> > >
> >
> > Cleaning up some of this technical debt is a great idea for Queens!
> >
> > What do you think about using a common gerrit topic to make those
> > reviews easy to find across the repository?
> >
>   yeah, that's helpful to track the reviews,  what about the topic 
> 'oslo-debt-cleanup'?

That works great. I can add the query for that topic to my regular
review routine.

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][oslo][all] Clean up oslo deprecated stuff !

[Doug Hellmann]

Excerpts from ChangBo Guo's message of 2017-08-22 15:24:44 +0800:
> Hi ALL,
> 
> We discussed a little about how to avoid breaking consuming projects' gate
> in oslo weekly meeting last week.  The easy improvement is that clean up
> deprecated stuff in oslo at the beginning of Queens.  I collected
> deprecated stuff  in [1].  This need Oslo team and other team work
> toghether. I think we can start the work when cycle Queens is open. I also
> reserved a room in PTG
> for 2 hours to do hacking.[2]
> 
> 
> [1] https://etherpad.openstack.org/p/oslo-queens-tasks
> [2] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
> 

Cleaning up some of this technical debt is a great idea for Queens!

What do you think about using a common gerrit topic to make those
reviews easy to find across the repository?

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][ptl] tools for creating new releases

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2017-08-22 11:38:10 +0200:
> On 08/22/2017 11:34 AM, Dmitry Tantsur wrote:
> > On 08/21/2017 09:15 PM, Doug Hellmann wrote:
> >> Excerpts from Doug Hellmann's message of 2017-08-21 11:21:59 -0400:
> >>> Excerpts from Dmitry Tantsur's message of 2017-08-15 14:11:05 +0200:
> >>>> On 08/08/2017 03:30 PM, Doug Hellmann wrote:
> >>>>> We realized recently that we haven't publicized some of the tools
> >>>>> in the releases repository very well. One tool that will be useful
> >>>>> this week as you prepare your release candidates is the 'new-release'
> >>>>> command, which edits a deliverable file to add a new release from
> >>>>> HEAD of the given branch, automatically computing the next verison
> >>>>> number based on the inputs.
> >>>>>
> >>>>> Use the ``venv`` tox environment to run the tool, like this:
> >>>>>
> >>>>>  $ tox -e venv -- new-release SERIES DELIVERABLE TYPE
> >>>>>
> >>>>> The SERIES value should be the release series, such as "pike".
> >>>>>
> >>>>> The DELIVERABLE value should be the deliverable name, such as
> >>>>> "oslo.config" or "cinder".
> >>>>>
> >>>>> The TYPE value should be one of "bugfix", "feature", "major",
> >>>>> "milestone", or "rc".
> >>>>>
> >>>>> If the most recent release of cinder during the pike series is
> >>>>> 11.0.0.0b3 then running:
> >>>>>
> >>>>>  $ tox -e venv -- new-release pike cinder rc
> >>>>
> >>>> On systems with Python 3 by default this fails on installing 
> >>>> lazr.restfulclient.
> >>>> I think we should add
> >>>>
> >>>>basepython = python2
> >>>>
> >>>> for now.
> >>
> >> I wonder if you have an old copy of the releases repo. In master we
> >> explicitly set basepython to python3 and lazr.restfulclient is no longer
> >> a dependency.
> > 
> > Updated to latest HEAD, removed *.pyc files and .tox. Still getting:
> > 
> > Obtaining file:///home/dtantsur/Projects/releases
> > Requirement already up-to-date: pbr>=1.6 in 
> > ./.tox/list-changes/lib/python3.6/site-packages (from 
> > releases==0.0.1.dev3083)
> > Collecting lazr.restfulclient==0.13.1 (from releases==0.0.1.dev3083)
> >Using cached lazr.restfulclient-0.13.1.tar.gz
> >  Complete output from command python setup.py egg_info:
> >  Traceback (most recent call last):
> >File "", line 1, in 
> >File "/tmp/pip-build-hhi229rh/lazr.restfulclient/setup.py", line 19, 
> > in 
> > 
> >  import ez_setup
> >File "/tmp/pip-build-hhi229rh/lazr.restfulclient/ez_setup.py", line 
> > 98
> >  except pkg_resources.VersionConflict, e:
> >  ^
> >  SyntaxError: invalid syntax
> > 
> > I cannot find where this dependency comes from, still investigating.
> 
> And here is what helped: rm -rf *.egg-info/
> 
> I suspect it was coming from stale directory releases.egg-info (currently we 
> have openstack_releases.egg-info instead). I'm not sure why it was picked..

Yes, that's odd, but I'm glad you found the problem.

I see you're running with python 3.6. I've only tested with 3.5 so far,
so I would appreciate bug reports or patches if you find issues.

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] [docs] Updating the docs team mission statement

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-08-08 08:11:25 -0400:
> Excerpts from Thierry Carrez's message of 2017-08-08 12:28:58 +0200:
> > Petr Kovar wrote:
> > > Hi all,
> > > 
> > > With the core docs suite moving from openstack-manuals to individual
> > > project repos as per
> > > http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html,
> > > it's also time to update the docs team mission statement from
> > > https://governance.openstack.org/tc/reference/projects/documentation.html.
> > > 
> > > What are everybody's thoughts on what should the new mission statement
> > > say now that most OpenStack docs maintenance is in the hands of project
> > > teams?
> > > 
> > > One idea is for the docs team to act as a focused group of editors and
> > > maintain a common set of guidelines, recommended practices (style
> > > guidelines come to mind, for instance), and requirements (such as a common
> > > docs and publishing structure shared across projects).
> > 
> > I would say something like:
> > 
> > The docs team provides guidance, assistance, tooling, and style guides
> > enabling OpenStack project teams to produce consistent, accurate, and
> > high-quality documentation.
> > 
> 
> Thanks for starting this thread, Petr.
> 
> To make it easier to compare, here's the current mission statement:
> 
>   Provide documentation for core OpenStack projects to promote
>   OpenStack.  Develop and maintain tools and processes to ensure
>   quality, accurate documentation. Treat documentation like OpenStack
>   code.
> 
> Thierry's suggestion highlights some of the changes I see coming
> for the docs team. I would like to hear from some of the other team
> members about what they think about that.
> 
> Doug

This thread died out, but I think it's important that we make some
progress on the discussion before the PTG because the outcome is
going to influence the work we do there.

One way we could approach it is to make a list of all of the things
that the team is currently doing (or has been doing, up to Pike)
and then review that list to consider which of those things, if the
team was not already doing them, you would be willing to start doing
today.  That should establish a pattern for the types of tasks and
initiatives the team thinks it can manage, and help us focus the
mission statement.

So, what does the docs team "do" or "make" today?

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][ptl] tools for creating new releases

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-08-21 11:21:59 -0400:
> Excerpts from Dmitry Tantsur's message of 2017-08-15 14:11:05 +0200:
> > On 08/08/2017 03:30 PM, Doug Hellmann wrote:
> > > We realized recently that we haven't publicized some of the tools
> > > in the releases repository very well. One tool that will be useful
> > > this week as you prepare your release candidates is the 'new-release'
> > > command, which edits a deliverable file to add a new release from
> > > HEAD of the given branch, automatically computing the next verison
> > > number based on the inputs.
> > > 
> > > Use the ``venv`` tox environment to run the tool, like this:
> > > 
> > > $ tox -e venv -- new-release SERIES DELIVERABLE TYPE
> > > 
> > > The SERIES value should be the release series, such as "pike".
> > > 
> > > The DELIVERABLE value should be the deliverable name, such as
> > > "oslo.config" or "cinder".
> > > 
> > > The TYPE value should be one of "bugfix", "feature", "major",
> > > "milestone", or "rc".
> > > 
> > > If the most recent release of cinder during the pike series is
> > > 11.0.0.0b3 then running:
> > > 
> > > $ tox -e venv -- new-release pike cinder rc
> > 
> > On systems with Python 3 by default this fails on installing 
> > lazr.restfulclient. 
> > I think we should add
> > 
> >   basepython = python2
> > 
> > for now.

I wonder if you have an old copy of the releases repo. In master we
explicitly set basepython to python3 and lazr.restfulclient is no longer
a dependency.

Doug

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

Re: [openstack-dev] [ironic] [release] [stable] pike release

[Doug Hellmann]

Excerpts from Sam Betts (sambetts)'s message of 2017-08-21 10:01:35 +:
> Quick reply with my thoughts in-line.
> 
> Sam
> 
> On 21/08/2017, 10:13, "Dmitry Tantsur"  wrote:
> 
> (adding the release and stable team just for their information)
> 
> Thanks Julia and everyone for handling this situation while I was out. 
> More 
> comments inline.
> 
> On 08/17/2017 07:13 PM, Julia Kreger wrote:
> > Greetings everyone!
> > 
> > As some of you may have noticed, we released ironic 9.0.0 today. But
> > wait! There is more!
> > 
> > We triggered this release due to a number of issues, one of which was
> > that we learned that we needed the stable/pike branch for our grenade
> > jobs to execute properly. This was not done previously because
> > Ironic’s release model is incompatible with making release candidate
> > releases.
> 
> Yep :( So, I think the lesson to learn is to create our stable/XXX branch 
> at the 
> same time as the other projects. We kind of knew that already, but did 
> not 
> anticipate such a huge breakage so quickly. I suggest we don't try it in 
> Queens :)

Yes, we do try to encourage teams to branch around that RC1 period when
the milestone-based projects branch to avoid these sorts of issues.

> 
> Now, with that in place we still have two options:
> 1. A conservative one - make the branching the hard feature freeze, 
> similar to 
> other projects. We may start with a soft freeze at around M3, and just 
> move into 
> Queens when stable/queens is created. As that point, what is out - is out.
> 2. Alternative - continue making selected feature backports until the 
> final 
> freeze roughly one week before the final release. This kind of 
> contradicts 
> calling a branch "stable" though.

I see that Ironic didn't really take advantage of the
cycle-with-intermediary model by preparing any intermediary releases
during pike, so perhaps it would be simplest to change the release
model to cycle-with-milestones and align with the other projects
that way?

> 
> I don't have a strong opinion, but I'm slightly more in favor of the 
> conservation option #1 to avoid confusing people and complicating the 
> process.
> 
> Thoughts?
> 
> Personally, I think option 2 still makes sense, and it aligns us closely with 
> the process in the other projects, the difference between us and them is that 
> their branch is cut using a release candidate instead of a real release. The 
> act of backporting things into the stable branch and then re-releasing is the 
> same though.
> 
> Another alternative I wonder if we should consider is cutting our branch 
> earlier in the cycle, when we make our first intermediary release, and then 
> finding out if we can sync the branches at each release time instead of 
> backporting everything. E.g. git checkout stable/X, git reset –hard 
> origin/master or git rebase master, git push. Doing this will allow us to 
> retain the git history and same commit ids from master to stable/X until 
> master stops developing stable/X and moves on to stable/X+1. I think another 
> advantage of this is it also allows people to find and use our latest 
> intermediary releases easier. But I don’t know how nicely this would work 
> with all the tooling etc the release team has in place.

I don't think that is something the release team would be prepared
to support. We're trying to avoid having every project handling
releases and branches in their own way, because it makes tooling
that much harder to deal with.

> 
> > 
> > Once we’ve confirmed that our grenade testing is passing, we will back
> > port patches we had previously approved, but that had not landed, from
> > master to stable/pike.
> 
> ++ I've approved a few patches already, and will continue approving them 
> today.
> 
> > 
> > As a result, please anticipate Ironic’s official Pike release for this
> > cycle to be 9.1.0, if the stars, gates, and job timeouts align with
> > us.
> 
> Right, I think we will request it on Wednesday, to allow a bit more time 
> to test 
> our newly populated not-so-stable stable/pike :)
> 
> > 
> > If there are any questions, please feel free to stop by
> > #openstack-ironic. We have also been keeping our general purpose
> > whiteboard[1] up to date, you can see our notes regarding our current
> > plan starting at line 120, and notes regarding gate failures and
> > issues starting at line 37.
> > Thanks!
> > 
> > -Julia
> > 
> > [1]: https://etherpad.openstack.org/p/IronicWhiteBoard
> > 
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > 

Re: [openstack-dev] [release][ptl] tools for creating new releases

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2017-08-15 14:11:05 +0200:
> On 08/08/2017 03:30 PM, Doug Hellmann wrote:
> > We realized recently that we haven't publicized some of the tools
> > in the releases repository very well. One tool that will be useful
> > this week as you prepare your release candidates is the 'new-release'
> > command, which edits a deliverable file to add a new release from
> > HEAD of the given branch, automatically computing the next verison
> > number based on the inputs.
> > 
> > Use the ``venv`` tox environment to run the tool, like this:
> > 
> > $ tox -e venv -- new-release SERIES DELIVERABLE TYPE
> > 
> > The SERIES value should be the release series, such as "pike".
> > 
> > The DELIVERABLE value should be the deliverable name, such as
> > "oslo.config" or "cinder".
> > 
> > The TYPE value should be one of "bugfix", "feature", "major",
> > "milestone", or "rc".
> > 
> > If the most recent release of cinder during the pike series is
> > 11.0.0.0b3 then running:
> > 
> > $ tox -e venv -- new-release pike cinder rc
> 
> On systems with Python 3 by default this fails on installing 
> lazr.restfulclient. 
> I think we should add
> 
>   basepython = python2
> 
> for now.

We should definitely address that. We need lazr.restfulclient to
talk to Launchpad, and we need that in the release scripts in
release-tools but I don't think we need it in the releases repo. Maybe
we can remove the dependency, or set it up so it is only installed when
python 2 is used?

Happy-to-review-patches-ly,
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 Thierry Carrez's message of 2017-08-17 09:42:15 +0200:
> Kendall Nelson wrote:
> > Hello Everyone!
> > 
> > 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:
> > [...]
> 
> Congratulations to all the elected PTLs, new names and returning ones!
> 
> The PTLs are at the same time a steward for their team, facilitating the
> work of their teammates, an ambassador for the project, communicating
> the work being done to the outside world, and a default contact point
> for anyone having questions about a given team.
> 
> That can be daunting, especially for larger teams. Don't hesitate to
> delegate as much of those tasks as you can!
> 
> Thank you again for your help. Let's make Queens a great cycle!
> 

And if any new PTLs would like advice or tips, please get in touch
with a former PTL, TC member, or other community leader. We're here
to help make your lives easier.

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][oslo.config][ansible][tripleo][kolla][ptg] Pluggable drivers and protect plaintext secrets

[Doug Hellmann]

Excerpts from Raildo Mascena de Sousa Filho's message of 2017-08-17 12:16:15 
+:
> Hi all,
> 
> Should we reserve a room in the extra session ethercalc [0
> ] or we
> already have a time slot scheduled for that discussion?
> 
> [0] https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms

I think this topic was on Emilien's list for TripleO. Would the other
groups mind if the TripleO team hosts the discussion in their room? That
would save the more limited reserveable rooms for discussions that don't
have an obvious host.

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][docs] O search where art thou?

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-08-11 09:10:59 -0400:
> On 08/11/2017 08:50 AM, Anne Gentle | Just Write Click wrote:
> > Yeah, I need to circle back in the theme work to make sure both search 
> > scopes are available. My prior attempt had some wonky CSS debugging and I 
> > needed to separate patches more.
> > 
> > I'll put up another patch to the theme today to bring in the Sphinx search 
> > in the sidebar as it was before.
> > 
> > I'm not sure how to solve the sort problem Sean notes, would like help 
> > there.
> > Hope this helps - 
> > Anne
> 
> If we have the option to use sphinx baked in search, instead of the
> bounce out to google swift_search that's being installed, it's all
> solved. The sphinx search builds the search terms into a compiled
> javascript file on build, and will only link to content in the tree.
> 
> I think the thing to do is probably enhance openstackdocstheme to have
> some toggle of "local_search = True" which would get rid of swift_search
> and just use baked in local search. Then on a per site basic people
> could turn it on / off, and openstackdocstheme could still be used for
> sites that want global search.
> 
> -Sean
> 

We could also limit the global search to one of the top-level pages in
the openstack-manuals repo and have the theme link to a search page
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] [docs] importing openstack-manuals questions, looking for strategies

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-08-09 09:39:55 -0400:
> On 08/09/2017 09:24 AM, Sean Dague wrote:
> > On 08/09/2017 09:19 AM, Doug Hellmann wrote:
> >> Excerpts from Sean Dague's message of 2017-08-08 17:01:29 -0400:
> >>> When trying to import
> >>> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/compute/hypervisor-vmware.rst#L2
> >>> into the Nova admin config reference
> >>> (https://review.openstack.org/#/c/491853), a couple of interesting
> >>> challenges popped up. These pop up in a couple of other places, but this
> >>> one file nicely contains both of them.
> >>>
> >>> The first is the common autogenerated files (like
> >>> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/tables/nova-vmware.rst#L11).
> >>> To the best of my knowledge we don't have that autogeneration tooling in
> >>> the projects. Should we just be copy/pasting this content in? Is there
> >>> another better strategy there?
> >>
> >> oslo.config does have an extension for generating a table-format
> >> list of all of the configuration options, and the idea is to replace
> >> those included tables with the 'show-options' directive. It uses
> >> the same inputs as the sample file generator. See
> >> https://docs.openstack.org/oslo.config/latest/reference/sphinxext.html for
> >> details
> > 
> > So in this case we could:
> > 
> > .. show-options::
> > 
> >oslo.vmware
> > 
> > 
> > And that would have the same impact?
> 
> I'm attempting to do this, and just getting:
> 
> Warning, treated as error:
> Could not load oslo.vmware
> 
> 
> .tox/docs/bin/pip freeze
> 
> shows that oslo.vmware is installed the tox env. Any ideas what I'm
> doing incorrectly?
> 
> -Sean
> 

The option discovery stuff in oslo.config works using entry point
plugins. oslo.vmware doesn't defined any plugins for the oslo.config.opts
namespace.

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] [docs] importing openstack-manuals questions, looking for strategies

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-08-09 09:24:07 -0400:
> On 08/09/2017 09:19 AM, Doug Hellmann wrote:
> > Excerpts from Sean Dague's message of 2017-08-08 17:01:29 -0400:
> >> When trying to import
> >> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/compute/hypervisor-vmware.rst#L2
> >> into the Nova admin config reference
> >> (https://review.openstack.org/#/c/491853), a couple of interesting
> >> challenges popped up. These pop up in a couple of other places, but this
> >> one file nicely contains both of them.
> >>
> >> The first is the common autogenerated files (like
> >> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/tables/nova-vmware.rst#L11).
> >> To the best of my knowledge we don't have that autogeneration tooling in
> >> the projects. Should we just be copy/pasting this content in? Is there
> >> another better strategy there?
> > 
> > oslo.config does have an extension for generating a table-format
> > list of all of the configuration options, and the idea is to replace
> > those included tables with the 'show-options' directive. It uses
> > the same inputs as the sample file generator. See
> > https://docs.openstack.org/oslo.config/latest/reference/sphinxext.html for
> > details
> 
> So in this case we could:
> 
> .. show-options::
> 
>oslo.vmware
> 
> 
> And that would have the same impact?
> 
> -Sean

The option namespaces are based on plugins, not python packages.
We do often name them the same for easy reference, but some packages
use multiple plugins tied to different list_opts functions. I'm not
sure where those options are defined.

The oslo.vmware library doesn't seem to export any plugins for the
config generator, probably because it doesn't use oslo.config at
all.

I see some configuration options defined in the os-win library, but
I don't know if those match the table you're referring to. That
library does not export an entry point for discovering the options,
so unfortunately it won't work with the config generator or sphinx
extension. If the options you're looking for are in that library, for
Pike you'll need to import the static table.

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][infra]Plan to support Python 3.6 ?

[Doug Hellmann]

Excerpts from ChangBo Guo's message of 2017-08-09 21:25:07 +0800:
> We received Python 3.6 related Bug recently [1][2]. That let me think
> what's the plan to support Python 3.6 for OpenStack in the future.   Python
> 3.6 was released on December 23, 2016, has some different behaviors from
> Python 3.5[3]. talked with cdent in the IRC, would like to discuss this
> through mailing list , and suggest a discussion at the PTG[3]

One of the reasons we were able to move ahead with 3.5 was that it would
be available on the platforms for which we test deployments, as defined
in the CTI [5]. Are Ubuntu LTS and CentOS shipping Python 3.6?

[5] https://governance.openstack.org/tc/reference/project-testing-interface.html

> 
> 1. what's the time to support Python 3.6 ?
> 
> 2. what 's the  plan or process ?
>  Maybe we can do that we support python 3
>  1) setup python 3.6 non-voting CI jobs
>  2) Fix related issues about Python 3.6
>  3) enable pyhton 3.6 jobs voting
> 
> [1] https://bugs.launchpad.net/oslo.rootwrap/+bug/1709505
> [2]https://bugs.launchpad.net/pbr/+bug/1690103
> [3]https://docs.python.org/3/whatsnew/3.6.html
> [4] https://etherpad.openstack.org/p/infra-ptg-queens

__
OpenStack Development Mailing 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] [docs] importing openstack-manuals questions, looking for strategies

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-08-08 17:01:29 -0400:
> When trying to import
> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/compute/hypervisor-vmware.rst#L2
> into the Nova admin config reference
> (https://review.openstack.org/#/c/491853), a couple of interesting
> challenges popped up. These pop up in a couple of other places, but this
> one file nicely contains both of them.
> 
> The first is the common autogenerated files (like
> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/tables/nova-vmware.rst#L11).
> To the best of my knowledge we don't have that autogeneration tooling in
> the projects. Should we just be copy/pasting this content in? Is there
> another better strategy there?

oslo.config does have an extension for generating a table-format
list of all of the configuration options, and the idea is to replace
those included tables with the 'show-options' directive. It uses
the same inputs as the sample file generator. See
https://docs.openstack.org/oslo.config/latest/reference/sphinxext.html for
details

The "filtering" ability is limited right now to namespaces. You may not
be able to reproduce exactly the tables that were used in earlier
releases. We've asked for feedback about other capabilities that teams
want for building tables containing subsets of the input options, and if
we find contributors to build those features we can add them for Queens.

In the mean time, if the output doesn't meet your needs, you can
copy in the tables from the old guide. They aren't up to date, so
you may want to look at the tool for generating the tables in the
openstack-doc-tools repo.

> The second is cross references that don't yet exist. In this case -
> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/compute/hypervisor-vmware.rst#L981.
> Which is :ref:`block_storage_vmdk_driver`, that would be in the cinder
> manual, but does not seem to yet be there. I'm not sure what the best
> strategy is here. Just a TODO to find the right cinder ref once it shows up?

jungleboyj is working on the cinder docs, so he may have some idea of
when those are expected to land. In the mean time, a TODO with a link to
some page in the cinder docs seems like a good temporary measure.

> 
> If anyone has thoughts on the best resolutions here, that would be great.
> 
> -Sean
> 

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

Re: [openstack-dev] [release][ptl] tools for creating new releases

[Doug Hellmann]

Excerpts from Armando M.'s message of 2017-08-08 08:48:34 -0700:
> On 8 August 2017 at 06:30, Doug Hellmann <d...@doughellmann.com> wrote:
> 
> > We realized recently that we haven't publicized some of the tools
> > in the releases repository very well. One tool that will be useful
> > this week as you prepare your release candidates is the 'new-release'
> > command, which edits a deliverable file to add a new release from
> > HEAD of the given branch, automatically computing the next verison
> > number based on the inputs.
> >
> > Use the ``venv`` tox environment to run the tool, like this:
> >
> >$ tox -e venv -- new-release SERIES DELIVERABLE TYPE
> >
> > The SERIES value should be the release series, such as "pike".
> >
> > The DELIVERABLE value should be the deliverable name, such as
> > "oslo.config" or "cinder".
> >
> > The TYPE value should be one of "bugfix", "feature", "major",
> > "milestone", or "rc".
> >
> > If the most recent release of cinder during the pike series is
> > 11.0.0.0b3 then running:
> >
> >$ tox -e venv -- new-release pike cinder rc
> >
> > detects that this is the first release candidate and updates the
> > file deliverables/pike/cinder.yaml with the new release 11.0.0.0rc1
> > and instructions to create a new stable branch at that tag.
> >
> > There are some more details in the README.rst file in the releases
> > repository, and as usual you'll find us in #openstack-release if you
> > have questions.
> >
> 
> I tried it and it works like a charm, though I noticed some harmless side
> effects in that changes [1] in my patch showed up unsolicited.

Changing booleans from true/false to yes/no is a side-effect of
some of the settings in the YAML formatter.

Doug

> 
> Cheers,
> Armando
> 
> [1]
> https://review.openstack.org/#/c/491560/1/deliverables/pike/networking-bgpvpn.yaml@7
> 
> >
> > 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] [api] [tc] Nominatimg Eric Fried for service-types-authority core

[Doug Hellmann]

Excerpts from Chris Dent's message of 2017-08-08 16:35:18 +0100:
> 
> I don't believe we have an established procedure for core
> nominations in the service-types-authority group, so I'll just go
> ahead and take the initiative. I think we should make Eric Fried
> (efried on IRC) a core in that group. He's been doing a great deal
> of work related to service types and service catalog, is around all the
> time, and would be a worthy addition.
> 
> If you don't like this idea but would like to say so privately,
> please contact me. Otherwise I'll give a few days and make it so.

+1 for adding Eric.

> 
> The [tc] tag is on here because the repo is considered "owned by the
> technical committee".
> 
> We may also wish to consider removing Anne Gentle and Brant Knudson
> who are less available these days.
> 

I don't have a problem with removing them, but it would be good to
confirm whether they expect to have more time in queens before we do.

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] [release][ptl] tools for creating new releases

[Doug Hellmann]

We realized recently that we haven't publicized some of the tools
in the releases repository very well. One tool that will be useful
this week as you prepare your release candidates is the 'new-release'
command, which edits a deliverable file to add a new release from
HEAD of the given branch, automatically computing the next verison
number based on the inputs.

Use the ``venv`` tox environment to run the tool, like this:

   $ tox -e venv -- new-release SERIES DELIVERABLE TYPE

The SERIES value should be the release series, such as "pike".

The DELIVERABLE value should be the deliverable name, such as
"oslo.config" or "cinder".

The TYPE value should be one of "bugfix", "feature", "major",
"milestone", or "rc".

If the most recent release of cinder during the pike series is
11.0.0.0b3 then running:

   $ tox -e venv -- new-release pike cinder rc

detects that this is the first release candidate and updates the
file deliverables/pike/cinder.yaml with the new release 11.0.0.0rc1
and instructions to create a new stable branch at that tag.

There are some more details in the README.rst file in the releases
repository, and as usual you'll find us in #openstack-release if you
have questions.

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] [neutron][tap-as-a-service] pike branch/release

[Doug Hellmann]

Excerpts from Takashi Yamamoto's message of 2017-08-08 10:49:09 +0900:
> hi
> 
> i'll create stable/pike (and probably a release) for tap-as-a-service
> in this week.
> 

We have a bunch of tools that expect stable branches to only be created
from releases, so please do tag before branching.

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] [docs] Updating the docs team mission statement

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2017-08-08 12:28:58 +0200:
> Petr Kovar wrote:
> > Hi all,
> > 
> > With the core docs suite moving from openstack-manuals to individual
> > project repos as per
> > http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html,
> > it's also time to update the docs team mission statement from
> > https://governance.openstack.org/tc/reference/projects/documentation.html.
> > 
> > What are everybody's thoughts on what should the new mission statement
> > say now that most OpenStack docs maintenance is in the hands of project
> > teams?
> > 
> > One idea is for the docs team to act as a focused group of editors and
> > maintain a common set of guidelines, recommended practices (style
> > guidelines come to mind, for instance), and requirements (such as a common
> > docs and publishing structure shared across projects).
> 
> I would say something like:
> 
> The docs team provides guidance, assistance, tooling, and style guides
> enabling OpenStack project teams to produce consistent, accurate, and
> high-quality documentation.
> 

Thanks for starting this thread, Petr.

To make it easier to compare, here's the current mission statement:

  Provide documentation for core OpenStack projects to promote
  OpenStack.  Develop and maintain tools and processes to ensure
  quality, accurate documentation. Treat documentation like OpenStack
  code.

Thierry's suggestion highlights some of the changes I see coming
for the docs team. I would like to hear from some of the other team
members about what they think 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] [nova] [docs] Ideal landing page

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-08-07 17:07:37 -0400:
> The integration of all the manual docs, plus all of our native docs
> trying to get restructured a bit, has left us with a first order mess
> when it comes to our front page (and the Table of Contents in the
> sidebar) - https://docs.openstack.org/nova/latest/
> 
> I started trying to pull things out of the sidebar TOC by creating some
> interior landing pages for Contributors and a Deep Dive Technical
> Reference. In staring at what was left on the page for a good hour today
> I came up with the following ideal front page outline.
> 
> https://etherpad.openstack.org/p/ideal-nova-docs-landing-page
> 
> This probably turns into 3 additional patches on topic:bp/doc-migration
> * For Users
> * For Operators
> * Index page smooth over
> 
> The original docs spec didn't really separate out users / operators as
> target audiences. None of this will involve moving subpages around (so

End-user content goes in /user. Operator content goes in /admin.  See
http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html#proposed-change
for details.

> no additional redirects), it will just be a couple of sections and
> landing documents where appropriate.
> 
> Please chime in if you have opinions. Otherwise I'm going to start
> writing the rest of this tomorrow to try to get it all sorted for RC.
> 
> -Sean
> 

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

Re: [openstack-dev] [nova][docs] Concerns with docs migration

[Doug Hellmann]

Excerpts from Clark Boylan's message of 2017-08-07 14:04:33 -0700:
> On Wed, Aug 2, 2017, at 01:44 PM, Clark Boylan wrote:
> > On Wed, Aug 2, 2017, at 11:37 AM, Sean Dague wrote:
> > > On 08/02/2017 12:28 PM, Clark Boylan wrote:
> > > > On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:
> > > >> Now that Stephen Finucane is back from enjoying his youth and 
> > > >> gallivanting all over Europe, and we talked about a few things in IRC 
> > > >> this morning on the docs migration for Nova, I wanted to dump my 
> > > >> concerns here for broader consumption.
> > > >>
> > > >> 1. We know we have to fix a bunch of broken links by adding in 
> > > >> redirects 
> > > >> [1] which sdague started here [2]. However, that apparently didn't 
> > > >> catch 
> > > >> everything, e.g. [3], so I'm concerned we're missing other broken 
> > > >> links. 
> > > >> Is there a way to find out?
> > > > 
> > > > The infra team can generate lists of 404 urls fairly easily on the docs
> > > > server. This won't show you everything but will show you what urls
> > > > people are finding/using that 404.
> > > 
> > > If we could get a weekly report of 404 urls posted somewhere public,
> > > that would be extremely useful, because the easy ones based on git
> > > renames are done, and everything else is going to require human
> > > inspection to figure out what the right landing target is.
> > > 
> > 
> > I've pushed https://review.openstack.org/#/c/490175/ which will generate
> > a report each day for roughly the last day's worth of 404s. You should
> > be able to see them at https://docs.openstack.org/404s once the change
> > merges and the cron job fires.
> > 
> > You can see what that will look like (from my test runs) at
> > http://paste.openstack.org/show/617322/. Note that this isn't a complete
> > file because paste.openstack.org truncated it but you'll get the full
> > data from the wbeserver once this change merges.
> 
> http://files.openstack.org/docs-404s/ is now live (note it moved to
> http://files.openstack.org/docs-404s because that is where we are
> hosting raw bits of utility info for this hosting service). The current
> content there was just generated by running the scripts manually, but it
> should update daily at 0700UTC going forward.
> 
> Hope this helps,
> Clark
> 

Thanks Clark, that's going to be really useful.

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][oslo.config][ansible][tripleo][kolla][ptg] Pluggable drivers and protect plaintext secrets

[Doug Hellmann]

Excerpts from Raildo Mascena de Sousa Filho's message of 2017-08-04 19:34:25 
+:
> Hi all,
> 
> We had a couple of discussions with the Oslo team related to implement
> Pluggable drivers for oslo.config[0] and use those feature to implement
> support to protect plaintext secret on configuration files[1].
> 
> In another hand, due the containerized support on OpenStack services, we
> have a community effort to implement a k8s ConfigMap support[2][3], which
> might make us step back and consider how secret management will work, since
> the config data will need to go into the configmap *before* the container
> is launched.
> 
> So, I would like to see what the community think. Should we continue
> working on that pluggable drivers and protect plain text secrets support
> for oslo.config? Makes sense having a PTG session[4] on Oslo to discuss
> that feature?
> 
> Thanks for the feedback in advance.
> 
> Cheers,
> 
> [0] https://review.openstack.org/#/c/454897/
> [1] https://review.openstack.org/#/c/474304/
> [2]
> https://github.com/flaper87/keystone-k8s-ansible/blob/6524b768d75a28adf44c74aca77ccf13dd66b1a9/provision-keystone-apb/tasks/main.yaml#L71-L108
> [3] https://kubernetes.io/docs/
> 
> tasks/configure-pod-container/configmap/
> 
> [4] https://etherpad.openstack.org/p/oslo-ptg-queens

I've added some of the deployment project tags to the subject line to
expand the audience for this discussion.

We're trying to decide what to do about space at the PTG for this
conversation. My Monday-Wednesday are completely booked, so I was
hoping we could do it Thursday. The Oslo team won't have a room then, so
we need to either find space in another room or reserve one of the extra
rooms mentioned on the schedule [1].

Kendall & Thierry, what do we need to do to reserve that room if we
can't find space in another team room?

Before we meet in Denver, it would be very useful to have some documents
describing the end-to-end processes teams foresee using for managing
secrets.

Doug

[1] 
https://docs.google.com/spreadsheets/u/1/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/pubhtml?gid=397241312=true

__
OpenStack Development Mailing 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][oslo.config] Pluggable drivers and protect plaintext secrets

[Doug Hellmann]

Excerpts from Fox, Kevin M's message of 2017-08-04 21:46:05 +:
> Yeah, but you still run into stuff like db contact and driver information 
> being mixed up with secret used for contacting that service. Those should be 
> separate fields I think so they can be split/merged with that mechanism.

That is also supported, through value interpolation.

https://docs.openstack.org/oslo.config/latest/reference/cfg.html#option-value-interpolation

Doug

> 
> Thanks,
> Kevin
> ____
> From: Doug Hellmann [d...@doughellmann.com]
> Sent: Friday, August 04, 2017 1:49 PM
> To: openstack-dev
> Subject: Re: [openstack-dev] [oslo][oslo.config] Pluggable drivers and  
> protect plaintext secrets
> 
> Excerpts from Fox, Kevin M's message of 2017-08-04 20:21:19 +:
> > I would really like to see secrets separated from config. Always have... 
> > They are two separate things.
> >
> > If nothing else, a separate config file so it can be permissioned 
> > differently.
> >
> > This could be combined with k8s secrets/configmaps better too.
> > Or make it much easier to version config in git and have secrets somewhere 
> > else.
> 
> Sure. It's already possible today to use multiple configuration
> files with oslo.config, using either the --config-dir option or by
> passing multiple --config-file options.
> 
> Doug
> 
> >
> > Thanks,
> > Kevin
> >
> > 
> > From: Raildo Mascena de Sousa Filho [rmasc...@redhat.com]
> > Sent: Friday, August 04, 2017 12:34 PM
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] [oslo][oslo.config] Pluggable drivers and protect 
> > plaintext secrets
> >
> > Hi all,
> >
> > We had a couple of discussions with the Oslo team related to implement 
> > Pluggable drivers for oslo.config[0] and use those feature to implement 
> > support to protect plaintext secret on configuration files[1].
> >
> > In another hand, due the containerized support on OpenStack services, we 
> > have a community effort to implement a k8s ConfigMap support[2][3], which 
> > might make us step back and consider how secret management will work, since 
> > the config data will need to go into the configmap *before* the container 
> > is launched.
> >
> > So, I would like to see what the community think. Should we continue 
> > working on that pluggable drivers and protect plain text secrets support 
> > for oslo.config? Makes sense having a PTG session[4] on Oslo to discuss 
> > that feature?
> >
> > Thanks for the feedback in advance.
> >
> > Cheers,
> >
> > [0] https://review.openstack.org/#/c/454897/
> > [1] https://review.openstack.org/#/c/474304/
> > [2] 
> > https://github.com/flaper87/keystone-k8s-ansible/blob/6524b768d75a28adf44c74aca77ccf13dd66b1a9/provision-keystone-apb/tasks/main.yaml#L71-L108
> > [3] 
> > https://kubernetes.io/docs/<https://kubernetes.io/docs/tasks/configure-pod-container/configmap/>tasks/configure-pod-container/configmap/<https://kubernetes.io/docs/tasks/configure-pod-container/configmap/>
> > [4] https://etherpad.openstack.org/p/oslo-ptg-queens
> 

__
OpenStack Development Mailing 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] [keystone][api] Backwards incompatible changes based on config

[Doug Hellmann]

Excerpts from Morgan Fainberg's message of 2017-08-04 14:52:18 -0700:
> On Fri, Aug 4, 2017 at 2:43 PM, Kevin L. Mitchell  wrote:
> > On Fri, 2017-08-04 at 16:45 -0400, Kristi Nikolla wrote:
> >> Is this the case even if we haven’t made any final release with the change
> >> that introduced this issue? [0]
> >>
> >> It was only included in the Pike milestones and betas so far, and was not
> >> part of the Ocata release.
> >
> > Maybe not, but please do recall that there are many deployers out there
> > that track master, not fixed releases, so we need to take that level of
> > compatibility into account.
> >
> 
> I am going to go out on a limb and say that we should not assume that
> if code merges ever it is a contract because someone might be
> following master. The contract should be for releases. We should do
> everything we can to avoid breaking people, but in the case of an API
> contract (behavior) that was never part of a final release, it should
> be understood this may change if needed until it is released.
> 
> This is just my $0.002 as this leads rapidly to "why bother having
> real releases" if everything is a contract, let someone take a
> snapshot where they're happy with the code to run. You're devaluing
> the actual releases.

I'm out here on this limb with you.

Doug

> 
> >> Therefore the call which now returns a 403 in master, returned a 2xx in
> >> Ocata. So we would be fixing something which is broken on master rather
> >> than changing a ‘contract’.
> >>
> >> 0. 
> >> https://github.com/openstack/keystone/commit/51d5597df729158d15b71e2ba80ab103df5d55f8
> >
> > I would be inclined to accept this specific change as a bug fix not
> > requiring a version bump, because it is a corner case that I believe a
> > deployer would view as a bug, if they encountered it, and because it
> > was introduced prior to a named final release.
> > --
> > Kevin L. Mitchell 
> > __
> > OpenStack Development Mailing 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] [oslo][oslo.config] Pluggable drivers and protect plaintext secrets

[Doug Hellmann]

Excerpts from Fox, Kevin M's message of 2017-08-04 20:21:19 +:
> I would really like to see secrets separated from config. Always have... They 
> are two separate things.
> 
> If nothing else, a separate config file so it can be permissioned differently.
> 
> This could be combined with k8s secrets/configmaps better too.
> Or make it much easier to version config in git and have secrets somewhere 
> else.

Sure. It's already possible today to use multiple configuration
files with oslo.config, using either the --config-dir option or by
passing multiple --config-file options.

Doug

> 
> Thanks,
> Kevin
> 
> 
> From: Raildo Mascena de Sousa Filho [rmasc...@redhat.com]
> Sent: Friday, August 04, 2017 12:34 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [oslo][oslo.config] Pluggable drivers and protect 
> plaintext secrets
> 
> Hi all,
> 
> We had a couple of discussions with the Oslo team related to implement 
> Pluggable drivers for oslo.config[0] and use those feature to implement 
> support to protect plaintext secret on configuration files[1].
> 
> In another hand, due the containerized support on OpenStack services, we have 
> a community effort to implement a k8s ConfigMap support[2][3], which might 
> make us step back and consider how secret management will work, since the 
> config data will need to go into the configmap *before* the container is 
> launched.
> 
> So, I would like to see what the community think. Should we continue working 
> on that pluggable drivers and protect plain text secrets support for 
> oslo.config? Makes sense having a PTG session[4] on Oslo to discuss that 
> feature?
> 
> Thanks for the feedback in advance.
> 
> Cheers,
> 
> [0] https://review.openstack.org/#/c/454897/
> [1] https://review.openstack.org/#/c/474304/
> [2] 
> https://github.com/flaper87/keystone-k8s-ansible/blob/6524b768d75a28adf44c74aca77ccf13dd66b1a9/provision-keystone-apb/tasks/main.yaml#L71-L108
> [3] 
> https://kubernetes.io/docs/tasks/configure-pod-container/configmap/
> [4] https://etherpad.openstack.org/p/oslo-ptg-queens

__
OpenStack Development Mailing 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][oslo.config] Pluggable drivers and protect plaintext secrets

[Doug Hellmann]

Excerpts from Raildo Mascena de Sousa Filho's message of 2017-08-04 19:34:25 
+:
> Hi all,
> 
> We had a couple of discussions with the Oslo team related to implement
> Pluggable drivers for oslo.config[0] and use those feature to implement
> support to protect plaintext secret on configuration files[1].
> 
> In another hand, due the containerized support on OpenStack services, we
> have a community effort to implement a k8s ConfigMap support[2][3], which
> might make us step back and consider how secret management will work, since
> the config data will need to go into the configmap *before* the container
> is launched.
> 
> So, I would like to see what the community think. Should we continue
> working on that pluggable drivers and protect plain text secrets support
> for oslo.config? Makes sense having a PTG session[4] on Oslo to discuss
> that feature?

A PTG session does make sense.

My main concern is that the driver approach described is a fairly
significant change to the library. I was more confident that it made
sense when it was going to be used for multiple purposes. There may be a
less invasive way to handle secret storage. Or, we might be able to
design a system-level approach for handling those that doesn't require
changing the library at all. So let's not frame the discussion as
"should we add plugins to oslo.config" but "how should we handle secret
values in configuration files".

Doug

> 
> Thanks for the feedback in advance.
> 
> Cheers,
> 
> [0] https://review.openstack.org/#/c/454897/
> [1] https://review.openstack.org/#/c/474304/
> [2]
> https://github.com/flaper87/keystone-k8s-ansible/blob/6524b768d75a28adf44c74aca77ccf13dd66b1a9/provision-keystone-apb/tasks/main.yaml#L71-L108
> [3] https://kubernetes.io/docs/
> 
> tasks/configure-pod-container/configmap/
> 
> [4] https://etherpad.openstack.org/p/oslo-ptg-queens

__
OpenStack Development Mailing 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][ptl][stable][release] stable/pike branches created for most libraries

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2017-08-04 08:56:17 +1000:
> On Thu, Aug 03, 2017 at 11:04:52AM -0400, Doug Hellmann wrote:
> > Excerpts from Tony Breeds's message of 2017-08-03 12:43:04 +1000:
> > > On Mon, Jul 31, 2017 at 08:00:22AM -0400, Doug Hellmann wrote:
> > > > Excerpts from Dmitry Tantsur's message of 2017-07-29 20:06:18 +0200:
> > > > > Just to clarify: we cannot land the tox.ini change until the 
> > > > > requirements repo 
> > > > > is actually branched, right?
> > > > 
> > > > Good point. The tests for those patches are passing for some projects in
> > > > CI, but when the patches are landed it will make it a little harder for
> > > > anyone to run the tests for the branch elsewhere because the
> > > > requirements repo has not yet been branched.
> > > > 
> > > > So, yes, hold off on landing the constraint URL changes.
> > > 
> > > I wonder if we should look at publishing the upper-constraints.txt file
> > > somewhere (other than cgit).  If we did something like:
> > > 
> > > tarballs.o.o/constraints/$series.txt
> > > 
> > > We wouldn't have an issue when we EOL a branch and the url's hard-coded
> > > in tox.ini breaking.  queens.txt wouldn't exist until we branch
> > > requirements but we could work around that with a redirect if needed.
> > 
> > I like the idea of publishing to a branch-specific file that always
> > stays on the server. We could make the job on master publish both
> > to a master.txt and a $series.txt file if we need both to exist at the
> > same time.
> > 
> > > Later we could get really crazy and make a version that took a package
> > > name and version perhaps like:
> > > 
> > > tarballs.o.o/constraints/$(python setup.py --name)/$(python setup.py 
> > > --version)
> > > 
> > > Which would redirect to the appropriate series file.  I think we have
> > > enough data in openstack/releases to generate those redirects.  We'd
> > > need to think about projects / repos that don't use the release
> > > infrastructure.
> > 
> > How would that redirect be used?
> 
> So I admit I typed that email and hit send without a huge amount of
> thought and even though I use a web browser a lot I don't really
> understand how http works but I was thinking about something like:
> 
> on $server probably releases.o.o but that's a detail we can sort out
> later.
> 
> /constraints contains a .htaccess file generated from the data in
> openstack relases that says something like:
> 
> redirect /constratints/nova/14.* to /constrataints/newton.txt
> redirect /constratints/nova/15.* to /constrataints/ocata.txt
> 
> Any unknown versions get  /constratints/master.txt (or queens.txt
> depending on what we do)
> 
> It could be a redirect or a rewrite rule whatever works best
> 
> then the nova tox.ini does something like:
> ${ENV:UPPER_CONSTRAINTS_FILE:https://server/constratins/nova/$(python
> setup.py --version)}
> 
> Now it is probably that direct shell output can't be used like that and
> then the whole thing fails but I hope we can do something like that ...
> even if in the short term we need to use a helper script like we do to
> work around other constraints issues.

OK, I see. I was assuming we would just tie it to series name, and
that series name could be taken from the .gitreview file or something.
So the URL calculation would always be done locally, and we wouldn't
need any sort of redirects.

We still need some sort of wrapper for pip, because you're right I
don't think we can use $() syntax to set the variable in tox.ini.
Unless maybe we can do some of this with a tox plugin/extension?
But it seems better to do it by putting a script or something in
the repo, so a user has fewer things to install to run the tests.

> If that doesn't work /constraints could become a script that looks and
> the path_element and does the same logic.
> 
> Now it's herder with libraries but now that much harder.
> 
> The trick would be for repos that don't use releases and perhaps for
> them in the first instance they need to hard code the serries.

Which things do we have that don't use the releases repo but do use
constraints?

Doug

> 
> > 
> > > 
> > > That'd mean we could get way from hard-coding the URLs in tox.ini and
> > > therefore not need to update them at branch time.
> > > 
> > > I've either had too much coffee or not enough.  y'all decide.
> > > 
> > > 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
> 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

Re: [openstack-dev] [ffe][requirements][monasca][heat][watcher][congress] FFE for python-monascaclient minimum version in g-r

[Doug Hellmann]

Excerpts from witold.be...@est.fujitsu.com's message of 2017-08-03 16:07:45 
+:
> > -Original Message-
> > From: Doug Hellmann [mailto:d...@doughellmann.com]
> > Sent: Donnerstag, 3. August 2017 15:45
> > To: openstack-dev <openstack-dev@lists.openstack.org>
> > Subject: Re: [openstack-dev]
> > [ffe][requirements][monasca][heat][watcher][congress] FFE for python-
> > monascaclient minimum version in g-r
> > 
> > Excerpts from witold.be...@est.fujitsu.com's message of 2017-08-03
> > 11:39:47 +:
> > > Hello everyone,
> > >
> > > I would like to ask for the FFE for python-monascaclient version in global
> > requirements.
> > >
> > > The current version in Pike (1.7.0) is not fully backward compatible. The
> > monasca exception classes were replaced with keystoneauth exceptions,
> > which affects heat and watcher projects if they use current upper
> > constraints. The fixes for these projects have been submitted [1, 2].
> > >
> > > Also, monasca projects (monasca-agent, monasca-ui, monasca-api) rely on
> > python-monascaclient 1.7.0 and don't work with older versions.
> > >
> > > The change for bumping the minimum version of python-monascaclient is
> > here:
> > >
> > > https://review.openstack.org/489173
> > >
> > >
> > > Best greetings
> > > Witek Bedyk
> > >
> > >
> > > [1] https://review.openstack.org/490016
> > > [2] https://review.openstack.org/490018
> > >
> > 
> > It is rather late to be raising the minimum allowed version of a library 
> > due to
> > backwards incompatibilities. Can you provide more details about which
> > projects will be impacted (both by updating, and by not updating)?
> 
> 
> Hi Doug,
> 
> I know it's very unfortunate to raise it so late. We haven't paid enough 
> attention when merging the osc-lib integration to monascaclient. I'm sorry 
> for that.
> 
> If we update g-r impacted projects are:
> * Congress
> * Heat
> * Watcher
> For Heat and Watcher we have provided above referenced changes. Congress 
> should work with both, old and new versions, from what we've checked.
> Rally and Freezer-dr do not follow g-r. Fix for Rally has already been merged 
> [1]. Freezer-dr should not be impacted.
> 
> If we don't update g-r the impacted projects are again:
> * Heat
> * Watcher
> The teams don't want to merge compatibility fixes until requirements are 
> raised. Please refer to the reviews from the first message. Without these 
> fixes monascaclient from upper-constraints does not work for them.
> 
> The change in g-r does not alter u-c.
> 
> 
> [1] https://review.openstack.org/486015
> 
> > 
> > How can it be that the Monasca services already rely on the features of this
> > version? Are they not following the constraints process, so they use the
> > same versions of the libraries all of the other projects use?
> > 
> > Doug
> 
> 
> I'm not sure if I know what you mean. We do use upper-constraints for 
> installation and testing. The new version is in u-c.

OK, I think the thing that I misunderstood was that this
backwards-incompatible release is already out. The version number 1.7.0
doesn't follow the SemVer policies if it is incompatible. It should have
been 2.0.0.

> 
> Could you please advise how to proceed?

A good start would be to get all of the PTLs for the projects you listed
to express their opinion here on this thread. Part of the point of
freezing is to force coordination when we do need to make exceptions.

Doug

> 
> 
> Thanks
> Witek
> 

__
OpenStack Development Mailing 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] [docs][release][stable][ptl][infra] Strategic discussion regarding the future of documentation for EOL releases

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2017-08-03 12:20:24 +1000:
> On Thu, Jul 27, 2017 at 07:05:16PM -0400, Doug Hellmann wrote:
>  
> > That content will now live in the project trees. Perhaps part of marking
> > branches in those repos EOL needs to include deleting the install tree
> > from the docs? Now that the docs are in a standard location, that could
> > be part of an EOL script (although it means 2 phases, since we have to
> > land the patch and let the docs rebuild before we remove the branch).
> 
> That can be done.  It's a bit of a pain but for the most part the gate
> is pretty stable at EOL time.  I do worry about what we do if $projects
> gate is broken and can't generate/publish the docs.
>  
> > We could also update the openstack-manuals tree to not publish links
> > to the install guides (either removing the page or replacing it
> > with a placeholder that explains they should be trying to use a
> > newer version).
> 
> That'd work too.  I kinda like that option better.

Yes, that's easy to do with 1 patch to the openstack-manuals repo.

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][ptl][tc] IMPORTANT upcoming change to technical elections

[Doug Hellmann]

> On Aug 2, 2017, at 10:53 PM, Jeremy Stanley  wrote:
> 
> On 2017-07-17 16:17:00 + (+), Jeremy Stanley wrote:
>> If you want to run or vote in upcoming elections for PTL and TC,
>> make sure your Foundation Individual Membership is active and has at
>> least one Email address which matches an Email address in your
>> Gerrit account: log in at https://www.openstack.org/profile/ and
>> check that it says "Current Member Level: Foundation Member" near
>> the top and that at least one of the Primary, Second or Third Email
>> Address fields contains an address which matches at least one of the
>> entries available in the Preferred Email drop-down at
>> https://review.openstack.org/#/settings/contact (case sensitivity
>> doesn't matter but they at least need to be spelled the same).
>> 
>> If you're an "extra-ATC" and don't have a Gerrit account (this is
>> common for translators on the I18n team) then you still need to be a
>> Foundation Member to participate in technical elections and should
>> make sure your member profile includes the Email address listed for
>> you on your team's page at
>> https://governance.openstack.org/tc/reference/projects/ .
> [...]
> 
> For those who haven't double-checked their memberships, I am
> attaching a list of OpenStack Foundation Individual Member IDs and
> names for contributors to official deliverable repositories between
> 2016-09-17 and the present (members.txt.gz, 2315 entries in total,
> these should be eligible to vote in elections for projects to which
> they contributed if a runoff is held). I'm also attaching a list of
> the names of contributors over the same time period who could not be
> automatically matched up to foundation membership profiles
> (nonmembers.txt.gz, 291 entries in total).
> 
> If you want to vote in upcoming elections and your membership isn't
> lining up with your contributor account/addresses (that is to say,
> your name is in the attached nonmembers.txt.gz file) then please
> follow the quoted instructions above from my earlier message as soon
> as possible.
> 
> Should you have any trouble reading the attached compressed lists,
> you can also view them in a browser at the following URLs:
> 
>members.txt - http://paste.openstack.org/raw/617357/
> 
>nonmembers.txt - http://paste.openstack.org/raw/617358/
> 

I had a quick look at that nonmembers.txt list and noticed several 
long-standing members of our community are included. PLEASE EVERYONE go check 
your settings so you are not left out of this election.

Doug

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



signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing 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][ptl][stable][release] stable/pike branches created for most libraries

[Doug Hellmann]

Excerpts from Tony Breeds's message of 2017-08-03 12:43:04 +1000:
> On Mon, Jul 31, 2017 at 08:00:22AM -0400, Doug Hellmann wrote:
> > Excerpts from Dmitry Tantsur's message of 2017-07-29 20:06:18 +0200:
> > > Just to clarify: we cannot land the tox.ini change until the requirements 
> > > repo 
> > > is actually branched, right?
> > 
> > Good point. The tests for those patches are passing for some projects in
> > CI, but when the patches are landed it will make it a little harder for
> > anyone to run the tests for the branch elsewhere because the
> > requirements repo has not yet been branched.
> > 
> > So, yes, hold off on landing the constraint URL changes.
> 
> I wonder if we should look at publishing the upper-constraints.txt file
> somewhere (other than cgit).  If we did something like:
> 
> tarballs.o.o/constraints/$series.txt
> 
> We wouldn't have an issue when we EOL a branch and the url's hard-coded
> in tox.ini breaking.  queens.txt wouldn't exist until we branch
> requirements but we could work around that with a redirect if needed.

I like the idea of publishing to a branch-specific file that always
stays on the server. We could make the job on master publish both
to a master.txt and a $series.txt file if we need both to exist at the
same time.

> Later we could get really crazy and make a version that took a package
> name and version perhaps like:
> 
> tarballs.o.o/constraints/$(python setup.py --name)/$(python setup.py 
> --version)
> 
> Which would redirect to the appropriate series file.  I think we have
> enough data in openstack/releases to generate those redirects.  We'd
> need to think about projects / repos that don't use the release
> infrastructure.

How would that redirect be used?

> 
> That'd mean we could get way from hard-coding the URLs in tox.ini and
> therefore not need to update them at branch time.
> 
> I've either had too much coffee or not enough.  y'all decide.
> 
> 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

Re: [openstack-dev] [tc][packaging][deb] retiring Packaging Deb project

[Doug Hellmann]

Excerpts from Allison Randal's message of 2017-08-03 10:09:59 -0400:
> Hi all,
> 
> The Debian OpenStack packagers are gathered at the annual Debian
> developer event, and discussing the future of OpenStack packaging for
> Debian. There's general agreement that we'd like to go ahead and package
> Pike, but also agreement that we'd like to move back to the Debian
> infrastructure for doing packaging work. There are a variety of reasons,
> including that:
> 
> - Using the familiar Debian workflows and infrastructure is a better way
> to attract experienced Debian developers to the work, and
> 
> - The way we set up the Debian packaging workflow on OpenStack Infra was
> a temporary compromise, and not really a good fit for OpenStack Infra
> (or for Debian).

Moving to more standard Debian workflows and infrastructure make a lot
of sense. If there are tools to be shared, those don't necessarily have
to live on an openstack.org git repo to be useful.

> As a result of the change, we'd like to retire the Packaging Deb
> project in OpenStack, and there will be no candidate running for Queens
> PTL for the project. There will be some cleanup work to do, around
> deb-* repos and other aspects of the Debian packaging workflow we set up
> with OpenStack Infra, following the standard retirement procedures:
> 
> https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
> 
> The OpenStack installation tutorial for Debian will remain in OpenStack,
> and we'll update it for Pike.

To be clear, there is no longer one installation guide. As part of
the doc-migration project, most of the content has moved into project
trees. Some is still being moved, and some shared content related
to tasks such as installing foundation services like rabbit is in
the openstack-manuals repository.

https://docs.openstack.org/pike/install/ links to all the published
installation guides. We do not currently have separate pages that link
to the relevant sections for a given OS.

Doug

> If you have any concerns about the retirement, please let us know
> (especially other distros that use .deb format packages), we'll wait a
> bit for feedback before moving ahead with the cleanup.
> 
> Thanks,
> Allison
> 

__
OpenStack Development Mailing 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] Release countdown for week R-3, Aug 4 - Aug 11

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2017-08-03 16:16:12 +0200:
> Hi!
> 
> On 08/03/2017 03:03 PM, Thierry Carrez wrote:
> > Welcome to our regular release countdown email!
> > 
> 
> > 
> > 
> > Actions
> > ---
> > 
> > Deliverables following the cycle-with-milestones model should post a RC1
> > openstack/releases request during the week (X.0.0.0rc1), together with a
> > stable/pike branch request. It should include something like this:
> > 
> > ...
> >- projects:
> >- hash: YOURHASH
> >  repo: openstack/YOURPROJECT
> >  version: YOURVERSION.0.0.0rc1
> > branches:
> >- location: YOURVERSION.0.0.0rc1
> >  name: stable/pike
> > 
> > Deliverables following the cycle-with-intermediary model should also
> > create their Pike release branch next week. That means potentially
> > making a last Pike release, and in all cases posting the stable/pike
> > branch creation request:
> > 
> > ...
> > branches:
> >- location: YOUR.PIKE.VERSION
> >  name: stable/pike
> 
> https://releases.openstack.org/pike/schedule.html mentions the week after 
> next 
> (starting Aug 21) to be the last week for cycle-with-intermediary releases. 
> Are 
> we expected to branch before that? Could you please clarify the hard deadline?

Stable branches are always created from tagged releases. So, you
need to prepare a release to serve as the base of the branch.

Milestone-based projects use an 0rc1 tag for that release, indicating
that it is a release candidate. Those are scheduled for 10 Aug this
cycle.

cycle-with-intermediary projects like Monasca should use a full
regular release as the base of the branch. Those should be created
some time between the RC1 week and that final deadline on 24 Aug.
By selecting the cycle-with-intermediary model, you've indicated
that you want more control over the release process and understand
the risks, so you'll have to decide how to balance the timing of
the branch on your own. Branching too early means you may have to
backport more fixes and may have to make more patch releases.
Branching later means your users have less time to test the released
version that will ship as part of Pike.

After 24 Aug, we freeze the release repo for a week to give folks
time to test the last release candidates for milestone-based projects.
Only really critical fixes (installation deletes the entire database,
or infects servers, or whatever) for any project will be released
between 24 Aug and 30 Aug. Normal patch releasing usually resumes the
following week, after we open the requirements repository again.

Releases from master after 24 Aug will be considered part of Queens, not
Pike.

Does that help?

Doug

> 
> > 
> > 
> > Upcoming Deadlines & Dates
> > --
> > 
> > RC1 target deadline (and HardStringFreeze): August 10
> > Final Pike release: August 30
> > Queens PTG in Denver: Sept 11-15
> > 
> > As usual come find us on #openstack-release IRC channel if you have any
> > questions or concerns.
> > 
> 

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

Re: [openstack-dev] [monasca] Stable branch for Pike

[Doug Hellmann]

Excerpts from witold.be...@est.fujitsu.com's message of 2017-08-03 13:27:14 
+:
> Hello Monasca team,
> 
> Following the Pike release schedule I would like to cut the stable branch for 
> Pike release early next week. We will use it to create the final release at 
> the end of August.
> 
> Please let me know of release-critical bugs which should be merged before.
> 
> 
> Cheers
> Witek
> 

Please coordinate with the release team to create the stable branches
based on your release candidates.

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] [ffe][requirements][monasca][heat][watcher][congress] FFE for python-monascaclient minimum version in g-r

[Doug Hellmann]

Excerpts from witold.be...@est.fujitsu.com's message of 2017-08-03 11:39:47 
+:
> Hello everyone,
> 
> I would like to ask for the FFE for python-monascaclient version in global 
> requirements.
> 
> The current version in Pike (1.7.0) is not fully backward compatible. The 
> monasca exception classes were replaced with keystoneauth exceptions, which 
> affects heat and watcher projects if they use current upper constraints. The 
> fixes for these projects have been submitted [1, 2].
> 
> Also, monasca projects (monasca-agent, monasca-ui, monasca-api) rely on 
> python-monascaclient 1.7.0 and don't work with older versions.
> 
> The change for bumping the minimum version of python-monascaclient is here:
> 
> https://review.openstack.org/489173
> 
> 
> Best greetings
> Witek Bedyk
> 
> 
> [1] https://review.openstack.org/490016
> [2] https://review.openstack.org/490018
> 

It is rather late to be raising the minimum allowed version of a
library due to backwards incompatibilities. Can you provide more
details about which projects will be impacted (both by updating,
and by not updating)?

How can it be that the Monasca services already rely on the features
of this version? Are they not following the constraints process,
so they use the same versions of the libraries all of the other
projects use?

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] Release countdown for week R-3, Aug 4 - Aug 11

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2017-08-03 15:03:59 +0200:

> Actions
> ---
> 
> Deliverables following the cycle-with-milestones model should post a RC1
> openstack/releases request during the week (X.0.0.0rc1), together with a
> stable/pike branch request. It should include something like this:
> 
> ...
>   - projects:
>   - hash: YOURHASH
> repo: openstack/YOURPROJECT
> version: YOURVERSION.0.0.0rc1
> branches:
>   - location: YOURVERSION.0.0.0rc1
> name: stable/pike
> 
> Deliverables following the cycle-with-intermediary model should also
> create their Pike release branch next week. That means potentially
> making a last Pike release, and in all cases posting the stable/pike
> branch creation request:
> 
> ...
> branches:
>   - location: YOUR.PIKE.VERSION
> name: stable/pike

It would be really REALLY good for project teams to finish landing the
doc-migration patches before branching. Otherwise, you will have to
backport all of the doc changes to the stable branch in order for them
to show up in the Pike documentation.

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][docs] Concerns with docs migration

[Doug Hellmann]

Excerpts from Clark Boylan's message of 2017-08-02 13:44:26 -0700:
> On Wed, Aug 2, 2017, at 11:37 AM, Sean Dague wrote:
> > On 08/02/2017 12:28 PM, Clark Boylan wrote:
> > > On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:
> > >> Now that Stephen Finucane is back from enjoying his youth and 
> > >> gallivanting all over Europe, and we talked about a few things in IRC 
> > >> this morning on the docs migration for Nova, I wanted to dump my 
> > >> concerns here for broader consumption.
> > >>
> > >> 1. We know we have to fix a bunch of broken links by adding in redirects 
> > >> [1] which sdague started here [2]. However, that apparently didn't catch 
> > >> everything, e.g. [3], so I'm concerned we're missing other broken links. 
> > >> Is there a way to find out?
> > > 
> > > The infra team can generate lists of 404 urls fairly easily on the docs
> > > server. This won't show you everything but will show you what urls
> > > people are finding/using that 404.
> > 
> > If we could get a weekly report of 404 urls posted somewhere public,
> > that would be extremely useful, because the easy ones based on git
> > renames are done, and everything else is going to require human
> > inspection to figure out what the right landing target is.
> > 
> 
> I've pushed https://review.openstack.org/#/c/490175/ which will generate
> a report each day for roughly the last day's worth of 404s. You should
> be able to see them at https://docs.openstack.org/404s once the change
> merges and the cron job fires.
> 
> You can see what that will look like (from my test runs) at
> http://paste.openstack.org/show/617322/. Note that this isn't a complete
> file because paste.openstack.org truncated it but you'll get the full
> data from the wbeserver once this change merges.
> 
> Clark
> 

Wonderful, thank you, Clark!

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][docs] Concerns with docs migration

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-08-02 14:34:40 -0400:
> On 08/02/2017 12:20 PM, Doug Hellmann wrote:
> > Excerpts from Akihiro Motoki's message of 2017-08-03 01:02:59 +0900:
> >> 2017-08-03 0:52 GMT+09:00 Doug Hellmann <d...@doughellmann.com>:
> >>> Excerpts from Stephen Finucane's message of 2017-08-02 16:35:23 +0100:
> >>>> On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:
> >>>>> On 08/02/2017 09:22 AM, Stephen Finucane wrote:
> >>>>>> On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:
> >>>>>>> 3. The patch for the import of the admin guide [8] is missing some CLI
> >>>>>>> specific pages which are pretty useful given they aren't documented
> >>>>>>> anywhere else, like the forced_host part of the compute API [9].
> >>>>>>> Basically anything that's cli-nova-* in the admin guide should be in 
> >>>>>>> the
> >>>>>>> Nova docs. It's also missing the compute-flavors page [10] which is
> >>>>>>> pretty important for using OpenStack at all.
> >>>>>>
> >>>>>> This is a tricky one. Based on previous discussions with dhellmann, the
> >>>>>> plan
> >>>>>> seems to be to replace any references to 'nova xxx' or 'openstack xxx'
> >>>>>> commands
> >>>>>> (i.e. commands using python-novaclient or python-openstackclient) in 
> >>>>>> favour
> >>>>>> of
> >>>>>> 'curl'-based requests. The idea here is that the Python clients are 
> >>>>>> not the
> >>>>>> only clients available, and we shouldn't be "mandating" their use by
> >>>>>> referencing them in the docs. I get this, though I don't fully agree 
> >>>>>> with
> >>>>>> it
> >>>>>> (who really uses curl?)
> >>>>>
> >>>>> Are we going to document the python clients elsewhere then?
> >>>>
> >>>> I think the docs would go into the respective python clients docs?
> >>>
> >>> Right. I don't remember the details of the curl discussion, but I
> >>> think what I was trying to say there was that the "nova" command
> >>> line tool installed via python-novaclient should be documented as
> >>> part of the openstack/python-novaclient repo rather than openstack/nova.
> >>> A CLI reference for nova-manage, which I think is in openstack/nova,
> >>> could be documented in openstack/nova.
> >>>
> >>> Basically, put the docs with the code, which is the whole point of this
> >>> migration.
> >>
> >> It is true for CLI reference.
> >> The gray zone is CLI stuffs in the admin guide and/or end-user guide.
> >> I think this is the point Matt raised.
> >> cli-nova-* stuffs in the admin guide was per topic like launching instance,
> >> migrating instances and so on. It is actually beyond the CLI reference to 
> >> me.
> >> It is about how to use specific features of nova.
> >> IMHO this kind of stuffs can be covered by the admin guide or user guide,
> >> so it fits into openstack/nova (or other server projects).
> > 
> > Yeah, I don't know.
> > 
> > My gut response is to say that if the example uses nova-manage or
> > one of the nova service executables, then that makes sense to leave
> > in the nova tree, but otherwise it should go into either the
> > python-novaclient or python-openstackclient repositories (depending
> > on which command line tool is used in the example).
> > 
> > On the other hand, I can see that being somewhat confusing for
> > someone who lands at the nova docs and can't find instructions for
> > how to use it. Maybe less confusing, though, than if I am not
> > *running* nova but am trying to use a nova deployed by someone else
> > and I start from the python-novaclient or python-openstackclient
> > docs because I installed one of those in order to talk to nova.
> > 
> > I thought "put the docs with the code" would be a simple enough
> > rule that we wouldn't have to think too hard about where to put
> > individual example files, which would speed up the migration.
> 
> It's not so simple because years ago we decided nova-manage was mostly a
> bad thing (as you needed to run it on the API node and be able to read
> db creds with it), and exposed as much 

Re: [openstack-dev] [nova][docs] Concerns with docs migration

[Doug Hellmann]

Excerpts from Akihiro Motoki's message of 2017-08-03 01:02:59 +0900:
> 2017-08-03 0:52 GMT+09:00 Doug Hellmann <d...@doughellmann.com>:
> > Excerpts from Stephen Finucane's message of 2017-08-02 16:35:23 +0100:
> >> On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:
> >> > On 08/02/2017 09:22 AM, Stephen Finucane wrote:
> >> > > On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:
> >> > > > 3. The patch for the import of the admin guide [8] is missing some 
> >> > > > CLI
> >> > > > specific pages which are pretty useful given they aren't documented
> >> > > > anywhere else, like the forced_host part of the compute API [9].
> >> > > > Basically anything that's cli-nova-* in the admin guide should be in 
> >> > > > the
> >> > > > Nova docs. It's also missing the compute-flavors page [10] which is
> >> > > > pretty important for using OpenStack at all.
> >> > >
> >> > > This is a tricky one. Based on previous discussions with dhellmann, the
> >> > > plan
> >> > > seems to be to replace any references to 'nova xxx' or 'openstack xxx'
> >> > > commands
> >> > > (i.e. commands using python-novaclient or python-openstackclient) in 
> >> > > favour
> >> > > of
> >> > > 'curl'-based requests. The idea here is that the Python clients are 
> >> > > not the
> >> > > only clients available, and we shouldn't be "mandating" their use by
> >> > > referencing them in the docs. I get this, though I don't fully agree 
> >> > > with
> >> > > it
> >> > > (who really uses curl?)
> >> >
> >> > Are we going to document the python clients elsewhere then?
> >>
> >> I think the docs would go into the respective python clients docs?
> >
> > Right. I don't remember the details of the curl discussion, but I
> > think what I was trying to say there was that the "nova" command
> > line tool installed via python-novaclient should be documented as
> > part of the openstack/python-novaclient repo rather than openstack/nova.
> > A CLI reference for nova-manage, which I think is in openstack/nova,
> > could be documented in openstack/nova.
> >
> > Basically, put the docs with the code, which is the whole point of this
> > migration.
> 
> It is true for CLI reference.
> The gray zone is CLI stuffs in the admin guide and/or end-user guide.
> I think this is the point Matt raised.
> cli-nova-* stuffs in the admin guide was per topic like launching instance,
> migrating instances and so on. It is actually beyond the CLI reference to me.
> It is about how to use specific features of nova.
> IMHO this kind of stuffs can be covered by the admin guide or user guide,
> so it fits into openstack/nova (or other server projects).

Yeah, I don't know.

My gut response is to say that if the example uses nova-manage or
one of the nova service executables, then that makes sense to leave
in the nova tree, but otherwise it should go into either the
python-novaclient or python-openstackclient repositories (depending
on which command line tool is used in the example).

On the other hand, I can see that being somewhat confusing for
someone who lands at the nova docs and can't find instructions for
how to use it. Maybe less confusing, though, than if I am not
*running* nova but am trying to use a nova deployed by someone else
and I start from the python-novaclient or python-openstackclient
docs because I installed one of those in order to talk to nova.

I thought "put the docs with the code" would be a simple enough
rule that we wouldn't have to think too hard about where to put
individual example files, which would speed up the migration.

Doug

> 
> Akihiro
> 
> >
> > 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] [nova][docs] Concerns with docs migration

[Doug Hellmann]

Excerpts from Stephen Finucane's message of 2017-08-02 16:35:23 +0100:
> On Wed, 2017-08-02 at 09:28 -0600, Chris Friesen wrote:
> > On 08/02/2017 09:22 AM, Stephen Finucane wrote:
> > > On Wed, 2017-08-02 at 09:55 -0500, Matt Riedemann wrote:
> > > > 3. The patch for the import of the admin guide [8] is missing some CLI
> > > > specific pages which are pretty useful given they aren't documented
> > > > anywhere else, like the forced_host part of the compute API [9].
> > > > Basically anything that's cli-nova-* in the admin guide should be in the
> > > > Nova docs. It's also missing the compute-flavors page [10] which is
> > > > pretty important for using OpenStack at all.
> > > 
> > > This is a tricky one. Based on previous discussions with dhellmann, the
> > > plan
> > > seems to be to replace any references to 'nova xxx' or 'openstack xxx'
> > > commands
> > > (i.e. commands using python-novaclient or python-openstackclient) in 
> > > favour
> > > of
> > > 'curl'-based requests. The idea here is that the Python clients are not 
> > > the
> > > only clients available, and we shouldn't be "mandating" their use by
> > > referencing them in the docs. I get this, though I don't fully agree with
> > > it
> > > (who really uses curl?)
> >
> > Are we going to document the python clients elsewhere then?
> 
> I think the docs would go into the respective python clients docs?

Right. I don't remember the details of the curl discussion, but I
think what I was trying to say there was that the "nova" command
line tool installed via python-novaclient should be documented as
part of the openstack/python-novaclient repo rather than openstack/nova.
A CLI reference for nova-manage, which I think is in openstack/nova,
could be documented in openstack/nova.

Basically, put the docs with the code, which is the whole point of this
migration.

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] [release][requirements] FFE release for reno 2.5.0

[Doug Hellmann]

We have a few projects that have modified stable branch release
notes by editing the files on master, which makes those notes appear
as part of the current release. Reno has a new option to address
that problem by ignoring some note files, and I would like to release
that version to allow project teams to fix up their release notes
for pike. I really thought I had already released that update, so
I'm sorry for the late request.

Reno is only used during release notes builds, but it does appear
in the global requirements list and constraints list. I think the
risk is minimal.

https://review.openstack.org/489998

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][docs] recruiting for help with documentation tools

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-08-01 15:35:35 -0400:
> With the changes we've made to docs processes upstream, every team
> is going to need to build up their knowledge of how the new
> documentation tools and jobs work. The docs team will still help,
> but things will obviously go more smoothly if folks know how the
> tools work, now that the bulk of the content is in-tree with the
> code.
> 
> At the same time, the docs team could use help with developing and
> maintaining those tools. We have a couple people working on them
> now (me, Andreas, and Anne), but none of us is doing it full time.
> I need to transition off of this work, so over the course of Queens
> I will be trying to build up the skills of the existing team so
> they do not need to rely on me so much. Also, Andreas and Anne have
> said that they cannot commit to driving any work.
> 
> Although the documentation team has some skills in this area, they
> could use help, so I would like to find a few people to join the
> team specifically to work on the tooling (although if you wanted
> to write documentation, too, no one will object).
> 
> Some of you have been helping informally (thank you!), but the
> community shift is big enough that we need to account for the new
> need a bit more formally. I think if we could find several people
> who could give a small percentage of their time (10%?), we would
> be well covered. There will not be work every week, but when there
> is something to do it's likely to take a small extended period (1-2
> days) to add a feature or resolve an issue. If we found 4-6 people,
> I think we would be covered and have a sustainable group.
> 
> The areas we need help are maintaining the doc build jobs, the
> sphinx extensions in oslo.config and oslo.policy, the Sphinx theme,
> and the template build tool in the openstack-manuals git repo. These
> are all minimally complete, but there is definitely feature work
> and bug fixing to do. I can guarantee that, if you sign up to help,
> you will have a chance to land changes that will be visible for all
> OpenStack users. At the start of Queens, I will be doing some
> one-on-one training with volunteers to ensure they understand the
> system we have in place now and help them start on some of the
> remaining feature work.
> 
> If you are interested in helping, please let me know by following
> up to this thread, and then join #openstack-docs on IRC.
> 
> Doug
> 

If you want an idea of the sorts of work ahead, check out the tracking
pad: https://etherpad.openstack.org/p/doc-future-problems

Not everything on that list is related to the tools, but quite a lot is.

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][docs] recruiting for help with documentation tools

[Doug Hellmann]

Excerpts from Swapnil Kulkarni's message of 2017-08-02 14:35:49 +0530:
> On Wed, Aug 2, 2017 at 2:25 PM, Bogdan Dobrelya <bdobr...@redhat.com> wrote:
> > On 01.08.2017 21:35, Doug Hellmann wrote:
> >> With the changes we've made to docs processes upstream, every team
> >> is going to need to build up their knowledge of how the new
> >> documentation tools and jobs work. The docs team will still help,
> >> but things will obviously go more smoothly if folks know how the
> >> tools work, now that the bulk of the content is in-tree with the
> >> code.
> >>
> >> At the same time, the docs team could use help with developing and
> >> maintaining those tools. We have a couple people working on them
> >> now (me, Andreas, and Anne), but none of us is doing it full time.
> >> I need to transition off of this work, so over the course of Queens
> >> I will be trying to build up the skills of the existing team so
> >> they do not need to rely on me so much. Also, Andreas and Anne have
> >> said that they cannot commit to driving any work.
> >>
> >> Although the documentation team has some skills in this area, they
> >> could use help, so I would like to find a few people to join the
> >> team specifically to work on the tooling (although if you wanted
> >> to write documentation, too, no one will object).
> >>
> >> Some of you have been helping informally (thank you!), but the
> >> community shift is big enough that we need to account for the new
> >> need a bit more formally. I think if we could find several people
> >> who could give a small percentage of their time (10%?), we would
> >> be well covered. There will not be work every week, but when there
> >> is something to do it's likely to take a small extended period (1-2
> >> days) to add a feature or resolve an issue. If we found 4-6 people,
> >> I think we would be covered and have a sustainable group.
> >>
> >> The areas we need help are maintaining the doc build jobs, the
> >> sphinx extensions in oslo.config and oslo.policy, the Sphinx theme,
> >> and the template build tool in the openstack-manuals git repo. These
> >> are all minimally complete, but there is definitely feature work
> >> and bug fixing to do. I can guarantee that, if you sign up to help,
> >> you will have a chance to land changes that will be visible for all
> >> OpenStack users. At the start of Queens, I will be doing some
> >> one-on-one training with volunteers to ensure they understand the
> >> system we have in place now and help them start on some of the
> >> remaining feature work.
> >>
> >> If you are interested in helping, please let me know by following
> >> up to this thread, and then join #openstack-docs on IRC.
> >
> > +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
> >>
> >
> >
> > --
> > Best regards,
> > Bogdan Dobrelya,
> > Irc #bogdando
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> +1
> 

Thanks, Bogdan and Swapnil, I'm happy to have you on board!

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] [SPAM] [all][docs] recruiting for help with documentation tools

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2017-08-02 14:01:47 +0200:
> Doug Hellmann wrote:
> > [...]
> > The areas we need help are maintaining the doc build jobs, the
> > sphinx extensions in oslo.config and oslo.policy, the Sphinx theme,
> > and the template build tool in the openstack-manuals git repo. These
> > are all minimally complete, but there is definitely feature work
> > and bug fixing to do. I can guarantee that, if you sign up to help,
> > you will have a chance to land changes that will be visible for all
> > OpenStack users. At the start of Queens, I will be doing some
> > one-on-one training with volunteers to ensure they understand the
> > system we have in place now and help them start on some of the
> > remaining feature work.
> > [...]
> Feels like the doc owners/liaisons that we are looking for in the Top 5
> help wanted list[1] would be in a good position to help with that.
> Should we extend the description of the need so that it's clearer that
> help with maintaining the doc toolchain is also a top wanted thing ?
> 
> [1]
> https://governance.openstack.org/tc/reference/top-5-help-wanted.html#documentation-owners
> 

I'm torn on that. On the one hand, I would like to recruit. On the
other, we do need far more content contributors than tool maintainers.
Let's wait and see. There were 2 responses to this thread already, so
maybe we won't need to go that far.

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][ptl] new "linter" rules for openstack/releases repository

[Doug Hellmann]

Excerpts from Alex Schultz's message of 2017-08-01 13:56:53 -0600:
> On Tue, Aug 1, 2017 at 1:45 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> > Excerpts from Alex Schultz's message of 2017-08-01 12:55:15 -0600:
> >> On Tue, Aug 1, 2017 at 12:07 PM, Doug Hellmann <d...@doughellmann.com> 
> >> wrote:
> >> > The release team is working on a series of patches to improve the
> >> > data validation within openstack/releases. Part of that work is to
> >> > apply consistent formatting rules for all of the YAML files, so it
> >> > is easier to build tools that automatically update those files. To
> >> > enable those consistent rules, we have had to "normalize" the use
> >> > of whitespace in a bunch of the existing files.
> >> >
> >> > These changes mean that if you have built your own automation for
> >> > adding new releases, you might have to make adjustments. If you do,
> >> > please take the time to look at the tools within the repo (in
> >> > particular the new-release, interactive-release, and edit-deliverable
> >> > commands) to see if they meet your needs, or can be extended to do
> >> > so. There's not much point in all of us building our own tools. :-)
> >> >
> >> > If you're curious about the actual changes, you can have a look at the
> >> > patch series for "queens-indentation" at
> >> > https://review.openstack.org/#/q/project:openstack/releases+topic:queens-indentation
> >> >
> >>
> >> Was the linting rules applied via templates or is this something that
> >> can be done programatically via pyyaml/ruamel.yaml or some other
> >> library?  I know for the puppet release files I was using ruamel.yaml
> >
> > We're using yamllint and jsonschema. The whitepsace rules are enforced
> > by yamllint, and now also by the yamlutils module in the releases repo
> > which configures PyYAML to emit YAML that matches the linter rules.
> >
> 
> Ok I'll take a look. The issues I ran into with PyYAML was the
> ordering would end up differently than what was previously being
> generated.  I'm really not too keen on these types of changes as they
> seem to be making things harder than they need to be.  In the future
> can we ask for commentary on this prior to making these changes or
> only doing it at the beginning of the cycle? Now that we're working
> towards the RCs, the last thing I want to be doing right now is
> messing with yaml formatting while trying to get the final release
> stuff together.

The yamlutils module in the repo ties in an ordereddict thing so
the output is deterministic. We also have a format-yaml command
that reads the input and writes it back out using the new rules,
which makes it easy to normalize the file in one patch and then add
info in a follow-up.

All of this was intended to make it easier to have scripts that
apply bulk updates, which the release team uses at a few points
throughout the cycle.  I would be happy to work with you to bring
whatever tools you're building into the releases repo to generalize
them.

Doug

> 
> Thanks,
> -Alex
> 
> > Doug
> >
> >> to match up with what was being generated but this new formatting
> >> seems to diverge from what it generates.   The last time I went
> >> looking the tooling provided seemed to be using templates which didn't
> >> match anything if you were trying to manage the files via normal yaml
> >> objects which was kinda the problem.
> >>
> >> Thanks,
> >> -Alex
> >>
> >> > 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
> 

__
OpenStack Development Mailing 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][oslo] FFE for oslo.policy

[Doug Hellmann]

Excerpts from Davanum Srinivas (dims)'s message of 2017-08-01 16:38:13 -0400:
> +1, i'd support this as the 2 commits in there are not in the
> normal/runtime flow for oslo.policy and just touch the doc bits.

+1 as well

> 
> Thanks,
> Dims
> 
> On Tue, Aug 1, 2017 at 4:36 PM, Lance Bragstad  wrote:
> > I was cleaning up a few documentation things for keystone and noticed an
> > issue with how the configuration reference was rendering. It turns out
> > the oslo.policy library needed a few tweaks to the show-policy directive
> > along with some changes to keystone that allowed us to properly render
> > all default policies. I documented these in a bug report tagging both
> > projects [0].
> >
> > Two fixes were made to the oslo.policy library (thanks, Doug!) that will
> > allow projects to render their entire policy document using the
> > show-policy directive. Both fixes have merged in oslo.policy master and
> > have been backported to stable/pike. I also have a release proposed to
> > cut a new version of oslo.policy for us to use for pike [1].
> >
> > Opening this up for discussion to see if we can grant an FFE so that we
> > can use the proper version of oslo.policy. More context in IRC as well [2].
> >
> > Let me know if you have any questions. Thanks!
> >
> > Lance
> >
> > [0] https://bugs.launchpad.net/keystone/+bug/1707246
> > [1] https://review.openstack.org/#/c/489599/
> > [2]
> > http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-08-01.log.html#t2017-08-01T18:14:57
> >
> >
> >
> > __
> > OpenStack Development Mailing 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] [release][requirements][barbican][octavia][LBaaS][heat] FFE Request for python-barbicanclient library

[Doug Hellmann]

Excerpts from Dave McCowan (dmccowan)'s message of 2017-08-01 20:48:12 +:
> This note is to request a Feature Freeze Exemption (FFE) for the 
> python-barbicanclient library in Pike.
> 
> Python-barbicanclient 4.5.0 was intended to be the Pike release.  However, 
> after it was released, testing with the Heat and Octavia projects found that 
> it contained an incompatible change resulting in Tracebacks for those 
> projects.
> 
> The issue was reported in this bug.
> https://bugs.launchpad.net/python-barbicanclient/+bug/1706841
> 
> A first, and partial, attempt to fix this was merged in this patch.
> https://review.openstack.org/487721
> This patch is included in release 4.5.1.
> 
> A second, and successful, fix was merged in this patch.
> https://review.openstack.org/489518
> This patch is included in release 4.5.2.
> 
> The Barbican team requests a feature freeze exemption for 
> python-barbicanclient release 4.5.2 to be the release for Pike.  Releases 
> 4.5.0 and 4.5.1 should be blocked in global requirements.
> 
> Thanks,
> Dave
> IRC:dave-mccowan

This sounds reasonable. It's a critical problem but only affects a small
number of projects, so the risk is fairly small.

I assume you've done enough testing to feel comfortable that 4.5.2 will
work better than 4.5.0 and 4.5.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] [release][ptl] new "linter" rules for openstack/releases repository

[Doug Hellmann]

Excerpts from Alex Schultz's message of 2017-08-01 12:55:15 -0600:
> On Tue, Aug 1, 2017 at 12:07 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> > The release team is working on a series of patches to improve the
> > data validation within openstack/releases. Part of that work is to
> > apply consistent formatting rules for all of the YAML files, so it
> > is easier to build tools that automatically update those files. To
> > enable those consistent rules, we have had to "normalize" the use
> > of whitespace in a bunch of the existing files.
> >
> > These changes mean that if you have built your own automation for
> > adding new releases, you might have to make adjustments. If you do,
> > please take the time to look at the tools within the repo (in
> > particular the new-release, interactive-release, and edit-deliverable
> > commands) to see if they meet your needs, or can be extended to do
> > so. There's not much point in all of us building our own tools. :-)
> >
> > If you're curious about the actual changes, you can have a look at the
> > patch series for "queens-indentation" at
> > https://review.openstack.org/#/q/project:openstack/releases+topic:queens-indentation
> >
> 
> Was the linting rules applied via templates or is this something that
> can be done programatically via pyyaml/ruamel.yaml or some other
> library?  I know for the puppet release files I was using ruamel.yaml

We're using yamllint and jsonschema. The whitepsace rules are enforced
by yamllint, and now also by the yamlutils module in the releases repo
which configures PyYAML to emit YAML that matches the linter rules.

Doug

> to match up with what was being generated but this new formatting
> seems to diverge from what it generates.   The last time I went
> looking the tooling provided seemed to be using templates which didn't
> match anything if you were trying to manage the files via normal yaml
> objects which was kinda the problem.
> 
> Thanks,
> -Alex
> 
> > 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

[openstack-dev] [all][docs] recruiting for help with documentation tools

[Doug Hellmann]

With the changes we've made to docs processes upstream, every team
is going to need to build up their knowledge of how the new
documentation tools and jobs work. The docs team will still help,
but things will obviously go more smoothly if folks know how the
tools work, now that the bulk of the content is in-tree with the
code.

At the same time, the docs team could use help with developing and
maintaining those tools. We have a couple people working on them
now (me, Andreas, and Anne), but none of us is doing it full time.
I need to transition off of this work, so over the course of Queens
I will be trying to build up the skills of the existing team so
they do not need to rely on me so much. Also, Andreas and Anne have
said that they cannot commit to driving any work.

Although the documentation team has some skills in this area, they
could use help, so I would like to find a few people to join the
team specifically to work on the tooling (although if you wanted
to write documentation, too, no one will object).

Some of you have been helping informally (thank you!), but the
community shift is big enough that we need to account for the new
need a bit more formally. I think if we could find several people
who could give a small percentage of their time (10%?), we would
be well covered. There will not be work every week, but when there
is something to do it's likely to take a small extended period (1-2
days) to add a feature or resolve an issue. If we found 4-6 people,
I think we would be covered and have a sustainable group.

The areas we need help are maintaining the doc build jobs, the
sphinx extensions in oslo.config and oslo.policy, the Sphinx theme,
and the template build tool in the openstack-manuals git repo. These
are all minimally complete, but there is definitely feature work
and bug fixing to do. I can guarantee that, if you sign up to help,
you will have a chance to land changes that will be visible for all
OpenStack users. At the start of Queens, I will be doing some
one-on-one training with volunteers to ensure they understand the
system we have in place now and help them start on some of the
remaining feature work.

If you are interested in helping, please let me know by following
up to this thread, and then join #openstack-docs on IRC.

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