[openstack-dev] IMPORTANT: This list is retired
This mailing list was replaced by a new openstack-disc...@lists.openstack.org mailing list[0] as of Monday November 19, 2018 and starting now will no longer receive any new messages. The archive of prior messages will remain published in the expected location indefinitely for future reference. For convenience posts to the old list address will be rerouted to the new list for an indeterminate period of time, but please correct it in your replies if you notice this. See my original notice[1] (and the many reminders sent in months since) for an explanation of this change. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] IMPORTANT: We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] IMPORTANT: We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list[0] is open for posts from subscribers starting now, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 280 subscribers on openstack-discuss with three weeks to go before the old lists are closed down for good). At the recommendation of David Medberry at the OpenStack Summit last week, this reminder is being sent individually to each of the old lists (not as a cross-post), and without any topic tag in case either might be resulting in subscribers missing it. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] We're combining the lists!
On 2018-11-10 11:02:15 +0100 (+0100), Thierry Carrez wrote: [...] > As we are ultimately planning to move lists to mailman3 (which decided > to drop the "topics" concept altogether), I don't think we planned to > add serverside mailman topics to the new list. Correct, that was covered in more detail in the longer original announcement linked from my past couple of reminders: http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html In short, we're recommending client-side filtering because server-side topic selection/management was not retained in Mailman 3 as Thierry indicates and we hope we might move our lists to an MM3 instance sometime in the not-too-distant future. > We'll still have standardized subject line topics. The current list > lives at: > > https://etherpad.openstack.org/p/common-openstack-ml-topics Which is its initial location for crowd-sourcing/brainstorming, but will get published to a more durable location like on lists.openstack.org itself or perhaps the Project-Team Guide once the list is in use. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list is open for subscriptions[0] now, but is not yet accepting posts until Monday November 19 and it's strongly recommended to subscribe before that date so as not to miss any messages posted there. The old lists will be configured to no longer accept posts starting on Monday December 3, but in the interim posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them any time after the 19th and not miss any messages. See my previous notice[1] for details. For those wondering, we have 207 subscribers so far on openstack-discuss with a little over a week to go before it will be put into use (and less than a month before the old lists are closed down for good). [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][neutron-release] feature/graphql branch rebase
On 2018-11-09 16:35:22 +1100 (+1100), Gilles Dubreuil wrote: > Could you please provide permission [1] to upload commit merges? > > I'm getting the following error after merging HEAD: > > $ git review -R feature/graphql > remote: > remote: Processing changes: refs: 1 > remote: Processing changes: refs: 1, done > To ssh://review.openstack.org:29418/openstack/neutron.git > ! [remote rejected] HEAD -> refs/publish/feature/graphql/bug/1802101 > (you are not allowed to upload merges) > error: failed to push some refs to > 'ssh://q-1ille...@review.openstack.org:29418/openstack/neutron.git' [...] Per openstack/neutron's ACL[*] you need to be made a member of the neutron-release group in Gerrit[**]. (This permission is tightly controlled to avoid people accidentally pushing merge commits, which is all too easy if you're not careful to keep your branches clean.) [*] https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/neutron.config [**] https://review.openstack.org/#/admin/groups/neutron-release -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cyborg]Weekly Meeting
On 2018-11-07 10:02:52 -0500 (-0500), Li Liu wrote: > It seems the meeting bot is having issues.. I would just paste the > meeting log here [...] The meetbot wasn't having any issues. The chair didn't issue an #endmeeting, and only a meeting chair is allowed to do so until an hour has elapsed from the #startmeeting. After an hour, anyone can so I did an #endmeeting in your channel and it wrapped up and wrote the minutes and logs as usual: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-11-07-14.16.html -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04)
On 2018-11-06 22:05:49 +0100 (+0100), Slawek Kaplonski wrote: [...] > also add jobs like "devstack-xenial" and "tempest-full-xenial" > which projects can use still for some time if their job on Bionic > would be broken now? [...] That opens the door to piecemeal migration, which (as we similarly saw during the Trusty to Xenial switch) will inevitably lead to projects who no longer gate on Xenial being unable to integration test against projects who don't yet support Bionic. At the same time, projects which have switched to Bionic will start merging changes which only work on Bionic without realizing it, so that projects which test on Xenial can't use them. In short, you'll be broken either way. On top of that, you can end up with projects that don't get around to switching completely before release comes, and then they're stuck having to manage a test platform transition on a stable branch. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] 2019 summit during May holidays?
On 2018-11-05 11:06:14 -0800 (-0800), Julia Kreger wrote: [...] > I imagine that as a community, it is near impossible to schedule > something avoiding holidays for everyone in the community. [...] Scheduling events that time of year is particularly challenging anyway because of the proximity of Ramadan, Passover and Easter/Lent. (We've already conflicted with Passover at least once in the past, if memory serves.) So yes, any random week you pick is already likely to hit a major public or religious holiday for some part of the World, and then you also have to factor in availability of venues and other logistics. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed
On 2018-11-01 09:27:03 -0400 (-0400), Doug Hellmann wrote: > Jeremy Stanley writes: > > > On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote: > > [...] > >> Did I miss any options or issues with this approach? > > > > https://review.openstack.org/578557 > > How high of a priority is rolling that feature out? It does seem to > eliminate this particular issue (even the edge cases described in the > commit message shouldn't affect us based on our typical practices), but > until we have one of the two changes in place we're going to have this > issue with every release we tag. It was written as a potential solution to this problem back when we first discussed it in June, but at the time we thought it might be solvable via job configuration with minimal inconvenience so that feature was put on hold as a fallback option in case we ended up needing it. I expect since it's already seen some review and is passing tests it could probably be picked back up fairly quickly now that alternative solutions have proven more complex than originally envisioned. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed
On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote: [...] > Did I miss any options or issues with this approach? https://review.openstack.org/578557 -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Storyboard python script
On 2018-10-31 22:39:01 + (+), Krishna Jain wrote: > I’m an animator with some coding experience picking up Python. I > came across your python-storyboardclient library, which would be > very helpful for automating our pipeline in Toon Boom Storyboard > Pro. [...] The python-storyboardclient library is for use with the free/libre open source StoryBoard task and defect tracker project described by the documentation located at https://docs.openstack.org/infra/storyboard/ and not the commercial "Toon Boom Storyboard Pro" animation software to which you seem to be referring. Sorry for the confusion! -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] We're combining the lists!
On 2018-10-29 12:58:09 -0400 (-0400), Jay Pipes wrote: > I'm not willing to subscribe with a password over a non-TLS > connection... [...] Up to you, certainly. You don't actually need to enter anything in the password fields on the subscription page (as the instructions on it also indicate). You can alternatively subscribe by sending E-mail to openstack-discuss-requ...@lists.openstack.org with a subject line of "subscribe" if you prefer. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] We're combining the lists! (was: Bringing the community together...)
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list is open for subscriptions[0] now, but is not yet accepting posts until Monday November 19 and it's strongly recommended to subscribe before that date so as not to miss any messages posted there. The old lists will be configured to no longer accept posts starting on Monday December 3, but in the interim posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them any time after the 19th and not miss any messages. See my previous notice[1] for details. For those wondering, we have 127 subscribers so far on openstack-discuss with 3 weeks to go before it will be put into use (and 5 weeks now before the old lists are closed down for good). [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures] Release of openstack/python-apmecclient failed
On 2018-10-26 06:46:23 -0500 (-0500), Sean McGinnis wrote: [...] > Release failed for this due to openstackci not being properly configured > for the pypi package upload. If whoever "pineunity" is can add the "openstackci" account as another maintainer for https://pypi.org/project/python-apmecclient/ then I'm happy to reenqueue that tag into Zuul. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures] Release of openstack-infra/shade failed
On 2018-10-24 16:08:26 +1100 (+1100), Tony Breeds wrote: > On Wed, Oct 24, 2018 at 03:23:53AM +, z...@openstack.org wrote: > > Build failed. > > > > - release-openstack-python3 > > http://logs.openstack.org/ab/abac67d7bb347e1caba4d74c81712de86790316b/release/release-openstack-python3/e84da68/ > > : POST_FAILURE in 2m 18s > > So this failed because pypi thinks there was a name collision[1]: > HTTPError: 400 Client Error: File already exists. See > https://pypi.org/help/#file-name-reuse for url: > https://upload.pypi.org/legacy/ > > AFACIT the upload was successful: > > shade-1.27.2-py2-none-any.whl : 2018-10-24T03:20:00 > d30a230461ba276c8bc561a27e61dcfd6769ca00bb4c652a841f7148a0d74a5a > shade-1.27.2-py2.py3-none-any.whl : 2018-10-24T03:20:11 > 8942b56d7d02740fb9c799a57f0c4ff13d300680c89e6f04dadb5eaa854e1792 > shade-1.27.2.tar.gz: 2018-10-24T03:20:04 > ebf40040b892f3e9bd4229fd05fff7ea24a08c51e46b7f2d8b3901ce34f51cbf [...] I think PyPI is right. Note the fact that there are not two but *three* artifacts there. We shouldn't be building both a py2 and py2.py3 wheel. The log you linked is uploaded shade-1.27.2-py2.py3-none-any.whl and tried (but failed) to upload shade-1.27.2.tar.gz. So where did shade-1.27.2-py2-none-any.whl come from then? Hold onto your hats folks: http://logs.openstack.org/ab/abac67d7bb347e1caba4d74c81712de86790316b/release/release-openstack-python/f38f2b9/job-output.txt.gz#_2018-10-24_03_20_02_134223 I suppose we don't expect a project to run both the release-openstack-python and release-openstack-python3 jobs on the same tags. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Naming the T release of OpenStack
On 2018-10-18 08:35:21 -0500 (-0500), Jay S Bryant wrote: [...] > When OpenStack developers think Denver, we think Trains. :-) [...] As, presumably, do many OpenStack operators now since the Ops Mid-Cycle event was co-located with the most recent PTG. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][vitrage][infra] SQLAlchemy-Utils version 0.33.6 breaks Vitrage gate
On 2018-10-18 14:57:23 +0200 (+0200), Andreas Jaeger wrote: > On 18/10/2018 14.15, Ifat Afek wrote: > > Hi, > > > > In the last three days Vitrage gate is broken due to the new requirement > > of SQLAlchemy-Utils==0.33.6. > > We get the following error [1]: > > > > [...] > > > Can we move back to version 0.33.5? or is there another solution? > > We discussed that on #openstack-infra, and fixed it each day - and then it > appeared again. > > https://review.openstack.org/611444 is the proposed fix for that - the > issues comes from the fact that we build wheels if there are none available > and had a race in it. > > I hope an admin can delete the broken file again and it works again tomorrow > - if not, best to speak up quickly on #openstack-infra, It's been deleted (again) and the suspected fix approved so hopefully it won't recur. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [python3] Enabling py37 unit tests
On 2018-10-15 17:34:24 -0400 (-0400), Corey Bryant wrote: [...] > I was assuming the desire to keep 3.5 stein support was for other distros > that plan to support stein with 3.5. If there are other distros which are planning to support OpenStack Stein on Python 3.5, then they should work with us to get testing in place on systems running their distro. That said, I'd be surprised if a new LTS server release of a distro targets Python 3.5... it's already over 3 years old, and 3.3 and 3.4 each got roughly 5 years before EOL so I'd expect 3.5 to no longer be supported upstream past September 2020. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [python3] Enabling py37 unit tests
On 2018-10-15 15:00:07 -0400 (-0400), Zane Bitter wrote: [...] > That said, I don't think we should be dropping support/testing for 3.5. > According to: > > https://governance.openstack.org/tc/reference/pti/python.html > > 3.5 is the only Python3 version that we require all projects to run tests > for. Until we update it to refer to the version provided by the test platforms we document at: https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions > Out goal is to get everyone running 3.6 unit tests by the end of Stein: > > https://governance.openstack.org/tc/goals/stein/python3-first.html#python-3-6-unit-test-jobs > > but we explicitly said there that we were not dropping support for 3.5 as > part of the goal, and should continue to do so until we can effect an > orderly transition later. [...] We're not dropping support for 3.5 as part of the python3-first goal, but would be dropping it as part of the switch from Ubuntu 16.04 LTS (which provides Python 3.5) to 18.04 LTS (which provides Python 3.6). In the past the OpenStack Infra team has prodded us to follow our documented testing platform policies as new versions become available, but now with a move to providing infrastructure services to other OSF projects as well we're on our own to police this. We _could_ decide that we're going to start running tests on multiple versions of Python 3 indefinitely (rather than as a transitional state during the switch from Ubuntu Xenial to Bionic) but that does necessarily mean running more jobs. We could also decide to start targeting different versions of Python than provided by the distros on which we run our tests (and build it from source ourselves or something) but I think that's only reasonable if we're going to also recommend that users deploy OpenStack on top of custom-compiled Python interpreters rather than the interpreters provided by server distros like RHEL and Ubuntu. So to sum up the above, it's less a question of whether we're dropping Python 3.5 testing in Stein, and more a question of whether we're going to continue requiring OpenStack to also be able to run on Ubuntu 16.04 LTS (which wasn't the latest LTS even at the start of the cycle). -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] Polygerrit (was: [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo)
On 2018-10-15 11:54:28 +0100 (+0100), Stephen Finucane wrote: [...] > As an aside, are there any plans to enable PolyGerrit [1] in the > OpenStack Gerrit instance? [...] I believe so, but first we need to upgrade to a newer Gerrit version which provides it (that in turn requires a newer Java which needs a server built from a newer distro version, which is all we've gotten through on the upgrade plan so far). -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc][all] meetings outside IRC
On 2018-10-13 23:29:46 +0200 (+0200), Mohammed Naser wrote: > I was going over our governance documents, more specifically this > section: > > "All project meetings are held in public IRC channels and > recorded." > > Does this mean that all official projects are *required* to hold > their project meetings over IRC? If an official project team holds a regular official team meeting, then it needs to be in a public IRC channel with published logs (either the channel log or a log specific to the meeting). > Is this a hard requirement or is this something that we're a bit > more 'lax about? [...] We've not generally required this of auxiliary meetings for official teams. Sub-team meetings and unofficial/ad-hoc team discussions over conference call or video chat media have been tolerated in the past. But for an official team meeting (if the team regularly holds one) we've stuck to the quoted expectation as a requirement as far as I'm aware. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [python3] Enabling py37 unit tests
On 2018-10-10 16:35:38 -0700 (-0700), Goutham Pacha Ravi wrote: [...] > Thanks Corey for starting this effort. I proposed changes to > manila repos to use your template [1] [2], but the interpreter's > not being installed, do you need to make any bindep changes to > enable the "universe" ppa and install python3.7 and python3.7-dev? [...] I think we need to just make sure that the standard Python jobs install the intended version of the interpreter. Using bindep for that particular purpose is mildly silly. The bindep.txt file is, first and foremost, a local developer convenience to let people know what unexpected packages they might need to install on their systems to run certain kinds of local tests. I really doubt any reasonable developer will be surprised that they need to install python3.7 before being able to successfully run `tox -e py37` nor is the error message confusing if they forget to do so. A couple projects have added python-version-specific bindep profiles which do nothing but install the corresponding interpreter, but adding things to bindep.txt purely to satisfy the CI system is backwards. Our CI jobs should do what we expect them to do by default. If the job says it's going to run unit tests under Python 3.7 then the job should make sure a suitable interpreter is installed to do so. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [python3] Enabling py37 unit tests
On 2018-10-10 16:00:40 -0500 (-0500), Sean McGinnis wrote: [...] > I would rather see us testing 3.5 and 3.7 versus 3.5, 3.6, and > 3.7. [...] I might have only pointed this out on IRC so far, but the expectation is that testing 3.5 and 3.6 at the same time was merely transitional since official OpenStack projects should be moving their testing from Ubuntu Xenial (which provides 3.5) to Ubuntu Bionic (which provides 3.6 and, now, 3.7 as well) during the Stein cycle and so will drop 3.5 testing on master in the process. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo
On 2018-10-10 13:35:00 -0500 (-0500), Greg Hill wrote: [...] > We plan to still have a CI gatekeeper, probably Travis CI, to make sure PRs > past muster before being merged, so it's not like we're wanting to > circumvent good contribution practices by committing whatever to HEAD. Travis CI has gained the ability to prevent you from merging changes which fail testing? Or do you mean something else when you refer to it as a "gatekeeper" here? > But the +2/+W rights thing was a huge PITA to deal with with so > few contributors, for sure. [...] Note that this is not a technical limitation at all, merely social convention. There are plenty of projects hosted on our infrastructure, some even official OpenStack projects, where contributor count is low enough that authors who are also core reviewers just review and approve their own changes for expediency. > There's also a sense that if a project is in the Openstack > umbrella, it's not useful outside Openstack, and Taskflow is > designed to be a general purpose library. [...] Be aware that the "OpenStack Infrastructure" is in the process of rebranding itself as "OpenDev" and we're working to eliminate mention of OpenStack on things that don't need it. This includes moving services to a new domain name, switching to other repository namespaces, putting mirroring to services like GitHub and Bitbucket under the direct control of teams who are interested in handling that with their own unique organizations in those platforms, and so on. It's progressing, though perhaps too slowly to solve your immediate concerns. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [python3] Enabling py37 unit tests
On 2018-10-10 16:09:21 +0200 (+0200), Andreas Jaeger wrote: [...] > So, I'm asking whether there is a good way to not duplicating all > jobs to run on all three interpreters. Do we really need testing > of all three versions? Or is testing with a subset a manageable > risk? OpenStack projects are hopefully switching to testing on Bionic instead of Xenial during the Stein cycle, so will stop testing with Python 3.5 on master when that happens (since Bionic provides 3.6/3.7 and no 3.5). -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [python3] Enabling py37 unit tests
On 2018-10-10 09:38:14 -0400 (-0400), Corey Bryant wrote: [...] > Another option could be to use a non-LTS image to use a supported > release. Let's avoid creating additional images unless there is a strong reason (every additional image means more load on our image builders, more space consumed in our providers, et cetera). Bionic seems like it will serve fine for this purpose now that it's got more than a pre-release of 3.7. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [python3] Enabling py37 unit tests
On 2018-10-10 08:45:39 -0400 (-0400), Corey Bryant wrote: [...] > Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter [...] Thanks for the heads up! Last time I looked it was still a pre-3.7.0 beta package, but looks like that has finally been updated to a proper release of the interpreter for Bionic in the last few weeks? -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] Open API 3.0 for OpenStack API
On 2018-10-10 13:24:28 +1100 (+1100), Gilles Dubreuil wrote: > On 09/10/18 23:58, Jeremy Stanley wrote: > > On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote: > > [...] > > > It seems to me that a major goal of openstacksdk is to hide > > > differences between clouds from the user. If the user is meant > > > to use a GraphQL library themselves, we lose this and the user > > > needs to figure it out themselves. Did I understand that > > > correctly? > > This is especially useful where the SDK implements business > > logic for common operations like "if the user requested A and > > the cloud supports features B+C+D then use those to fulfil the > > request, otherwise fall back to using features E+F". > > The features offered to the user don't have to change, it's just a > different architecture. > > The user doesn't have to deal with a GraphQL library, only the > client applications (consuming OpenStack APIs). And there are also > UI tools such as GraphiQL which allow to interact directly with > GraphQL servers. My point was simply that SDKs provide more than a simple translation of network API calls and feature discovery. There can also be rather a lot of "business logic" orchestrating multiple primitive API calls to reach some more complex outcome. The services don't want to embed this orchestrated business logic themselves, and it makes little sense to replicate the same algorithms in every single application which wants to make use of such composite functionality. There are common actions an application might wish to take which involve speaking to multiple APIs for different services to make specific calls in a particular order, perhaps feeding the results of one into the next. Can you explain how GraphQL eliminates the above reasons for an SDK? -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] Open API 3.0 for OpenStack API
On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote: [...] > It seems to me that a major goal of openstacksdk is to hide differences > between clouds from the user. If the user is meant to use a GraphQL library > themselves, we lose this and the user needs to figure it out themselves. > Did I understand that correctly? This is especially useful where the SDK implements business logic for common operations like "if the user requested A and the cloud supports features B+C+D then use those to fulfil the request, otherwise fall back to using features E+F". -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][Searchlight] Always build universal wheels
On 2018-10-05 07:20:01 -0400 (-0400), Doug Hellmann wrote: [...] > So, I think this all means we can leave the setup.cfg files as > they are and not worry about updating the wheel format flag. I continue to agree that, because of the reasons you state, it is not urgent to update setup.cfg (either to start supporting universal wheels or to follow the deprecation/transition on the section name in the latest wheel release), at least for projects relying on the OpenStack-specific release jobs. It is still technically more correct and I don't think we should forbid individual teams from also updating the setup.cfg files in their repositories should they choose to do so. That's all I've been trying to say. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] bringing back formal TC meetings
On 2018-10-05 07:40:00 -0400 (-0400), Doug Hellmann wrote: [...] > I had in mind "email the chair your topic suggestion" and then "the > chair emails the agenda to openstack-dev tagged [tc] a bit in advance of > the meeting". There would also probably be some standing topics, like > updates for ongoing projects. > > Does that work for everyone? [...] Seems fine to me. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures] Release of openstack/os-log-merger failed
On 2018-10-04 18:21:50 -0400 (-0400), Doug Hellmann wrote: > Jeremy Stanley writes: > > > On 2018-10-04 17:57:06 -0400 (-0400), Doug Hellmann wrote: > > [...] > >> HTTPError: 400 Client Error: Invalid value for classifiers. Error: > >> 'Topic:: Utilities' is not a valid choice for this field for url: > >> https://upload.pypi.org/legacy/ > >> > >> I'm not aware of any way to test those values easily before doing an > >> upload. If someone knows of a way, please let me know. > > > > I started writing a distcheck utility based on some validation code > > flit uses, but now that twine has a check option there is expressed > > intent by Dustin to do it there (see description of > > https://github.com/pypa/twine/pull/395 for details) which seems like > > a more natural solution anyway. > > OK, good. The existing check job for packaging already runs 'twine > check' so we should be covered when that feature is merged and released. Well, the TODO comment at https://github.com/pypa/warehouse/blob/55230d8/warehouse/forklift/legacy.py#L341-L343 expresses an interest in seeing Warehouse's (the current PyPI implementation) metadata validation code move to the https://pypi.org/project/packaging/ library, which should be clear to progress now that https://www.python.org/dev/peps/pep-0459/ (which supplanted the withdrawn PEP 426 mentioned in the TODO) has been finalized. Someone still needs to do that work, and then update `twine check` to use it (probably won't be me either, unless I somehow grow some extra spare time). This would be an awesome project for *someone* interested in making new inroads in the Python packaging community. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures] Release of openstack/os-log-merger failed
On 2018-10-04 17:57:06 -0400 (-0400), Doug Hellmann wrote: [...] > HTTPError: 400 Client Error: Invalid value for classifiers. Error: > 'Topic:: Utilities' is not a valid choice for this field for url: > https://upload.pypi.org/legacy/ > > I'm not aware of any way to test those values easily before doing an > upload. If someone knows of a way, please let me know. I started writing a distcheck utility based on some validation code flit uses, but now that twine has a check option there is expressed intent by Dustin to do it there (see description of https://github.com/pypa/twine/pull/395 for details) which seems like a more natural solution anyway. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tc] bringing back formal TC meetings
On 2018-10-04 13:40:05 -0400 (-0400), Doug Hellmann wrote: [...] > TC members, please reply to this thread and indicate if you would > find meeting at 1300 UTC on the first Thursday of every month > acceptable, and of course include any other comments you might > have (including alternate times). This time is acceptable to me. As long as we ensure that community feedback continues more frequently in IRC and on the ML (for example by making it clear that this meeting is expressly *not* for that) then I'm fine with resuming formal meetings. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][Searchlight] Always build universal wheels
On 2018-10-04 23:11:22 +0900 (+0900), Trinh Nguyen wrote: [...] > Please avoid adding universal wheels to the project setup.cfg. [...] Why would you avoid also adding it to the setup.cfg? The change you cited is merely to be able to continue building universal wheels for projects while the setup.cfg files are corrected over time, to reduce the urgency of doing so. Wheel building happens in more places than just our CI system, so only fixing it in CI is not a good long-term strategy. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [goal][python3] week 7 update
On 2018-09-28 13:58:52 -0400 (-0400), William M Edmonds wrote: > Doug Hellmann wrote on 09/26/2018 06:29:11 PM: > > > * We do not want to set the override once in testenv, because that > > breaks the more specific versions used in default environments like > > py35 and py36 (at least under older versions of tox). > > > I assume that something like > https://git.openstack.org/cgit/openstack/nova-powervm/commit/?id=fa64a93c965e6a6692711962ad6584534da81695 > should be a perfectly acceptable alternative in at least some cases. > Agreed? I believe the confusion is that ignore_basepython_conflict didn't appear in a release of tox until after we started patching projects for this effort (in fact it was added to tox in part because we discovered the issue in originally attempting to use basepython globally). -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder][glance][osc][sdk] Image Encryption for OpenStack (proposal)
On 2018-09-28 08:51:46 -0300 (-0300), Erlon Cruz wrote: > I don't know if our workflow supports this, but it would be nice > to have a place to place cross-projec changes like that (something > like, openstack-cross-projects-specs), and use that as a initial > point for high level discussions. But for now, you can start > creating specs for the projects involved. [...] If memory serves, the biggest challenge around that solution was determining who approves such proposals since they still need per-project specs for the project-specific details anyway. Perhaps someone who has recently worked on a feature which required coordination between several teams (but not a majority of teams like our cycle goals process addresses) can comment on what worked for them and what improvements they would make on the process they followed. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc][elections] Stein TC Election Results
On 2018-09-27 20:00:42 -0400 (-0400), Mohammed Naser wrote: [...] > A big thank you to our election team who oversees all of this as > well :) [...] I wholeheartedly concur! And an even bigger thank you to the 5 candidates who were not elected this term; please run again in the next election if you're able, I think every one of you would have made a great choice for a seat on the OpenStack TC. Our community is really lucky to have so many qualified people eager to take on governance tasks. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ptl][release] Proposed changes for cycle-with-milestones deliverables
On 2018-09-26 09:22:30 -0500 (-0500), Sean McGinnis wrote: [...] > It tests the release automation machinery to identify problems > before the RC and final release crunch time. [...] More to the point, it helped spot changes to projects which made it impossible to generate and publish their release artifacts. Coverage has improved for finding these issues before merging now, as well as in flight tests on proposed releases, making the risk lower than it used to be. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [storyboard] why use different "bug" tags per project?
On 2018-09-26 00:50:16 -0600 (-0600), Chris Friesen wrote: > At the PTG, it was suggested that each project should tag their bugs with > "-bug" to avoid tags being "leaked" across projects, or something > like that. > > Could someone elaborate on why this was recommended? It seems to me that > it'd be better for all projects to just use the "bug" tag for consistency. > > If you want to get all bugs in a specific project it would be pretty easy to > search for stories with a tag of "bug" and a project of "X". Because stories are a cross-project concept and tags are applied to the story, it's possible for a story with tasks for both openstack/nova and openstack/cinder projects to represent a bug for one and a new feature for the other. If they're tagged nova-bug and cinder-feature then that would allow them to match the queries those teams have defined for their worklists, boards, et cetera. It's of course possible to just hand-wave that these intersections are rare enough to ignore and go ahead and use generic story tags, but the recommendation is there to allow teams to avoid disagreements in such cases. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [storyboard] Prioritization?
On 2018-09-24 19:31:17 -0400 (-0400), Doug Hellmann wrote: > That came up as a suggestion, too. The challenge there is that we > cannot (as far as I know) sort on tags. So even if we have tags, > we can't create a list of stories that is ordered automatically > based on the priority. Maybe there's a solution to that? A board with automatic lanes for each priority tag? That way you can also have a lane for "stories with incomplete tasks for projects in my project-group but which haven't been prioritized yet" and be able to act on/triage them accordingly. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [storyboard] Prioritization?
On 2018-09-24 18:35:04 -0400 (-0400), Doug Hellmann wrote: [...] > At the PTG there was feedback from at least one team that > consumers of the data in storyboard want a priority setting on > each story. Historically the response to that has been that > different users will have different priorities, so each of them > using worklists is the best way to support those differences of > opinion. > > I think we need to reconsider that position if it's going to block > adoption. I think Ben's case is an excellent second example of > where having a field to hold some sort of priority value would be > useful. The alternative suggestion, for teams who want to be able to flag some sort of bucketed priorities, is to use story tags. We could even improve the import tool to accept some sort of priority-to-tag-name mapping so that, say, when we import bugs for Oslo their oslo-critical tag is applied to any with a critical bugtask, oslo-medium to any with medium priority tasks, and so on. Not all teams using StoryBoard will want to have a bucketed priority scheme, and those who do won't necessarily want to use the same number or kinds of priorities. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] Capturing Feedback/Input
On 2018-09-21 12:55:09 -0500 (-0500), Melvin Hillsman wrote: [...] > Yeah unfortunately we do have a tendency to overthink/complicate > things. Not saying Storyboard is the right tool but suggested > rather than having something extra to maintain was what I > understood. There are at least 3 things that were to be addressed: > > - single pane so folks know where to provide/see updates Not all OpenStack projects use the same task trackers currently and there's no guarantee that they ever will, so this is a best effort only. Odds are you may wind up duplicating some information also present in the Nova project on Launchpad, the Tripleo project on Trello and the Foobly project on Bugzilla (I made this last one up, in case it's not obvious). > - it is not a catchall/dumpsite If it looks generic enough, it will become that unless there are people actively devoted to triaging and pruning submissions to curate them... a tedious and thankless long-term commitment, to be sure. > - something still needs to be flushed out/prioritized (Public > Cloud WG's missing features spreadsheet for example) This is definitely a good source of input, but still needs someone to determine which various projects/services the tasks for them get slotted into and then help prioritizing and managing spec submissions on a per-team basis. > - not specific to a single project (i thought this was a given > since there is already a process/workflow for single project) The way to do that on storyboard.openstack.org is to give it a project of its own. Basically just couple it to a new, empty Git repository and then the people doing these tasks still have the option of also putting that repository to some use later (for example, to house their workflow documentation). > I could very well be wrong so I am open to be corrected. From my > perspective the idea in the room was to not circumvent anything > internal but rather make it easy for external viewers, passerbys, > etc. When feedback is gathered from Ops Meetup, OpenStack Days, > Local meetups/events, we discussed putting that here as well. It seems a fine plan, just keep in mind that documenting and publishing feedback doesn't magically translate into developers acting on any of it (and this is far from the first time it's been attempted). -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release][collectd-openstack-plugins] Schedule new release?
On 2018-09-21 05:53:08 -0500 (-0500), Sean McGinnis wrote: [...] > collectd-openstack-plugins does not appear to be an official repo under > governance [1]. For these types of projects to do a release, the team would > need to push a tag to the repo. That will trigger some post jobs to run that > will create and publish tarballs. Some basic information (though slightly > different context) can be found here [2]. > > [1] > http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml > [2] > https://docs.openstack.org/infra/manual/creators.html#prepare-an-initial-release Perhaps slightly more aligned with the context of the question is this document: https://docs.openstack.org/infra/manual/drivers.html#tagging-a-release -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] [all][tc] We're combining the lists! (was: Bringing the community together...)
On 2018-09-20 15:46:43 -0600 (-0600), Doug Hellmann wrote: [...] > Since last week there was some discussion of including the openstack-tc > mailing list among these lists to eliminate confusion caused by the fact > that the list is not configured to accept messages from all subscribers > (it's meant to be used for us to make sure TC members see meeting > announcements). [...] I think it makes sense. The Interop WG also indicated they'd like to do the same with theirs. In cases like these where the lists in question have much lower volume anyway, I don't think any special handling is needed. Basically any time after November 19 just send a post to the old list saying that subsequent messages need to go to openstack-discuss instead, and then immediately set it to no longer accept new messages. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] We're combining the lists! (was: Bringing the community together...)
ryone from the four older lists to the new one and call it a day? Well, I personally would find it rude if a list admin mass-subscribed me to a mailing list I hadn't directly requested. Doing so may even be illegal in some jurisdictions (we could probably make a case that it's warranted, but it's cleaner to not need to justify such an action). Much like the answer to the previous question, the changes in behavior (and also in the list name itself) are likely to cause lots of subscribers to need to update their message filtering rules anyway. I know by default it would all start landing in my main inbox, and annoy me mightily. What subject tags are we going to be using to identify messages of interest and to be able to skip those we don't care about? We're going to continuously deploy a list of recommended subject tags in a visible space, either on the listserv's WebUI or the Infra Manual and link to it liberally. There is already an initial set of suggestions[5] being brainstormed, so feel free to add any there you feel might be missing. It's not yet been decided whether we'll also include these in the Mailman "Topics" configuration to enable server-side filtering on them (as there's a good chance we'll be unable to continue supporting that after an upgrade to Mailman 3), so for now it's best to assume you may need to add them to your client-side filters if you rely on that capability. If you have any further questions, please feel free to respond to this announcement so we can make sure they're answered. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000493.html [2] http://lists.openstack.org/pipermail/openstack-dev/2018-August/134074.html [3] https://etherpad.openstack.org/p/infra-ptg-denver-2018 [4] https://www.ietf.org/rfc/rfc2369.txt [5] https://etherpad.openstack.org/p/common-openstack-ml-topics -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal
On 2018-09-18 14:52:28 +0200 (+0200), Sylvain Bauza wrote: [...] > Why are we discussing about WeChat now? Is that because a large > set of our contributors *can't* access IRC or because they > *prefer* any other? Until we get confirmation either way, I'm going to work under the assumption that there are actual network barriers to using IRC for these contributors and that it's not just a matter of preference. I mainly want to know the source of these barriers because that will determine how to go about addressing them. If it's restrictions imposed by employers, it may be hard for employees to raise the issue in predominantly confrontation-averse cultures. The First Contact SIG is working on a document which outlines the communications and workflows used by our community with a focus on explaining to managers and other staff at contributing organizations what allowances they can make to ease and improve the experience of those they've tasked with working upstream. If the barriers are instead imposed by national government, then urging contributors within those borders to flaunt the law and interact with the rest of our community over IRC is not something which should be taken lightly. That's not to say it can't be solved, but the topic then is a much more political one and our community may not be an appropriate venue for those discussions. > In the past, we made clear for a couple of times why IRC is our > communication channel. I don't see those reasons to be invalid > now, but I'm still open to understand the problems about why our > community becomes de facto fragmented. I think the extended community is already fragmented across a variety of discussion fora. Some watch for relevant hashtags on Twitter and engage in discussions there. I gather there's an unofficial OpenStack Slack channel where lots of newcomers show up to ask questions because they assume the OpenStack community relies on Slack the same way the Kubernetes community does, and so a few volunteers from our community hang out there and try to redirect questions to more appropriate places. I've also heard tell of an OpenStack subReddit which some stackers help moderate and try to provide damage control/correct misstatements there. I don't think these are necessarily a problem, and the members of our community who work to spread accurate information to these places are in many cases helping reduce the actual degree of fragmentation. I'm still trying to make up my mind on 602697 which is why I haven't weighed in on the proposal yet. So far I feel like it probably doesn't bring anything new, since we already declare how and where official discussion takes place and the measure doesn't make any attempt to change that. We also don't regulate where unofficial discussions are allowed to take place, and so it doesn't open up any new possibilities which were previously disallowed. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal
On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote: [...] > I can understand that IRC cannot be used in China which is very > painful and mostly it is used weChat. [...] I have yet to hear anyone provide first-hand confirmation that access to Freenode's IRC servers is explicitly blocked by the mainland Chinese government. There has been a lot of speculation that the usual draconian corporate firewall policies (surprise, the rest of the World gets to struggle with those too, it's not just a problem in China) are blocking a variety of messaging protocols from workplace networks and the people who encounter this can't tell the difference because they're already accustomed to much of their other communications being blocked at the border. I too have heard from someone who's heard from someone that "IRC can't be used in China" but the concrete reasons why continue to be missing from these discussions. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [election][tc]Question for candidates about global reachout
On 2018-09-18 10:23:33 +0800 (+0800), Zhipeng Huang wrote: [...] > Jeremy, what I'm saying here, and also addressed in comments with > the related resolution patch, is that personality reasons are the > ones that we have to respect and no form of governance change > could help solve the problem. However other than that, we could > always find a way to address the issue for remedies, if we don't > have a good answer now maybe we will have sometime later. > > Preference on social tooling is something that the technical > committee is able to address, with isolation of usage of > proprietary tools for certain scenario and also strict policy on > enforcing the open source communication solutions we have today as > the central ones the community will continue to use. This is not > an unsolvable problem given that we have a technical committee, > but personality issues are, no matter what governance instrument > we have. Once again, I think we're talking past each other. I was replying to (and quoted from) the provided sample rejection letter. First I wanted to point out that I had already rejected the premise earlier on this thread even though it was suggested that no rejection had yet been provided. Second, the sample letter seemed to indicate what I believe to be a fundamental misunderstanding among those pushing this issue: the repeated attempts I've seen so far to paint a disinterest in participating in wechat interactions as mere "personal preference," and the idea that those who hold this "preference" are somehow weak or afraid of the people they'll encounter there. For me, it borders on insulting. I (and I believe many others) have strong ideological opposition to participating in these forums, not mere personal preferences. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [election][tc]Question for candidates about global reachout
On 2018-09-18 07:27:26 +0800 (+0800), Zhipeng Huang wrote: [...] > On another side note, there has not been a (maybe I missed) good > "no" vote message I was looking for. > > A good quality "no" message could something like this in my > opinion (and this is just one of many possibilities): > > "Thanks for invitation but no I would not like to use social media > apps other than IRC. General social media apps are open to a more > variety of people than in IRC channels and there are personalities > or social characters that I found myself just cannot cope with. > Moreover social media apps demands instant response, or at least > has the expectation for one, in its nature and it would make me > feel pressured all the time. So no thank you I would not use > social media in any form, however if you do have good technical > questions from the social apps, please feel free to relay to me > and I'm glad to help when I have the bandwidth" This seems to completely miss the reasons I personally reject such platforms. I don't use proprietary tools or services for interacting with our community, I avoid relying on products from companies which attempt to track or share my location and activities for their own profit or to report them to various government agencies, and I have no interest in owning a "smart phone" (which some services such as wechat outright require). At least for me, the example rejection you proposed above is a miss on all counts... I am plenty capable of coping with any of the "personalities or social characters" I'm likely to encounter on those services (I'm quite certain IRC is where you're going to find some of the worst and *most* intolerable characters of any discussion medium). I also am accustomed to providing a near instant response to urgent requests in IRC, and at the same time don't feel particularly "pressured" to do so. And I _do_ use some social media: both IRC and mailing lists are in fact legitimate examples of social media. I'm really not even opposed to using other forms as long as they rely on open protocols and both the client _and_ server software are available under a free/libre open source license. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [election][tc]Question for candidates about global reachout
On 2018-09-16 14:14:41 +0200 (+0200), Jean-philippe Evrard wrote: [...] > - What is the problem joining Wechat will solve (keeping in mind the > language barrier)? As I understand it, the suggestion is that mere presence of project leadership in venues where this emerging subset of our community gathers would provide a strong signal that we support them and care about their experience with the software. > - Isn't this problem already solved for other languages with > existing initiatives like local ambassadors and i18n team? Why > aren't these relevant? [...] It seems like there are at least couple of factors at play here: first the significant number of users and contributors within mainland China compared to other regions (analysis suggests there were nearly as many contributors to the Rocky release from China as the USA), but second there may be facets of Chinese culture which make this sort of demonstrative presence a much stronger signal than it would be in other cultures. > - Pardon my ignorance here, what is the problem with email? (I > understand some chat systems might be blocked, I thought emails > would be fine, and the lowest common denominator). Someone in the TC room (forgive me, I don't recall who now, maybe Rico?) asserted that Chinese contributors generally only read the first message in any given thread (perhaps just looking for possible announcements?) and that if they _do_ attempt to read through some of the longer threads they don't participate in them because the discussion is presumed to be over and decisions final by the time they "reach the end" (I guess not realizing that it's perfectly fine to reply to a month-old discussion and try to help alter course on things if you have an actual concern?). > I also have technical questions about 'wechat' (like how do you > use it without a smartphone?) and the relevance of tools we > currently use, but this will open Pandora's box, and I'd rather > not spend my energy on closing that box right now :D Not that I was planning on running it myself, but I did look into the logistics. Apparently there is at least one free/libre open source wechat client under active development but you still need to use a separate mobile device to authenticate your client's connection to wechat's central communication service. By design, it appears this is so that you can't avoid reporting your physical location (it's been suggested this is to comply with government requirements for tracking citizens participating in potentially illegal discussions). They also go to lengths to prevent you from running the required mobile app within an emulator, since that would provide a possible workaround to avoid being tracked. Further, there is some history of backdoors getting included in the software, so you need to use it with the expectation that you're basically handing over all communications and content for which you use that mobile device to wechat developers/service operators and, by proxy, the Chinese government. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [election][tc]Question for candidates about global reachout
On 2018-09-14 13:52:50 -0600 (-0600), Zhipeng Huang wrote: > This is a joint question from mnaser and me :) > > For the candidates who are running for tc seats, please reply to > this email to indicate if you are open to use certain social media > app in certain region (like Wechat in China, Line in Japan, etc.), > in order to reach out to the OpenStack developers in that region > and help them to connect to the upstream community as well as > answering questions or other activities that will help. (sorry for > the long sentence ... ) [...] I respect that tool choices can make a difference in enabling or improving our outreach to specific cultures. I'll commit to personally rejecting presence on proprietary social media services so as to demonstrate that public work can be done within our community while relying exclusively on free/libre open source software. I recognize the existence of the free software movement as a distinct culture with whom we could do a better job of connecting. If as a community we promote and embrace non-free tools we will only continue to alienate them, so I'm happy to serve as an example that it is possible to be an engaged and effective contributor to our community without compromising those ideals. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels
On 2018-09-11 16:53:05 + (+), Jeremy Stanley wrote: > On 2018-08-01 08:40:51 -0700 (-0700), James E. Blair wrote: > > Monty Taylor writes: > > > On 08/01/2018 12:45 AM, Ian Wienand wrote: > > > > I'd suggest to start, people with an interest in a channel can > > > > request +r from an IRC admin in #openstack-infra and we track > > > > it at [2] > > > > > > To mitigate the pain caused by +r - we have created a channel > > > called #openstack-unregistered and have configured the channels > > > with the +r flag to forward people to it. > [...] > > It turns out this was a very popular option, so we've gone ahead > > and performed this for all channels registered with accessbot. > [...] > > We rolled this back 5 days ago for all channels and haven't had any > new reports of in-channel spamming yet. Hopefully this means the > recent flood is behind us now but definitely let us know (replying > on this thread or in #openstack-infra on Freenode) if you see any > signs of resurgence. And then it was turned back on again a few hours ago after a new wave of spam cropped up. We'll try to continue to keep an eye on things. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)
On 2018-09-12 17:50:30 -0600 (-0600), Matt Riedemann wrote: [...] > Again, I'm not saying TC members should be doing all of the work > themselves. That's not realistic, especially when critical parts > of any major effort are going to involve developers from projects > on which none of the TC members are active contributors (e.g. > nova). I want to see TC members herd cats, for lack of a better > analogy, and help out technically (with code) where possible. I can respect that. I think that OpenStack made a mistake in naming its community management governance body the "technical" committee. I do agree that having TC members engage in activities with tangible outcomes is preferable, and that the needs of the users of its software should weigh heavily in prioritization decisions, but those are not the only problems our community faces nor is it as if there are no other responsibilities associated with being a TC member. > Given the repeated mention of how the "help wanted" list continues > to not draw in contributors, I think the recruiting role of the TC > should take a back seat to actually stepping in and helping work > on those items directly. For example, Sean McGinnis is taking an > active role in the operators guide and other related docs that > continue to be discussed at every face to face event since those > docs were dropped from openstack-manuals (in Pike). I completely agree that the help wanted list hasn't worked out well in practice. It was based on requests from the board of directors to provide some means of communicating to their business-focused constituency where resources would be most useful to the project. We've had a subsequent request to reorient it to be more like a set of job descriptions along with clearer business use cases explaining the benefit to them of contributing to these efforts. In my opinion it's very much the responsibility of the TC to find ways to accomplish these sorts of things as well. > I think it's fair to say that the people generally elected to the > TC are those most visible in the community (it's a popularity > contest) and those people are generally the most visible because > they have the luxury of working upstream the majority of their > time. As such, it's their duty to oversee and spend time working > on the hard cross-project technical deliverables that operators > and users are asking for, rather than think of an infinite number > of ways to try and draw *others* to help work on those gaps. But not everyone who is funded for full-time involvement with the community is necessarily "visible" in ways that make them electable. Higher-profile involvement in such activities over time is what gets them the visibility to be more easily elected to governance positions via "popularity contest" mechanics. > As I think it's the role of a PTL within a given project to have a > finger on the pulse of the technical priorities of that project > and manage the developers involved (of which the PTL certainly may > be one), it's the role of the TC to do the same across openstack > as a whole. If a PTL doesn't have the time or willingness to do > that within their project, they shouldn't be the PTL. The same > goes for TC members IMO. Completely agree, I think we might just disagree on where to strike the balance of purely technical priorities for the TC (as I personally think the TC is somewhat incorrectly named). -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)
On 2018-09-12 17:05:17 -0600 (-0600), Lance Bragstad wrote: [...] > IMHO, I think the point Matt is making here is more about ensuring > sure we have people to do what we've agreed upon, as a community, > as being mission critical. Enablement is imperative, but no matter > how good we are at it, sometimes we really just needs hands to do > the work. [...] Sure, and I'm saying that instead I think the influence of TC members _can_ be more valuable in finding and helping additional people to do these things rather than doing it all themselves, and it's not just about the limited number of available hours in the day for one person versus many. The successes goal champions experience, the connections they make and the elevated reputation they gain throughout the community during the process of these efforts builds new leaders for us all. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)
On 2018-09-12 17:03:10 -0600 (-0600), Matt Riedemann wrote: > On 9/12/2018 4:14 PM, Jeremy Stanley wrote: > > I think Doug's work leading the Python 3 First effort is a great > > example. He has helped find and enable several other goal champions > > to collaborate on this. I appreciate the variety of other things > > Doug already does with his available time and would rather he not > > stop doing those things to spend all his time acting as a project > > manager. > > I specifically called out what Doug is doing as an example of > things I want to see the TC doing. I want more/all TC members > doing that. With that I was replying to Zhipeng Huang's message which you have trimmed above, specifically countering the assertion that recruiting others to help with these efforts is a waste of time and that TC members should simply do all the work themselves instead. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)
On 2018-09-12 16:03:12 -0600 (-0600), Zhipeng Huang wrote: > On Wed, Sep 12, 2018 at 3:55 PM Jeremy Stanley wrote: > > On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote: > > [...] > > > So I encourage all elected TC members to work directly with the > > > various SIGs to figure out their top issue and then work on > > > managing those deliverables across the community because the TC is > > > particularly well suited to do so given the elected position. > > [...] > > > > I almost agree with you. I think the OpenStack TC members should be > > actively engaged in recruiting and enabling interested people in the > > community to do those things, but I don't think such work should be > > solely the domain of the TC and would hate to give the impression > > that you must be on the TC to have such an impact. > > Jeremy, this is not to say that one must be on the TC to have such an > impact, it is that TC has the duty more than anyone else to get this > specific cross-project goal done. I would even argue it is not the job > description of TC to enable/recruit, but to just do it. I think Doug's work leading the Python 3 First effort is a great example. He has helped find and enable several other goal champions to collaborate on this. I appreciate the variety of other things Doug already does with his available time and would rather he not stop doing those things to spend all his time acting as a project manager. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] Open letter/request to TC candidates (and existing elected officials)
On 2018-09-12 09:47:27 -0600 (-0600), Matt Riedemann wrote: [...] > So I encourage all elected TC members to work directly with the > various SIGs to figure out their top issue and then work on > managing those deliverables across the community because the TC is > particularly well suited to do so given the elected position. [...] I almost agree with you. I think the OpenStack TC members should be actively engaged in recruiting and enabling interested people in the community to do those things, but I don't think such work should be solely the domain of the TC and would hate to give the impression that you must be on the TC to have such an impact. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Ongoing spam in Freenode IRC channels
On 2018-08-01 08:40:51 -0700 (-0700), James E. Blair wrote: > Monty Taylor writes: > > On 08/01/2018 12:45 AM, Ian Wienand wrote: > > > I'd suggest to start, people with an interest in a channel can > > > request +r from an IRC admin in #openstack-infra and we track > > > it at [2] > > > > To mitigate the pain caused by +r - we have created a channel > > called #openstack-unregistered and have configured the channels > > with the +r flag to forward people to it. [...] > It turns out this was a very popular option, so we've gone ahead > and performed this for all channels registered with accessbot. [...] We rolled this back 5 days ago for all channels and haven't had any new reports of in-channel spamming yet. Hopefully this means the recent flood is behind us now but definitely let us know (replying on this thread or in #openstack-infra on Freenode) if you see any signs of resurgence. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [StoryBoard] Project Update/Some New Things
On 2018-09-10 14:43:18 +0100 (+0100), Adam Coldrick wrote: [...] > # Linking to projects by name > > Keen observers might've noticed that StoryBoard recently grew the ability > to link to projects by name, rather than by ID number. All the links to > projects in the UI have been replaced with links in this form, and its > probably a good idea for folk to start using them in any documentation > they have. These links look like > > https://storyboard.openstack.org/#!/project/openstack-infra/storyboard [...] Worth noting, this has made it harder to find the numeric project ID without falling back on the API. Change https://review.openstack.org/600893 merged to the releases repository yesterday allowing deliverable repositories to be referenced by their StoryBoard project name rather than only the ID number. If there are other places in tooling and automation where we relied on the project ID number, work should be done to update those similarly. > # Finding stories from a task ID > > It is now possible to navigate to a story given just a task ID, if for > whatever reason that's all the information you have available. A link like > > https://storyboard.openstack.org/#!/task/12389 > > will work. This will redirect to the story containing the task, and is the > first part of work to support linking directly to an individual task in a > story. [...] As an aside, I think this makes it possible now for us to start hyperlinking Task footers in commit messages within the Gerrit change view. I'll try and figure out what we need to adjust in our Gerrit commentlink and its-storyboard plugin configs to make that happen. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [election][tc] Opinion about 'PTL' tooling
On 2018-09-10 06:38:11 -0600 (-0600), Mohammed Naser wrote: > I think something we should take into consideration is *what* you > consider health because the way we’ve gone about it over health > checks is not something that can become a toolkit because it was > more of question asking, etc [...] I was going to follow up with something similar. It's not as if the TC has a toolkit of any sort at this point to come up with the information we're assembling in the health tracker either. It's built up from interviewing PTLs, reading meeting logs, looking at the changes which merge to teams' various deliverable repositories, asking around as to whether they've missed important deadlines such as release milestones (depending on what release models they follow) or PTL nominations, looking over cycle goals to see how far along they are, and so on. Extremely time-consuming which is why it's taken us most of a release cycle and we still haven't finished a first pass. Assembling some of this information might be automatable if we make adjustments to how the data/processes on which it's based are maintained, but at this point we're not even sure which ones are problem indicators at all and are just trying to provide the clearest picture we can. If we come up with a detailed checklist and some of the checks on that list can be automated in some way, that seems like a good thing. However, the original data should be publicly accessible so I don't see why it needs to be members of the technical committee who write the software to collect that. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Storyboard][Searchlight] Where can I find the project ID on Storyboard?
On 2018-09-08 10:10:37 +0900 (+0900), Trinh Nguyen wrote: > I'm adding Searchlight projects to the Stein deliverables with the > storyboard attribute. Where can I find the Searchlight projects ID? Right > now I can only see the project links. It can be looked up from the API like so: https://storyboard.openstack.org/api/v1/projects/openstack/searchlight However I agree expecting users to do this isn't particularly friendly. Since this was in service of filling out release management details, I've pushed https://review.openstack.org/600893 for review to support optionally using the project name now that SB supports querying with it and uses it by default in webclient URLs. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Summit Forum in Berlin: Topic Selection Process
On 2018-09-06 15:03:52 -0500 (-0500), Matt Riedemann wrote: > On 9/6/2018 2:56 PM, Jeremy Stanley wrote: > > On 2018-09-06 14:31:01 -0500 (-0500), Matt Riedemann wrote: > > > On 8/29/2018 1:08 PM, Jim Rollenhagen wrote: > > > > On Wed, Aug 29, 2018 at 12:51 PM, Jimmy McArthur > > > <mailto:ji...@openstack.org>> wrote: > > > > > > > > > > > > Examples of typical sessions that make for a great Forum: > > > > > > > > Strategic, whole-of-community discussions, to think about the big > > > > picture, including beyond just one release cycle and new > > > > technologies > > > > > > > > e.g. OpenStack One Platform for containers/VMs/Bare Metal > > > > (Strategic > > > > session) the entire community congregates to share opinions on how > > > > to make OpenStack achieve its integration engine goal > > > > > > > > > > > > Just to clarify some speculation going on in IRC: this is an example, > > > > right? Not a new thing being announced? > > > > > > > > // jim > > > FYI for those that didn't see this on the other ML: > > > > > > http://lists.openstack.org/pipermail/foundation/2018-August/002617.html > > [...] > > > > While I agree that's a great post to point out to all corners of the > > community, I don't see what it has to do with whether "OpenStack One > > Platform for containers/VMs/Bare Metal" was an example forum topic. > > Because if I'm not mistaken it was the impetus for the hullabaloo in the tc > channel that was related to the foundation ML post. It would be more accurate to say that community surprise over the StarlingX mention in Vancouver keynotes caused some people to (either actually or merely in half-jest) start looking for subtext everywhere indicating the next big surprise announcement. The discussion[*] in #openstack-tc readily acknowledged that most of its participants didn't think "OpenStack One Platform for containers/VMs/Bare Metal" was an actual proposal for a forum discussion much less announcement of a new project, but were just looking for an opportunity to show feigned alarm and sarcasm. The most recent discussion[**] leading up to the foundation ML "OSF Open Infrastructure Projects" update occurred the previous week. That E-mail did go out the day after the forum topic brainstorming example discussion, but was unrelated (and already in the process of being put together by then). [*] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-29.log.html#t2018-08-29T16:55:37 [**] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-23.log.html#t2018-08-23T16:23:00 -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack Summit Forum in Berlin: Topic Selection Process
On 2018-09-06 14:31:01 -0500 (-0500), Matt Riedemann wrote: > On 8/29/2018 1:08 PM, Jim Rollenhagen wrote: > > On Wed, Aug 29, 2018 at 12:51 PM, Jimmy McArthur > <mailto:ji...@openstack.org>> wrote: > > > > > > Examples of typical sessions that make for a great Forum: > > > > Strategic, whole-of-community discussions, to think about the big > > picture, including beyond just one release cycle and new technologies > > > > e.g. OpenStack One Platform for containers/VMs/Bare Metal (Strategic > > session) the entire community congregates to share opinions on how > > to make OpenStack achieve its integration engine goal > > > > > > Just to clarify some speculation going on in IRC: this is an example, > > right? Not a new thing being announced? > > > > // jim > > FYI for those that didn't see this on the other ML: > > http://lists.openstack.org/pipermail/foundation/2018-August/002617.html [...] While I agree that's a great post to point out to all corners of the community, I don't see what it has to do with whether "OpenStack One Platform for containers/VMs/Bare Metal" was an example forum topic. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-I18n] [storyboard] [I18n] Can Storyboard web pages be translatable to multiple languages?
On 2018-09-06 11:06:34 +0900 (+0900), Ian Y. Choi wrote: > I wanna ask whether https://storyboard.openstack.org/ web pages > can be translatable to multiple languages (e.g., Chinese, > Japanese, Korean, German, French, Spanish, ...) or not. [...] As also discussed in #storyboard I think this is an interesting idea, particularly for organizations who may want to use StoryBoard deployments where most users are fluent in one of those other languages (and perhaps not at all with English). I do think interface translation is potentially useful for the OpenStack community's storyboard.openstack.org service too, though we'll want to keep in mind that for most of the projects hosted there English is explicitly preferred to increase collaboration (same as with most OpenStack community mailing lists, IRC channels, code review and so on). We may discover that we need to find ways to point out to people, particularly those arriving there for the first time, that they should file stories in English if at all possible even though the interface may be presented in their personally preferred language instead. I've added this topic to https://etherpad.openstack.org/p/sb-stein-ptg-planning and am looking forward to seeing you in Denver! -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Storyboard][Searchlight] Commits of searchlight-specs are not attached to the story
On 2018-09-06 16:39:13 +0900 (+0900), Trinh Nguyen wrote: > Looks like the commits for searchlight-specs are not attached to > the story on Storyboard. Example: > > Commit: https://review.openstack.org/#/c/600316/ > Story: https://storyboard.openstack.org/#!/story/2003677 > > Is there anything that I need to do to link those 2 together? In change 600316 you included a "Task: #2619" footer, when the actual task you seem to have wanted to reference was 26199 (task 2619 is associated with unrelated story 2000403). -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] better name for placement
On 2018-09-05 17:01:49 +0200 (+0200), Thomas Goirand wrote: [...] > In a distro, no 2 package can hold the same file. That's > forbidden. This has nothing to do if someone has to "import > placemement" or not. > > Just saying this, but *not* that we should rename (I didn't spot > any conflict yet and I understand the pain it would induce). This > command returns nothing: > > apt-file search placement | grep python3/dist-packages/placement Well, also since the Placement maintainers have expressed that they aren't interested in making Python API contracts for it to be usable as an importable library, there's probably no need to install its modules into the global Python search path anyway. They could just go into a private module path on the filesystem instead as long as the placement service/entrypoint wrapper knows where to find them, right? -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [election] [tc] thank you
On 2018-09-04 22:11:41 -0400 (-0400), Emilien Macchi wrote: > After 2 years at the TC, I feel lucky enough to have been part of this > group where I hope that my modest contributions helped to make OpenStack a > bit better. [...] I think they have. I've always valued your input, and hope you continue providing it whether or not you're serving on the TC. Thanks, really! -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] non-candidacy for TC
On 2018-09-04 19:46:30 -0400 (-0400), Paul Belanger wrote: > After a year on the TC, I've decided not to run for another term. [...] Thank you for your service (past and future)! -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Run for a seat on the TC (I am, and you can too!)
I'm standing for reelection to a third term on the OpenStack Technical Committee. Rather than the usual platform where I drone on and on about myself, I'm going to take this opportunity to run a public service announcement instead. Going into my second term I stated, "my personal vision for OpenStack is that of a vibrant and diverse community" and I think we've made progress on that front but still have a long way to go. The diversity (personal, professional and cultural) of our community has increased steadily, but we won't be able to sustain it if similar diversity among elected leaders continues to lag behind. Our leaders are frequently the faces of our community to those outside it, and should set an example for others to follow. OpenStack is built on a promise of representative leadership, and so we need people from under-represented segments of our community to stand and take up the challenge. There's just over 48 hours left to send in your self-nomination for a seat on the TC. If you can't meet the time commitments but know someone who can, encourage them to run. And, of course, when the time comes, vote. Vote for the candidates who best represent you, your beliefs, your ideals. Vote for those who share your vision for who, how and what OpenStack should be. If you've been paying attention these past years, you already know my opinions. I'd rather hear some new opinions from you. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] better name for placement
On 2018-09-04 11:44:41 -0400 (-0400), Doug Hellmann wrote: > Excerpts from Chris Dent's message of 2018-09-04 15:32:12 +0100: [...] > > I would hope we'd be able to do that, and probably should do that. > > 'openstack-placement' seems a find pypi package name for a think > > from which you do 'import placement' to do some openstack stuff, > > yeah? > > That's still a pretty generic name for the top-level import, but I think > the only real risk is that the placement service couldn't be installed > at the same time as another package owned by someone else that used that > top-level name. I'm not sure how much of a risk that really is. [...] Well, it goes further than just the local system. For example, if there was another project unrelated to OpenStack which also had a module named "placement" in the default import path, then Debian wouldn't be able to carry packages for both projects without modifying. At least one would need the module renamed or would need to put it in a private path and then any consumers would need to be adjusted to suit. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] better name for placement (was:Nominating Chris Dent for placement-core)
On 2018-09-04 09:32:20 +0100 (+0100), Chris Dent wrote: [...] > it allowed for the possibility that there could be another project > which provided the same service-type. That hasn't really come to > pass [...] It still might make sense to attempt to look at this issue from outside the limited scope of the OpenStack community. Is the expectation that the project when packaged (on PyPI, in Linux distributions and so on) will just be referred to as "placement" with no further context? -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Bringing the community together (combine the lists!)
On 2018-08-31 14:02:23 +0200 (+0200), Thomas Goirand wrote: [...] > I'm coming from the time when OpenStack had a list on launchpad > where everything was mixed. We did the split because it was really > annoying to have everything mixed. [...] These days (just running stats for this calendar year) we've been averaging 4 messages a day on the general openstack@lists.o.o ML, so if it's volume you're worried about most of it would be the current -operators and -dev ML discussions anyway (many of which are general questions from users already, because as you also pointed out we don't usually tell them to take their questions elsewhere any more). -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Mailman topic filtering (was: Bringing the community together...)
On 2018-08-31 09:35:55 +0100 (+0100), Stephen Finucane wrote: [...] > I've tinked with mailman 3 before so I could probably take a shot at > this over the next few week(end)s; however, I've no idea how this > feature is supposed to work. Any chance an admin of the current list > could send me a couple of screenshots of the feature in mailman 2 along > with a brief description of the feature? Alternatively, maybe we could > upload them to the wiki page Tony linked above or, better yet, to the > technical details page for same: > > https://wiki.mailman.psf.io/DEV/Brief%20Technical%20Details Looks like this should be https://wiki.list.org/DEV/Brief%20Technical%20Details instead, however reading through it doesn't really sound like the topic filtering feature from MM2. The List Member Manual has a very brief description of the feature from the subscriber standpoint: http://www.list.org/mailman-member/node29.html The List Administration Manual unfortunately doesn't have any content for the feature, just a stubbed-out section heading: http://www.list.org/mailman-admin/node30.html Sending screenshots to the ML is a bit tough, but luckily MIT's listadmins have posted some so we don't need to: http://web.mit.edu/lists/mailman/topics.html -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [all] Bringing the community together (combine the lists!)
On 2018-08-30 18:08:56 -0500 (-0500), Melvin Hillsman wrote: [...] > I also recall us discussing having some documentation or way of > notifying net new signups of how to interact with the ML > successfully. An example was having some general guidelines around > tagging. Also as a maintainer for at least one of the mailing > lists over the past 6+ months I have to inquire about how that > will happen going forward which again could be part of this > documentation/initial message. [...] Mailman supports customizable welcome messages for new subscribers, so the *technical* implementation there is easy. I do think (and failed to highlight it explicitly earlier I'm afraid) that this proposal comes with an expectation that we provide recommended guidelines for mailing list use/etiquette appropriate to our community. It could be contained entirely within the welcome message, or merely linked to a published document (and whether that's best suited for the Infra Manual or New Contributor Guide or somewhere else entirely is certainly up for debate), or even potentially both. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [all] Bringing the community together (combine the lists!)
On 2018-08-30 22:49:26 +0200 (+0200), Thomas Goirand wrote: [...] > I really don't want this. I'm happy with things being sorted in > multiple lists, even though I'm subscribed to multiples. I understand where you're coming from, and I used to feel similarly. I was accustomed to communities where developers had one mailing list, users had another, and whenever a user asked a question on the developer mailing list they were told to go away and bother the user mailing list instead (not even a good, old-fashioned "RTFM" for their trouble). You're probably intimately familiar with at least one of these communities. ;) As the years went by, it's become apparent to me that this is actually an antisocial behavior pattern, and actively harmful to the user base. I believe OpenStack actually wants users to see the development work which is underway, come to understand it, and become part of that process. Requiring them to have their conversations elsewhere sends the opposite message. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Bringing the community together (combine the lists!)
On 2018-08-30 12:57:31 -0600 (-0600), Chris Friesen wrote: [...] > Do we want to merge usage and development onto one list? That > could be a busy list for someone who's just asking a simple usage > question. A counterargument though... projecting the number of unique posts to all four lists combined for this year (both based on trending for the past several years and also simply scaling the count of messages this year so far based on how many days are left) comes out roughly equal to the number of posts which were made to the general openstack mailing list in 2012. > Alternately, if we are going to merge everything then why not just > use the "openstack" mailing list since it already exists and there > are references to it on the web. This was an option we discussed in the "One Community" forum session as well. There seemed to be a slight preference for making a new -disscuss list and retiring the old general one. I see either as an potential solution here. > (Or do you want to force people to move to something new to make them > recognize that something has changed?) That was one of the arguments made. Also I believe we have a *lot* of "black hole" subscribers who aren't actually following that list but whose addresses aren't bouncing new posts we send them for any of a number of possible reasons. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-sigs] [all] Bringing the community together (combine the lists!)
On 2018-08-31 01:13:58 +0800 (+0800), Rico Lin wrote: [...] > What needs to be done for this is full topic categories support > under `options` page so people get to filter emails properly. [...] Unfortunately, topic filtering is one of the MM2 features the Mailman community decided nobody used (or at least not enough to warrant preserving it in MM3). I do think we need to be consistent about tagging subjects to make client-side filtering more effective for people who want that, but if we _do_ want to be able to upgrade we shouldn't continue to rely on server-side filtering support in Mailman unless we can somehow work with them to help in reimplementing it. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Bringing the community together (combine the lists!)
The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists on lists.openstack.org see an increasing amount of cross-posting and thread fragmentation as conversants attempt to reach various corners of our community with topics of interest to one or more (and sometimes all) of those overlapping groups of subscribers. For some time we've been discussing and trying ways to bring our developers, distributors, operators and end users together into a less isolated, more cohesive community. An option which keeps coming up is to combine these different but overlapping mailing lists into one single discussion list. As we covered[1] in Vancouver at the last Forum there are a lot of potential up-sides: 1. People with questions are no longer asking them in a different place than many of the people who have the answers to those questions (the "not for usage questions" in the openstack-dev ML title only serves to drive the wedge between developers and users deeper). 2. The openstack-sigs mailing list hasn't seem much uptake (an order of magnitude fewer subscribers and posts) compared to the other three lists, yet it was intended to bridge the communication gap between them; combining those lists would have been a better solution to the problem than adding yet another turned out to be. 3. At least one out of every ten messages to any of these lists is cross-posted to one or more of the others, because we have topics that span across these divided groups yet nobody is quite sure which one is the best venue for them; combining would eliminate the fragmented/duplicative/divergent discussion which results from participants following up on the different subsets of lists to which they're subscribed, 4. Half of the people who are actively posting to at least one of the four lists subscribe to two or more, and a quarter to three if not all four; they would no longer be receiving multiple copies of the various cross-posts if these lists were combined. The proposal is simple: create a new openstack-discuss mailing list to cover all the above sorts of discussion and stop using the other four. As the OpenStack ecosystem continues to mature and its software and services stabilize, the nature of our discourse is changing (becoming increasingly focused with fewer heated debates, distilling to a more manageable volume), so this option is looking much more attractive than in the past. That's not to say it's quiet (we're looking at roughly 40 messages a day across them on average, after deduplicating the cross-posts), but we've grown accustomed to tagging the subjects of these messages to make it easier for other participants to quickly filter topics which are relevant to them and so would want a good set of guidelines on how to do so for the combined list (a suggested set is already being brainstormed[2]). None of this is set in stone of course, and I expect a lot of continued discussion across these lists (oh, the irony) while we try to settle on a plan, so definitely please follow up with your questions, concerns, ideas, et cetera. As an aside, some of you have probably also seen me talking about experiments I've been doing with Mailman 3... I'm hoping new features in its Hyperkitty and Postorius WebUIs make some of this easier or more accessible to casual participants (particularly in light of the combined list scenario), but none of the plan above hinges on MM3 and should be entirely doable with the MM2 version we're currently using. Also, in case you were wondering, no the irony of cross-posting this message to four mailing lists is not lost on me. ;) [1] https://etherpad.openstack.org/p/YVR-ops-devs-one-community [2] https://etherpad.openstack.org/p/common-openstack-ml-topics -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc][openstack-helm] On the problem of OSF copyright headers
On 2018-08-28 10:11:18 -0700 (-0700), John Dickinson wrote: [...] > It would be *really* helpful to have a simple rule or pattern for > each file's header. Something like "Copyright (c) created>-present by contributors to this project". I applaud and share your desire for a clear rule on such things. Sadly, I have serious doubts it's possible to get one. > As you mentioned, this issue comes up about every two years, and having > contributors police (via code review) the appropriate headers for every > commit is not a sustainable pattern. The only thing I'm sure about is that > the existing copyright headers are not correct, but I have no idea what the > correct header are. The point was not really for reviewers (who can't necessarily know whether or not a copyright claim is in any way legitimate), but rather for authors (please don't assign copyright of your works to the OSF). -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][tc][openstack-helm] On the problem of OSF copyright headers
[Obligatory disclaimer: I am not a lawyer, this is not legal advice, and I am not representing the OpenStack Foundation in any legal capacity here.] TL;DR: You should not be putting "Copyright OpenStack Foundation" on content in Git repositories, or anywhere else for that matter (unless you know that you are actually an employee of the OSF or otherwise performing work-for-hire activities at the behest of the OSF). The OpenStack Individual Contributor License Agreement (ICLA) does not require copyright assignment. The foundation does not want, nor does it even generally accept, copyright assignment from developers. Your copyrightable contributions are your own, or by proxy are the copyright of your employer if you have created them as a part of any work-for-hire arrangement (unless you've negotiated with your employer to retain copyright of your work). This topic has been raised multiple times in the past. In the wake of a somewhat protracted thread on the legal-disc...@lists.openstack.org mailing list (it actually started out on the openstack-dev mailing list but was then redirected to a more appropriate venue) back in April, 2013, we attempted to record a summary in the wiki article we'd been maintaining regarding various frequently-asked legal questions: https://wiki.openstack.org/wiki/LegalIssuesFAQ#OpenStack_Foundation_Copyright_Headers In the intervening years, we've worked to make sure other important documentation moves out of the wiki and into more durable maintenance (mostly Git repositories under code review, rendered and published to a Web site). I propose that as this particular topic is germane to contributing to the development of OpenStack software, the OpenStack Technical Committee should publish a statement on the governance site similar in nature to or perhaps as an expansion of the https://governance.openstack.org/tc/reference/licensing.html page where we detail copyright licensing expectations for official OpenStack project team deliverables. As I look back through that wiki article, I see a few other sections which may also be appropriate to cover on the governance site. The reason I'm re-raising this age-old discussion is because change https://review.openstack.org/596619 came to my attention a few minutes ago, in which some 400+ files within the openstack/openstack-helm repository were updated to assign copyright to "OpenStack Foundation" based on this discussion from an openstack-helm IRC meeting back in March (which seems to have involved no legal representative of the OSF): http://eavesdrop.openstack.org/meetings/openstack_helm/2018/openstack_helm.2018-03-20-15.00.log.html#l-101 There are also a couple of similar changes under the same review topic for the openstack/openstack-helm-infra and openstack/openstack-helm-addons repositories, one of which I managed to -1 before it could be approved and merged. I don't recall any follow-up discussion on the legal-disc...@lists.openstack.org or even openstack-dev@lists.openstack.org mailing lists, which I would have expected for any change of this legal significance. The point of this message is of course not to berate anyone, but to raise the example which seems to indicate that as a community we've apparently not done a great job of communicating the legal aspects of contributing to OpenStack. If there are no objections, I'll push up a proposed addition to the openstack/governance repository addressing this semi-frequent misconception and follow up with a link to the review. I'm also going to post to the legal-discuss ML so as to make the subscribers there aware of this thread. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] UUID sentinel needs a home
On 2018-08-24 18:51:08 -0500 (-0500), Matt Riedemann wrote: [...] > So just follow me here people, what if we had this common shared > library where code could incubate and then we could write some > tools to easily copy that common code into other projects... If we do this, can we at least put it in a consistent place in all projects? Maybe name the directory something like "openstack/common" just to make it obvious. > I'm pretty sure I could get said project approved as a top-level > program under The Foundation and might even get a talk or two out > of this idea. I can see the Intel money rolling in now... Seems like a sound idea. Can we call it "Nostalgia" for no particular reason? Though maybe "Recurring Nightmare" would be a more accurate choice. -- 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
Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?
On 2018-08-22 00:17:41 + (+), Fox, Kevin M wrote: > There have been plenty of cross project goals set forth from the > TC and implemented by the various projects such as wsgi or > python3. Those have been worked on by each of the projects in > priority to some project specific goals by devs interested in > bettering OpenStack. Why is it so hard to believe if the TC gave > out a request for a grander user/ops supporting feature, that the > community wouldn't step up? PTL's are supposed to be neutral to > vendor specific issues and work for the betterment of the Project. Those goals, cross-project by nature, necessarily involve people with domain-specific knowledge in the requisite projects. That is a lot different than expecting Cinder developers to switch gears and start working on Barbican instead just because the TC (or the UC, or the OSF BoD, or whoever) decrees key management is prioritized over multi-attach storage. Cross-project goal setting is already a strained process, in which we as a community spend a _lot_ of time and effort to determine what various project teams are even willing to work on and prioritize alongside the things they already get done. Asking them to work on something has absolutely not stopped them from wanting to work on other things instead. There are plenty of instances where the community (via its elected leadership) has attempted to set goals and some teams have chosen to work on other priorities of their own instead. If they could have directed all their contributors to focus on that it would have been completed, but they (all teams really) attempt balance the priorities set by the OpenStack Technical Committee and other leadership with their own project-specific priorities. Just as the TC sinks a lot of effort into getting teams to focus on things it identifies as priorities, the PTLs encounter similar challenges getting their teams to focus on whatever priorities they've set as a group. Some contributors only work on what interests them, some only on what their employer tells them, and so on, while much of the rest struggle simply to keep up with the overall rate of change. > I don't buy the complexity argument either. Other non OpenStack > projects are implementing similar functionality with far less > complexity. I attribute a lot of that to difference in governence. > Through governence we've made hard things much harder. They can't > be fixed until the governence issues are fixed first I think. [...] Again, specifics would be nice. What decisions has the community made in governing itself which have contributed to the problems you see? What incremental changes would you make to improve that situation (hint: blow-it-all-up suggestions like "get rid of PTLs" aren't solutions when you're steering a community consisting of thousands of developers, we need steps to get from point A to point B)? In this _particular_ situation, what action are you asking the TC or other community leaders to take to resolve the problem (and what do you see as "the problem" in this case, for that matter)? -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?
On 2018-08-22 11:03:43 -0700 (-0700), melanie witt wrote: [...] > I think it's about context. If two separate projects do their own priority > and goal setting, separately, I think they will naturally be more different > than they would be if they were one project. Currently, we agree on goals > and priorities together, in the compute context. If placement has its own > separate context, the priority setting and goal planning will be done in the > context of placement. In two separate groups, someone who is a member of > both the Nova and Placement teams would have to persuade Placement-only > members to agree to prioritize a particular item. This may sound subtle, but > it's a notable difference in how things work when it's one team vs two > separate teams. I think having shared context and alignment, at this point > in time, when we have outstanding closely coupled nova/placement work to do, > is critical in delivering for operators and users who are depending on us. [...] I'm clearly missing some critical detail about the relationships in the Nova team. Don't the Nova+Placement contributors already have to convince the Placement-only contributors what to prioritize working on? Or are you saying that if they disagree that's fine because the Nova+Placement contributors will get along just fine without the Placement-only contributors helping them get it done? -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?
On 2018-08-21 22:42:45 + (+), Fox, Kevin M wrote: [...] > Yes, I realize shared storage was Cinders priority and Nova's now > way behind in implementing it. so it is kind of a priority to get > it done. Just using it as an example though in the bigger context. > > Having operators approach individual projects stating their needs, > and then having the individual projects fight it out for > priorities isn't a good plan. The priorities should be prioritized > at a higher level then projects so the operators/users needs can > be seen in a global light, not just filtered though each projects > views of things. > > Yes, some folks volunteer to work on the things that they want to > work on. Thats great. But some folks volunteer to work on > priorities to help users/operators in general. Getting clear, > unbiased priorities for them is really important. [...] I remain unconvinced that if someone (the TC, the OSF board, the now defunct product management nee hidden influencers working group) declared for example that secrets management was a higher priority than shared storage, that any significant number of people who could work on the latter would work on the former instead. The TC has enough trouble getting developers in different projects to cooperate on more than a couple of prioritized cross-project goals per cycle. The OSF board has repeatedly shown its members are rarely in the positions within member companies that they have any influence over what upstream features/projects those companies work on. The product management working group thought they had that influence over the companies in which they worked, but were similarly unable to find developers who could make progress toward their identified goals. OpenStack is an extremely complex (arguably too complex) combination of software, for which there are necessarily people with very strong understanding of very specific pieces and at best a loose understanding of the whole. In contrast, there are few people who have both the background and interest (much less leeway from their employers in the case of paid contributors) to work on any random feature of any random project and be quickly effective at it. If you're familiar with, say, Linux kernel development, you see very much the same sort of specialization with developers who are familiar with specific kernel subsystems and vanishingly few who can efficiently (that is to say without investing lots of time to come up to speed) implement novel features in multiple unrelated subsystems. We'll all continue to work on get better at this, but hard things are... well... hard. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?
On 2018-08-21 17:18:40 + (+), Fox, Kevin M wrote: [...] > I'm really sure at this point that you can't have a project as > large as OpenStack without leadership setting a course and > sometimes making hard choices for the betterment of the whole. > That doesn't mean a benevolent dictator. But our self govened > model with elected officials should be a good balance. If they are > too unreasonable, they don't get reelected. But not leading isn't > an option either anymore. [...] Divining a consensual direction in which to steer the community is not the same thing as telling people what to do, but is still very much leadership. But I'd rather stop dancing in generalities and just talk about concrete examples instead. In this case, separation of governance between Nova and (as of yet unnamed) placement teams. If the Nova team is against wholly handing over control of the placement service to the current placement contributors, then having the OpenStack Technical Committee tell them to get over it isn't the way to foster productive future relationships between those two groups of people. The placement team is already entirely empowered, should they wish, to fork the placement service out of the nova repository and then apply to the TC to have that recognized as a separate team but doing so in no way guarantees the Nova team will work with them to use that version of placement and deprecate the one on which they currently rely. For that, there needs to be a positive working relationship, one we can't simply demand into being, so it's in their best interests to work things out amicably and directly instead of asking someone else (the TC) to decide this for them. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?
On 2018-08-21 16:38:41 + (+), Fox, Kevin M wrote: [...] > You need someone like the TC to be able to step in, in those cases > to help sort that kind of issue out. In the past, the TC was not > willing to do so. My gut feeling though is that is finally > changing. [...] To be clear, it's not that TC members are unwilling to step into these discussions. Rather, it's that most times when a governing body has to tell volunteers to do something they don't want to do, it tends to not be particularly helpful in solving the underlying disagreement. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?
On 2018-08-20 14:25:06 -0400 (-0400), Zane Bitter wrote: > On 20/08/18 14:02, Chris Friesen wrote: > > In order to address the "velocity of change in placement" > > issues, how about making the main placement folks members of > > nova-core with the understanding that those powers would only be > > used in the new placement repo? > > That kind of 'understanding' is only needed (because of > limitations in Gerrit) when working in the same repo. Once it's in > a separate repo you just create a new 'placement-core' group and > make nova-core a member of it. More correctly, the effort you'd go through to correctly characterize subsets of a repository under control of different groups of people is within the same order of magnitude as just putting them in separate Git repositories (especially when you take in to consideration the knock-on effects of duplicating things like review dashboards for the various prolog rules defined for those different subsets of the repository). If you're going to attempt to delegate review on portions of a Git repository, in most cases you may as well go ahead and make it a separate repository anyway. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [requirements][release][docs] FFE for openstackdocstheme 1.21.2
On 2018-08-17 06:56:11 +1000 (+1000), Tony Breeds wrote: [...] > How terrible would it be to branch openstackdocstheme and backport > the fix without the pbr changes? It might also be possible, > though I'm not sure how we'd land it, to branch (stable/ocata) > openstackdocstheme today and just revert the pbr changes to set > the lower bound. [...] I think it would also be entirely reasonable to just not worry about it, and let the people who asked for extended maintenance on older branches do the legwork. We previously limited the number we'd keep open because keeping those older branches updatable does in fact require quite a bit of effort. When we agreed to the suggestion of not closing branches, it was with the understanding that they won't just suddenly get taken care of by the same people who were already not doing that because they considered it a lot of extra work. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Personal tool patterns in .gitignore cookiecutter
In response to some recent but misguided proposals from well-meaning contributors in various projects, I've submitted a change[*] for the openstack-dev/cookiecutter .gitignore template inserting a comment which recommends against including patterns related to personal choices of tooling (arbitrary editors, IDEs, operating systems...). It includes one suggestion for a popular alternative (creating a personal excludesfile specific to the tools you use), but there are of course multiple ways it can be solved. This is not an attempt to set policy, but merely provides a recommended default for new repositories in hopes that projects can over time reduce some of the noise related to unwanted .gitignore additions. If it merges, projects who disagree with this default can of course modify or remove the comment at the top of the file as they see fit when bootstrapping content for a new repository. Projects with existing repositories on which they'd like to apply this can also easily copy the comment text or port the patch. If there seems to be some consensus that this change is appreciated, I'll remove the WIP flag and propose similar changes to our other cookiecutters for consistency. [*] https://review.openstack.org/592520 -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...
On 2018-08-13 16:29:27 -0500 (-0500), Amy Marrich wrote: > I know we did a ping last week in #openstack-ansible for our meeting no > issue. I wonder if it's a length of names thing or a channel setting. [...] Freenode's Sigyn bot may not have been invited to #openstack-ansible. We might want to consider kicking it from channels while they have nick registration enforced. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][searchlight][designate][telemetry][mistral][blazar][watcher][masakari]Possible deprecation of Nova's legacy notification interface
On 2018-08-09 11:41:38 +0200 (+0200), Balázs Gibizer wrote: [...] > There is a list of projects (we know of) consuming the legacy > interface and we would like to know if any of these projects plan > to switch over to the new interface in the foreseeable future so > we can make a well informed decision about the deprecation. > > > * Searchlight [3] - it is in maintenance mode so I guess the answer is no [...] With https://review.openstack.org/588644 looking likely to merge and Searchlight already not slated for inclusion in Rocky, I recommend not basing your decision on what it is or isn't using at this point. If someone wants to resurrect it, updating things like the use of the Nova notification interface seem like the bare minimum amount of work they should commit to doing anyway. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cyborg]Team Weekly Meeting 2018.08.08
On 2018-08-08 16:45:22 +0800 (+0800), Zhipeng Huang wrote: > We are rushing towards the end of Rocky cycle and let's use the meeting to > sync up with any important features still on the fly. > > starting UTC1400 at #openstack-cyborg, as usual Please consider adding your meeting to the IRC meetings schedule at http://eavesdrop.openstack.org/ (the first sentence in the section contains instructions for doing so), that way people in the community can find out when it is held without having to rely solely on announcements. Thanks! -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Stepping down as coordinator for the Outreachy internships
On 2018-08-07 20:47:28 (-0300), Victoria Martínez de la Cruz wrote: > I'm reaching you out to let you know that I'll be stepping down as > coordinator for OpenStack next round. [...] You've done a great job, and mentoring a new coordinator is just another great example of that; thanks for all you've done and all you have yet to do, it's important! -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] PTG Denver Horns
On 2018-08-08 06:51:27 -0500 (-0500), David Medberry wrote: > So basically, we have added "sl" to osc. Duly noted. > > (FWIW, I frequently use "sl" as a demo of how "live" a VM is during live > migration. The train "stutters" a bit during the cutover.) > > Now I can base it on PTG design work in a backronym fashion. [...] Speaking of which, is it too soon to put in bids to name the Denver summit and associated release in 2019 "OpenStack Train"? I feel like we're all honorary railroad engineers by now. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra][horizon][osc] ClientImpact tag automation
On 2018-08-02 14:16:10 -0500 (-0500), Sean McGinnis wrote: [...] > Interesting... I hadn't looked into Gerrit functionality enough to know about > these. Looks like this is probably what you are referring to? > > https://gerrit.googlesource.com/plugins/its-storyboard/ Yes, that. Khai Do (zaro) did the bulk of the work implementing it for us but isn't around as much these days (we miss you!). > It's been awhile since I did anything significant with Java, but that might be > an option. Maybe a fun weekend project at least to see what it would take to > create an its-launchpad plugin. [...] Careful; if you let anyone know you've touched a Gerrit plug-in the requests for more help will never end. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] How to debug no valid host failures with placement
On 2018-08-02 14:04:10 -0600 (-0600), Chris Friesen wrote: [...] > At a previous Summit[1] there were some operators that said they just always > ran nova-scheduler with debug logging enabled in order to deal with this > issue, but that it was a pain to isolate the useful logs from the not-useful > ones. [...] Also, the OpenStack VMT doesn't prioritize information leaks which are limited to debug-level logging[*], so leaving debug logging enabled is perhaps more risky if you don't safeguard those logs. [*] https://security.openstack.org/vmt-process.html#incident-report-taxonomy -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra][horizon][osc] ClientImpact tag automation
On 2018-08-02 10:09:48 -0500 (-0500), Sean McGinnis wrote: [...] > I was able to find part of how that is implemented in jeepyb: > > http://git.openstack.org/cgit/openstack-infra/jeepyb/tree/jeepyb/cmd/notify_impact.py [...] As for the nuts and bolts here, the script you found is executed from a Gerrit hook every time a change merges: https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/files/gerrit/change-merged Gerrit hooks are a bit fragile but also terribly opaque (the only way to troubleshoot a failure is a Gerrit admin pouring over a noisy log file on the server looking for a Java backtrace). If you decide to do something automated to open bugs/stories when changes merge, I recommend a Zuul job. We don't currently have a pipeline definition which generates a distinct build set for every merged change (the post and promote pipelines do supercedent queuing rather than independent queuing these days) but it would be easy to add one that does. It _could_ also be a candidate for a Gerrit ITS plug-in (there's one for SB but not for LP as far as I know), but implementing this would mean spending more time in Java than most of us care to experience. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][election] PTL nominations are now closed
On 2018-08-02 10:58:53 +0200 (+0200), Thierry Carrez wrote: [...] > Finally, RefStack: I feel like this should be wrapped into an > Interoperability SIG, since that project team is not producing > "OpenStack", but helping fostering OpenStack interoperability. > Having separate groups (Interop WG, RefStack) sounds overkill > anyway, and with the introduction of SIGs we have been recentering > project teams on upstream code production. That was one of the possibilities I discussed with them during their meeting a month ago: http://eavesdrop.openstack.org/irclogs/%23refstack/%23refstack.2018-07-03.log.html#t2018-07-03T17:05:43 Election official hat off and TC Refstack liaison hat on, I think if Chris Hoge doesn't volunteer to act as PTL this cycle to oversee shutting down the team and reassigning its deliverables, then we need to help them fast-track that nowish and not appoint a Stein cycle PTL. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
