settingsLogin | Registersettings

[openstack-dev] [neutron] - are you attending the Sydney summit?

0 votes

Hi,

If you are a Neutron developer attending the Sydney Summit, please add your
name to the following etherpad so we can plan a team social event and
easily coordinate in person meetings:

https://etherpad.openstack.org/p/neutron-sydney-summit-attendees

Safe travels and see you Down Under!

Cheers

Miguel


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Oct 20, 2017 in openstack-dev by Miguel_Lavalle (2,460 points)   1 4

1 Response

0 votes

Thanks mlavalle, 

I have added my information to the etherpad and expect to discussing the topic about SR-IOV bond as following

https://review.openstack.org/#/c/506066/4

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

I am looking forward to see you ~~

张延显 zhangyanxian

软件高级系统工程师  Senior System Software Engineer
虚拟化南京一部/无线研究院/无线产品经营部 NIV Nanjing Dept. I/Wireless Product R&D Institute/Wireless Product Operation Division


江苏省南京市雨花台区紫荆花路68号中兴南京研发中心
R&D Building, ZTE Corporation Zijinghua Road No. 68,
Yuhuatai District, Nanjing City, Jiangsu Province,P.R.China, 210012
M: +86 18260022960
E: zhang.yanxian@zte.com.cn
www.zte.com.cn

原始邮件

发件人: openstack-dev-request@lists.openstack.org;

收件人: openstack-dev@lists.openstack.org;

日 期 :2017年10月21日 15:37

主 题 :OpenStack-dev Digest, Vol 66, Issue 36

Send OpenStack-dev mailing list submissions to
    openstack-dev@lists.openstack.org

To subscribe or unsubscribe via the World Wide Web, visit
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or, via email, send a message with subject or body 'help' to
    openstack-dev-request@lists.openstack.org

You can reach the person managing the list at
    openstack-dev-owner@lists.openstack.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenStack-dev digest..."

Today's Topics:

   1. Re: [puppet] avoid rechecks (Arnaud MORIN)
   2. [nova] [placement] resource providers update 39 (Chris Dent)
   3. Re: [keystone][all][tc] v2.0 API removal (Jeremy Stanley)
   4. [neutron] [stadium] Tempest plugin split goal for stadium
      projects (Bernard Cafarelli)
   5. [neutron][vpnaas] core reviewer proposal (Takashi Yamamoto)
   6. [neutron][networking-midonet] Core reviewers change    proposal
      (Takashi Yamamoto)
   7. Fwd: [Distutils][pbr] Announcement: Pip 10 is    coming, and
      will move all internal APIs (Doug Hellmann)
   8. [tc] Technical Committee Status update, October 20th
      (Thierry Carrez)
   9. Re: [policy] AWS IAM session (Lance Bragstad)
  10. Re: [puppet] avoid rechecks (Mohammed Naser)
  11. Do you hate the new gerrit thing where the cursor    jumps all
      over? (Matt Riedemann)
  12. Re: [OpenStack-docs] [docs] Documentation meeting    Thursday
      (Petr Kovar)
  13. [docs] Docs meeting time? (was: Documentation    meeting
      Thursday) (Petr Kovar)
  14. Re: [keystone][all][tc] v2.0 API removal (Yaguang Tang)
  15. [docs] Docs meeting time? (was: Documentation meeting
      Thursday) (Chan Chason)
  16. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0    API
      removal (Fox, Kevin M)
  17. Re: Do you hate the new gerrit thing where the cursor jumps
      all over? (Jeremy Freudberg)
  18. Re: Do you hate the new gerrit thing where the cursor jumps
      all over? (Clark Boylan)
  19. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API
      removal (Jeremy Stanley)
  20. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0    API
      removal (Jeremy Stanley)
  21. Re: Do you hate the new gerrit thing where the cursor jumps
      all over? (Jeremy Freudberg)
  22. Re: Fwd: [Distutils][pbr] Announcement: Pip 10 is coming, and
      will move all internal APIs (Clark Boylan)
  23. Re: Fwd: [Distutils][pbr] Announcement: Pip 10 is coming, and
      will move all internal APIs (Clark Boylan)
  24. [ironic] Support for single OpenStack system supporting VM
      and Baremetal Instances simultaneously ? (Waines, Greg)
  25. Re: [infra] Short gerrit / zuul outage 2017-10-20    20:00UTC
      (Ian Wienand)
  26. Re: Fwd: [Distutils][pbr] Announcement: Pip 10 is coming, and
      will move all internal APIs (Clark Boylan)
  27.  [neutron] - are you attending the Sydney summit? (Miguel Lavalle)
  28. Re: Fwd: [Distutils][pbr][devstack][qa]    Announcement: Pip 10
      is coming, and will move all internal APIs (Doug Hellmann)
  29. [qa] Proposing changes to 17UTC team meeting (Andrea Frittoli)
  30. [All][Elections] Vote Vote Vote in the TC election!
      (Kendall Nelson)
  31. Re: Fwd: [Distutils][pbr][devstack][qa] Announcement: Pip 10
      is coming, and will move all internal APIs (Sam Yaple)
  32. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0    API
      removal (Fox, Kevin M)
  33. Re: [TripleO][Kolla] Concerns about containers images in
      DockerHub (Steven Dake (stdake))
  34. Re: Do you hate the new gerrit thing where the cursor jumps
      all over? (Tim Burke)
  35. [all] [elections] Technical Committee Election    Results
      (Kendall Nelson)
  36. Re: [all] [elections] Technical Committee Election Results
      (Ildiko Vancsa)
  37. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API
      removal (Morgan Fainberg)
  38. Re: [all] [elections] Technical Committee Election Results
      (Tony Breeds)
  39. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API
      removal (Morgan Fainberg)
  40. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API
      removal (Fox, Kevin M)
  41. Re: Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API
      removal (Cody A.W. Somerville)
  42. Re: [TripleO][Kolla] Concerns about containers images in
      DockerHub (Michał Jastrzębski)
  43. Re: [tc][election] Question for candidates: How do you think
      we can make our community more inclusive? (Diana Clarke)
  44. OpenStack Bug Smash for Queens (Fred Li)


Message: 1
Date: Fri, 20 Oct 2017 14:18:29 +0200
From: Arnaud MORIN arnaud.morin@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [puppet] avoid rechecks
Message-ID:
    CALn_SgZU7r2=v+f44hykSySiuDYGHf55S_g-0W+e54t69wWOxA@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

Hi Mohammed and all,

Can we help with the puppet CI?

Cheers,
Arnaud.

On 1 October 2017 at 17:27, Mohammed Naser mnaser@vexxhost.com wrote:

 Hi everyone,

 As the Puppet modules CI is still in the process of getting plumbed
 properly with Zuul v3, you'll notice many of your checks failing.  If
 you notice a job that has a legacy- prefix, it is probably not
 migrated yet and will likely fail, therefore, I'd avoid a recheck to
 avoid taking up resources for a job that will fail.

 If none of your jobs are prefixed with legacy- then you can do the
 normal troubleshooting and recheck if it is a timeout of the job or a
 connectivity issue.

 I'll keep everyone updated at the progress of moving things over.

 Thanks,
 Mohammed

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 2
Date: Fri, 20 Oct 2017 13:32:45 +0100 (BST)
From: Chris Dent cdent+os@anticdent.org
To: OpenStack-dev@lists.openstack.org
Subject: [openstack-dev] [nova] [placement] resource providers update
    39
Message-ID: alpine.OSX.2.21.1710201332190.93119@cdent-m01.vmware.com
Content-Type: text/plain; charset="utf-8"; Format="flowed"

This is update 39 for resource providers and placement.

 Most Important

This week we had spec freeze, so now it is time to get rolling with
the making and the doing. Most of the specs that are related to
placement already had code in progress, so there's lots of stuff ready
to review. Given the volume of stuff in flight, the usual extras we'll
discover along the way, and the headspace we need to reserve for
thinking and experimenting about the future, we've got plenty going.

 What's Changed

Forward progress mostly. Engaging Neutron using placement, at the
intersection of Nova and Neutron, as represented by specs like

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

has been put off to later as it has too many dependencies on stuff
that is currently under development and not yet done.

The Granular Resource Request Syntax spec merged, which lays the
groundwork for nested resource providers and traits can work.

efried has created a functional test that exercises two bugs he
figured out with "alloc candidates with same RC in cn & shared"

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

This is interesting because it requires us to make some decisions
and clear statements about what is supposed to be happening, not just
fix a bug.

 Main Themes

 Nested Resource Providers

Progress is happening on nested providers:

     https://review.openstack.org/#/q/topic:bp/nested-resource-providers

It was injected into the middle of the de-orm stack, so while much of
that work has merged, there are some tail ends:

     https://review.openstack.org/#/q/topic:bp/de-orm-resource-providers

And the work to make traits work is relevant here, because with traits
nested aren't near as useful:

     https://review.openstack.org/#/q/bp/add-trait-support-in-allocation-candidates

 Migration allocations

The migration allocations work is nearly complete at:

     https://review.openstack.org/#/q/topic:bp/migration-allocations

Management of those allocations currently involves some raciness,
birthing the idea to allow POST /allocations, which causes a cascade
of required changes to bring that about. The code stack for that
starts at:

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

 Alternate Hosts

We want to be able to do retries within cells, so we need some
alternate hosts when returning a destination that are structured
nicely for RPC:

     https://review.openstack.org/#/q/topic:bp/return-alternate-hosts

 Other

https://review.openstack.org/#/c/513001/
   Only add CUSTOM_ prefix if required

https://review.openstack.org/#/c/508555/
   Re-use existing ComputeNode on ironic rebalance

https://review.openstack.org/#/c/512553/
   Reproduce bug 1724172 in the functional test env
   (this is an allocations related bug)

https://review.openstack.org/#/c/493865/
   cover migration cases with functional tests

https://review.openstack.org/#/c/513041/
   Extract instance allocation removal code

https://review.openstack.org/#/c/495159/
   Test resource allocation during soft delete

https://review.openstack.org/#/c/499539/
   Moving more utils to ServerResourceAllocationTestBase

https://review.openstack.org/#/c/503037/
   factor out compute service start in ServerMovingTest

https://review.openstack.org/#/c/505202/
   Change live_migrate tests to use fakedriver

https://review.openstack.org/#/c/497399/
   Extend ServerMovingTests with custom resources

https://review.openstack.org/#/q/topic:bug/1702420
    Fixes for shared providers map being incorrect

https://review.openstack.org/#/c/499826/
    Include /resource_providers/uuid/allocations link
    (Matt has declared this needs a microversion)

https://review.openstack.org/#/c/492247/
    Use ksa adapter for placement conf & requests

https://review.openstack.org/#/q/topic:bp/placement-osc-plugin
    Placement plugin for osc

https://review.openstack.org/#/c/492571/
    Make compute log less verbose with allocs autocorrection

https://review.openstack.org/#/c/499539/
    Stack of functional test fixups

https://review.openstack.org/#/c/495380/
    [placement] manage cache headers for /resource_providers

https://review.openstack.org/#/c/511488/
    [placement] Confirm that empty resources query causes 400

https://review.openstack.org/#/c/511485/
    [placement] add coverage for update of standard resource class

https://review.openstack.org/#/q/topic:bp/allocation-candidates-limit
   Enable limiting GET /allocation_candidates

https://review.openstack.org/#/c/513057/
   [placement] Clean up TODOs in allocations.yaml gabbit

https://review.openstack.org/#/q/topic:bug/1578989
   move placement client in neutron to neutron-lib and add
   functionality

https://review.openstack.org/#/c/494206/
   Remove the Pike migration code for [Ironic] flavor migration

https://review.openstack.org/#/c/511342/
   placement: add API reference for create inventory

 End

You only get a prize if you review all the things linked here. If you
do then your prize is a massive sense of accomplishment and
contribution.

-- 
Chris Dent                      (⊙_⊙')         https://anticdent.org/
freenode: cdent                                         tw: @anticdent


Message: 3
Date: Fri, 20 Oct 2017 12:46:27 +0000
From: Jeremy Stanley fungi@yuggoth.org
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone][all][tc] v2.0 API removal
Message-ID: 20171020124626.GB28203@yuggoth.org
Content-Type: text/plain; charset="utf-8"

On 2017-10-20 10:52:36 +0800 (+0800), Yaguang Tang wrote:
 Keystone is one project that all other OpenStack projects use, so
 personally I think the change to remove the API which are widely
 used should be discussed at TC meeting .
[...]

The OpenStack Technical Committee ceased holding regular weekly
meetings around 6 months ago:

https://governance.openstack.org/tc/resolutions/20170425-drop-tc-weekly-meetings.html

Also, the TC is not generally in the business of making decisions on
behalf of projects and instead provides opt-in policy in the form of
"tags" which projects can choose to apply to their teams or
deliverables, such as:

https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html

As you can see, the Keystone team asserts the keystone API service
follows the deprecation model indicated there. Are you suggesting
that policy was not followed, or that it's merely insufficient?
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: 


Message: 4
Date: Fri, 20 Oct 2017 15:08:33 +0200
From: Bernard Cafarelli bcafarel@redhat.com
To: OpenStack Development Mailing List
    openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] [stadium] Tempest plugin split goal
    for stadium projects
Message-ID:
    CABHdKwqBUKosWp97r9zFMNqgCdcjMd5TP9UTda_o=L39S3tzzg@mail.gmail.com
Content-Type: text/plain; charset="UTF-8"

Hi neutrinos,

to follow up on the community goal efffort to split tempest plugins in
separate repos 1, I started the work for networking-sfc [2], aiming
for a new "networking-sfc-tempest-plugin" repository.

Armando had an interesting question that I am bringing to the wider
audience: for stadium projects, should we create one tempest repo per
project, or host all stadium tempest related tests in a single neutron
repo [3]?

In similar cases, we already currently have "common code" repos:
neutron-lib for API, and python-neutronclient for OSC code.

So what do you think?

1 http://lists.openstack.org/pipermail/openstack-dev/2017-October/123268.html
[2] https://review.openstack.org/#/c/510553/
[3] https://git.openstack.org/cgit/openstack/neutron-tempest-plugin

-- 
Bernard Cafarelli


Message: 5
Date: Fri, 20 Oct 2017 22:10:00 +0900
From: Takashi Yamamoto yamamoto@midokura.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][vpnaas] core reviewer proposal
Message-ID:
    CAH=wFzRt7=29ttr9tgi_pLe0L5AZwD+xaGLpeSxL7svRkaYDbQ@mail.gmail.com
Content-Type: text/plain; charset="UTF-8"

Hi,

Unless anyone objects, i'll add the following people to neutron-vpnaas
core reviewers. 1

- Cao Xuan Hoang hoangcx@vn.fujitsu.com
- Akihiro Motoki amotoki@gmail.com
- Miguel Lavalle miguel@mlavalle.com

Hoang is the most active contributor for the project these days.

I don't bother to introduce Akihiro and Miguel as i guess everyone here
knows them. :-)

1 https://review.openstack.org/#/admin/groups/502,members


Message: 6
Date: Fri, 20 Oct 2017 22:10:51 +0900
From: Takashi Yamamoto yamamoto@midokura.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][networking-midonet] Core reviewers
    change    proposal
Message-ID:
    CAH=wFzSOc_ijk5xQUyMHEHn0=KotY2WOBaJ-dnHCw3eRKo8D1A@mail.gmail.com
Content-Type: text/plain; charset="UTF-8"

Hi,

Unless anyone objects, I'll remove the following people from the list
of networking-midonet core reviewers.

- Joe Mills
- Michael Micucci

They made great contributions in the past (thank you!) but have not
reviewed any patches in the last 6 months. [2]

1 https://review.openstack.org/#/admin/groups/607,members
[2] http://stackalytics.com/report/contribution/networking-midonet/180


Message: 7
Date: Fri, 20 Oct 2017 10:23:51 -0400
From: Doug Hellmann doug@doughellmann.com
To: openstack-dev openstack-dev@lists.openstack.org
Subject: [openstack-dev] Fwd: [Distutils][pbr] Announcement: Pip 10 is
    coming, and will move all internal APIs
Message-ID: 1508509327-sup-2738@lrrr.local
Content-Type: text/plain; charset=UTF-8

It sounds like the PyPI/PyPA folks are planning some major changes to
pip internals, soon.

I know pbr uses setuptools, and I don't think it uses pip, but if
someone has time to verify that it would be helpful.

We'll also want to watch out for breakage in normal use of pip 10. If
they're making changes this big, they may miss something in their own
test coverage that affects our jobs.

--- Begin forwarded message from Paul Moore ---
From: Paul Moore p.f.moore@gmail.com
To: Distutils distutils-sig@python.org, pypa-dev pypa-dev@googlegroups.com
Date: Fri, 20 Oct 2017 14:22:03 +0100
Subject: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

We're in the process of starting to plan for a release of pip (the
long-awaited pip 10). We're likely still a month or two away from a
release, but now is the time for people to start ensuring that
everything works for them. One key change in the new version will be
that all of the internal APIs of pip will no longer be available, so
any code that currently calls functions in the "pip" namespace will
break. Calling pip's internal APIs has never been supported, and
always carried a risk of such breakage, so projects doing so should,
in theory, be prepared for such things. However, reality is not always
that simple, and we are aware that people will need time to deal with
the implications.

Just in case it's not clear, simply finding where the internal APIs
have moved to and calling them under the new names is not what
people should do. We can't stop people calling the internal APIs,
obviously, but the idea of this change is to give people the incentive
to find a supported approach, not just to annoy people who are doing
things we don't want them to ;-)

So please - if you're calling pip's internals in your code, take the
opportunity now to check out the in-development version of pip, and
ensure your project will still work when pip 10 is released.

And many thanks to anyone else who helps by testing out the new
version, as well :-)

Thanks,
Paul
--- End forwarded message ---


Message: 8
Date: Fri, 20 Oct 2017 16:41:53 +0200
From: Thierry Carrez thierry@openstack.org
To: OpenStack Development Mailing List
    openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tc] Technical Committee Status update,
    October 20th
Message-ID: 555a45b2-8e75-8ef8-04c7-f7532796fc9b@openstack.org
Content-Type: text/plain; charset=utf-8

Hi!

This is the weekly summary of Technical Committee initiatives. You can
find the full list of all open topics (updated twice a week) at:

https://wiki.openstack.org/wiki/Technical_Committee_Tracker

If you are working on something (or plan to work on something) that is
not on the tracker, feel free to add to it !

== TC Election still in progress ==

A few hours left to vote!
Note that your ballot email might have been classified as spam.

== Recently-approved changes ==

* New project team: OpenStack-Helm (helm charts for OpenStack) 1
* Remove tox from PTI for python tarballs [2]
* Goal updates: kolla, ironic
* Retired repos: pylockfile
* New repos: contributor-guide, heat-dashboard, senlin-tempest-plugin

1 https://review.openstack.org/#/c/500118/
[2] https://review.openstack.org/#/c/508693/

The most significant change this week is the officialization of the
"OpenStack-Helm" project team, a packaging team working on producing
Helm charts to deploy OpenStack using helm. This likely closes the list
of OpenStack project teams for the Queens cycle. The Glare team
application, in particular, was deferred to Rocky by its PTL.

== Under review ==

Our latest top-5 "help wanted" list proposed addition, "champions
and stewards" is still pretty much under review:

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

Monty's series of modifications to the PTI (project testing
interface) still had two open changes. Please review at:

https://review.openstack.org/#/c/508694/
https://review.openstack.org/#/c/509868/

== TC member actions for the coming week(s) ==

Monty should answer the feedback on the supported database version
resolution (https://review.openstack.org/493932) so that we can make
progress there -- or abandon it.

== Office hours ==

To be more inclusive of all timezones and more mindful of people for
which English is not the primary language, the Technical Committee
dropped its dependency on weekly meetings. So that you can still get
hold of TC members on IRC, we instituted a series of office hours on

openstack-tc:

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

For the coming week, I expect the main topic of discussion to be the
onboarding of the newly-elected membership, as well as Summit preparations.

Cheers,

-- 
Thierry Carrez (ttx)


Message: 9
Date: Fri, 20 Oct 2017 09:46:12 -0500
From: Lance Bragstad lbragstad@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [policy] AWS IAM session
Message-ID: 64d8d01e-b544-3b8e-d30e-c110eb7a7866@gmail.com
Content-Type: text/plain; charset="utf-8"

I just sent a calendar invite to everyone who responded to this thread
or voted in the agenda. The session will be recorded if you are unable
to make it.

Thanks!

On 10/18/2017 10:10 AM, Lance Bragstad wrote:
 Now that we have some good feedback on the doodle, it looks like we
 have two sessions that will work for everyone. One is October 25th
 from 15:00 - 16:00 UTC and the other is also the 25th from 16:00 - 17:00.

 Let's shoot to meet at 15:00 UTC on October 25th and if the
 meeting goes over, we have time allocated for that. Would anyone like
 a formal calendar invite? If so, I can send one out. The etherpad [0]
 will act as our "schedule", but we'll likely just work through the
 cases we've documented.

 Thanks!

 [0] https://etherpad.openstack.org/p/analyzing-other-policy-systems

 On 10/16/2017 08:45 AM, Lance Bragstad wrote:

 Sending out a gentle reminder to vote for time slots that work for
 you [0]. We'll keep the poll open for a few more days, or until we
 reach quorum. Thanks!

 [0] https://beta.doodle.com/poll/ntkpzgmcv3k6v5qu

 On 10/11/2017 01:48 PM, Lance Bragstad wrote:

 Oh - one note about the doodle [0]. All proposed times are in UTC,
 so just keep that in mind when selecting your availability.

 Thanks!

 [0] https://beta.doodle.com/poll/ntkpzgmcv3k6v5qu

 On 10/11/2017 01:44 PM, Lance Bragstad wrote:

 In today's policy meeting we went through and started prepping for
 the session. Relevant information has been captured in the etherpad
 [0].

 We're going to hold the meeting using Google Hangouts. I'll
 update the etherpad with a link to the hangout once we settle on a
 date. If you plan on attending, please vote for available
 times 1. I've proposed a bunch of time slots (4 each day for
 the next two weeks) to try and find a time that works for everyone.
 People from US, AU, and EU will be trying to attended, so we're not
 going to find a perfect time for everyone. Having said that, we're
 going to record the session
.

 Most of what we talked about in the meeting today uncovered the
 need to go over the basics of AWS IAM. That should be something we
 can do with a free account, which I'm going to sign up for. If we
 need more time we can have another session or look at options for
 upgrading the account.

 [0] https://etherpad.openstack.org/p/analyzing-other-policy-systems
 1 https://doodle.com/poll/ntkpzgmcv3k6v5qu

 On 10/09/2017 04:23 PM, Lance Bragstad wrote:

 I've put a scheduling session on the books for the next policy
 meeting 0. Advertising it here since folks who want to be
 involved have responded to the thread.

 Let's use this meeting time to iron out account details and figure
 out what exactly we want to get out of the session.

 [0] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting
 1 https://etherpad.openstack.org/p/keystone-policy-meeting

 On 10/05/2017 02:24 AM, Colleen Murphy wrote:

 On Tue, Oct 3, 2017 at 10:08 PM, Lance Bragstad
 <lbragstad@gmail.com lbragstad@gmail.com> wrote:

     Hey all,

     It was mentioned in today's keystone meeting [0] that it
     would be useful
     to go through AWS IAM (or even GKE) as a group. With all the
     recent
     policy discussions and work, it seems useful to get our eyes
     on another
     system. The idea would be to spend time using a video
     conference/screen
     share to go through and play with policy together. The end
     result should
     keep us focused on the implementations we're working on
     today, but also
     provide clarity for the long-term vision of OpenStack's RBAC
     system.

     Are you interested in attending? If so, please respond to the
     thread.
     Once we have some interest, we can gauge when to hold the
     meeting, which
     tools we can use, and setting up a test IAM account.

     Thanks,

     Lance

     [0]
     http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-10-03-18.00.log.html#l-119
     

 Please count me in.

 Colleen

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: 


Message: 10
Date: Fri, 20 Oct 2017 11:27:24 -0400
From: Mohammed Naser mnaser@vexxhost.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [puppet] avoid rechecks
Message-ID:
    CAEs876gq2PRS+Xkc=x1MUK79g8XJTzE8CW3bWKQx2LGEop2zbw@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

Hi Arnaud,

Apologies for not following up with that email, things should be okay now
and we've mostly patched up our CI for Zuul v3 :)

Thanks,
Mohammed

On Fri, Oct 20, 2017 at 8:18 AM, Arnaud MORIN arnaud.morin@gmail.com
wrote:

 Hi Mohammed and all,

 Can we help with the puppet CI?

 Cheers,
 Arnaud.

 On 1 October 2017 at 17:27, Mohammed Naser mnaser@vexxhost.com wrote:

 Hi everyone,

 As the Puppet modules CI is still in the process of getting plumbed
 properly with Zuul v3, you'll notice many of your checks failing.  If
 you notice a job that has a legacy- prefix, it is probably not
 migrated yet and will likely fail, therefore, I'd avoid a recheck to
 avoid taking up resources for a job that will fail.

 If none of your jobs are prefixed with legacy- then you can do the
 normal troubleshooting and recheck if it is a timeout of the job or a
 connectivity issue.

 I'll keep everyone updated at the progress of moving things over.

 Thanks,
 Mohammed

 ____________________________________________________________
 ______________
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscrib
 e
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

-- 
Mohammed Naser — vexxhost


D. 514-316-8872
D. 800-910-1726 ext. 200
E. mnaser@vexxhost.com
W. http://vexxhost.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

Message: 11
Date: Fri, 20 Oct 2017 11:02:21 -0500
From: Matt Riedemann mriedemos@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: [openstack-dev] Do you hate the new gerrit thing where the
    cursor    jumps all over?
Message-ID: db23b0e9-68d4-cf00-e6b7-851af89c6269@gmail.com
Content-Type: text/plain; charset=utf-8; format=flowed

When you're lower in a change trying to expand comments and it always 
jumps you back up to the top?

Since not everyone might know about the solution, it's:

1. Go into settings
2. Diff Preference
3. Change "Render" from Fast to Slow.
4. Save

Get back to reviewing stuff without losing your mind.

-- 

Thanks,

Matt


Message: 12
Date: Fri, 20 Oct 2017 18:12:03 +0200
From: Petr Kovar pkovar@redhat.com
To: openstack-docs@lists.openstack.org,
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [OpenStack-docs] [docs] Documentation
    meeting    Thursday
Message-ID: 20171020181203.abe35f94e6e9f131eaf11a16@redhat.com
Content-Type: text/plain; charset=US-ASCII

Below are the meeting minutes from yesterday's docs team meeting.

Because we ran out of time (too many items to cover!), the conversation
about site map automation continued in #openstack-doc after the meeting:

http://eavesdrop.openstack.org/irclogs/%23openstack-doc/%23openstack-doc.2017-10-19.log.html

===========================

openstack-meeting: docteam

===========================

Meeting started by pkovar at 16:01:09 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/docteam/2017/docteam.2017-10-19-16.01.log.html
.

Meeting summary


 Docs meeting time?  (pkovar, 16:06:12)
  
 ACTION: pkovar to initiate a mtg time poll  (pkovar, 16:16:13)
   reconsider removing the docs ML  (pkovar, 16:23:05)
  
 decisions to be made in ML (-dev, preferably)  (pkovar, 16:23:42)
  * consider sending status updates  (pkovar, 16:24:39)

 Docs team vision document  (pkovar, 16:26:24)
  
 LINK:
    https://etherpad.openstack.org/p/docs-i18n-ptg-queens-mission-statement
    (pkovar, 16:26:34)
   LINK: https://docs.openstack.org/doc-contrib-guide/  (pkovar,
    16:27:58)
  
 ACTION: pkovar to add the vision doc to doc contrib guide  (pkovar,
    16:30:50)

 Docs retention policy changes  (pkovar, 16:31:29)
  
 LINK: https://review.openstack.org/#/c/507629  (pkovar, 16:31:47)
   LINK: https://review.openstack.org/#/c/491868/ to derive series name
    by the theme  (pkovar, 16:36:38)
  
 coordinate with tonyb and the stable team to avoid closing stable
    branches before adding badges to docs  (pkovar, 16:39:37)
   LINK:
    https://etherpad.openstack.org/p/docs-i18n-ptg-queens-release-badges
    (jamesmcarthur, 16:40:20)
  
 LINK:
    https://etherpad.openstack.org/p/docs-i18n-ptg-queens-release-badges
    (pkovar, 16:40:43)

 Contributor Portal  (pkovar, 16:43:46)
  
 LINK:
    http://lists.openstack.org/pipermail/openstack-dev/2017-October/123740.html
    (pkovar, 16:44:03)
   LINK: https://www.openstack.org/community/  (pkovar, 16:44:50)
  
 LINK: https://docs.openstack.org/contributors  (pkovar, 16:45:01)
  * LINK: https://docs.openstack.org/doc-contrib-guide/  (pkovar,
    16:45:13)

 sitemap automation suggestions  (pkovar, 16:47:39)
  
 LINK:
    http://lists.openstack.org/pipermail/openstack-dev/2017-October/123228.html
    (pkovar, 16:47:48)
  * ACTION: mguiney volunteered to help with sitemap automation, thanks
    (pkovar, 16:57:35)

Meeting ended at 17:00:10 UTC.

Action items, by person


 mguiney
  
 mguiney volunteered to help with sitemap automation, thanks
 pkovar
  
 pkovar to initiate a mtg time poll
  * pkovar to add the vision doc to doc contrib guide

People present (lines said)


* pkovar (93)
* dhellmann (58)
* jamesmcarthur (32)
* eumel8 (8)
* mguiney (8)
* bsilverman (7)
* openstack (4)
* thingee (1)

Generated by MeetBot_ 0.1.4


Message: 13
Date: Fri, 20 Oct 2017 18:33:46 +0200
From: Petr Kovar pkovar@redhat.com
To: openstack-docs@lists.openstack.org
Cc: , openstack-dev@lists.openstack.org
Subject: [openstack-dev] [docs] Docs meeting time? (was: Documentation
    meeting Thursday)
Message-ID: 20171020183346.16e966ef88621ed2e83dff86@redhat.com
Content-Type: text/plain; charset=UTF-8

Chason, 

Thanks for bringing this up. I definitely don't want contributors from Asia
to feel excluded. We discussed it in the docs meeting yesterday and it's
clear that finding a meeting time that would work for Asia, Europe and
America is a bit difficult, to say the least. 

Anyhow, I went ahead and I set up a poll to better understand what are
people's preferences wrt meeting time:

http://whenisgood.net/qtqbz52

All, if you could indicate your time preference, that would be appreciated.

Results will appear here:

http://whenisgood.net/qtqbz52/results/ptgfrap

Thanks,
pk

On Thu, 19 Oct 2017 20:47:12 +0800
Chason chason.chan@foxmail.com wrote:

 Hi Petr,
 
 Is there any chance the meeting could be moved earlier one so Asian can make it?
 Thursday at 16:00 UTC is Friday at 1:00 here.
 
 Thanks,
 
 Chason
 
 > 在 2017年10月19日,下午8:00,openstack-docs-request@lists.openstack.org 写道:
 > 
 > Send OpenStack-docs mailing list submissions to
 >     openstack-docs@lists.openstack.org
 > 
 > To subscribe or unsubscribe via the World Wide Web, visit
 >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
 > or, via email, send a message with subject or body 'help' to
 >     openstack-docs-request@lists.openstack.org
 > 
 > You can reach the person managing the list at
 >     openstack-docs-owner@lists.openstack.org
 > 
 > When replying, please edit your Subject line so it is more specific
 > than "Re: Contents of OpenStack-docs digest..."
 > 
 > 
 > Today's Topics:
 > 
 >   1. [docs] Documentation meeting Thursday (Petr Kovar)
 > 
 > 
 > ----------------------------------------------------------------------
 > 
 > Message: 1
 > Date: Wed, 18 Oct 2017 15:07:39 +0200
 > From: Petr Kovar pkovar@redhat.com
 > To: openstack-docs@lists.openstack.org
 > Cc: openstack-dev@lists.openstack.org
 > Subject: [OpenStack-docs] [docs] Documentation meeting Thursday
 > Message-ID: 20171018150739.28a243fd1691f243c3002da1@redhat.com
 > Content-Type: text/plain; charset=US-ASCII
 > 
 > Hi all,
 > 
 > The docs meeting will continue tomorrow, Thursday at 16:00 UTC in
 > #openstack-meeting, as scheduled. For more details, and the agenda, see the meeting page:
 > 
 > https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting
 > 
 > Cheers,
 > pk
 > 
 > 
 > 
 > ------------------------------
 > 
 > Subject: Digest Footer
 > 
 > _______________________________________________
 > OpenStack-docs mailing list
 > OpenStack-docs@lists.openstack.org
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
 > 
 > 
 > ------------------------------
 > 
 > End of OpenStack-docs Digest, Vol 64, Issue 9
 > *********************************************
 
 
 
 
 _______________________________________________
 OpenStack-docs mailing list
 OpenStack-docs@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs


Message: 14
Date: Sat, 21 Oct 2017 00:39:41 +0800
From: Yaguang Tang heut2008@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone][all][tc] v2.0 API removal
Message-ID:
    CAPP2CaUj9GgjweB02W5qQbWD+jX=2cjSoNEqFpqXMzfv3VdWBg@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

I am not saying keystone team don't follow the policy. Just want to express
my concern for this big action. it's a cross project thing, so want to have
a widely agreement. from the user's aspect, I want to ask the keystone team
to keep the V2 API for a long time if we don't have
to spend to much effort to maintain it.

On Fri, Oct 20, 2017 at 8:46 PM, Jeremy Stanley fungi@yuggoth.org wrote:

 On 2017-10-20 10:52:36 +0800 (+0800), Yaguang Tang wrote:
 > Keystone is one project that all other OpenStack projects use, so
 > personally I think the change to remove the API which are widely
 > used should be discussed at TC meeting .
 [...]

 The OpenStack Technical Committee ceased holding regular weekly
 meetings around 6 months ago:

 https://governance.openstack.org/tc/resolutions/20170425-
 drop-tc-weekly-meetings.html

 Also, the TC is not generally in the business of making decisions on
 behalf of projects and instead provides opt-in policy in the form of
 "tags" which projects can choose to apply to their teams or
 deliverables, such as:

 https://governance.openstack.org/tc/reference/tags/assert_
 follows-standard-deprecation.html

 As you can see, the Keystone team asserts the keystone API service
 follows the deprecation model indicated there. Are you suggesting
 that policy was not followed, or that it's merely insufficient?
 --
 Jeremy Stanley

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

-- 
Tang Yaguang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 15
Date: Fri, 20 Oct 2017 16:54:31 +0000
From: Chan Chason chenxingcampus@outlook.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: [openstack-dev] [docs] Docs meeting time? (was: Documentation
    meeting Thursday)
Message-ID:
    PS1PR0601MB20127D3E2F8C59E0EC6F4E15DD430@PS1PR0601MB2012.apcprd06.prod.outlook.com

Content-Type: text/plain; charset="gb2312"

Great! I have indicated my time preference and hopefully we can get a time for all of us. :P

Thanks,

Chason

 在 2017年10月21日,上午12:33,Petr Kovar pkovar@redhat.com 写道:
 
 Chason, 
 
 Thanks for bringing this up. I definitely don't want contributors from Asia
 to feel excluded. We discussed it in the docs meeting yesterday and it's
 clear that finding a meeting time that would work for Asia, Europe and
 America is a bit difficult, to say the least. 
 
 Anyhow, I went ahead and I set up a poll to better understand what are
 people's preferences wrt meeting time:
 
 http://whenisgood.net/qtqbz52
 
 All, if you could indicate your time preference, that would be appreciated.
 
 Results will appear here:
 
 http://whenisgood.net/qtqbz52/results/ptgfrap
 
 Thanks,
 pk
 
 
 On Thu, 19 Oct 2017 20:47:12 +0800
 Chason chason.chan@foxmail.com wrote:
 

 Hi Petr,
 
 Is there any chance the meeting could be moved earlier one so Asian can make it?
 Thursday at 16:00 UTC is Friday at 1:00 here.
 
 Thanks,
 
 Chason
 

 在 2017年10月19日,下午8:00,openstack-docs-request@lists.openstack.org 写道:
 
 Send OpenStack-docs mailing list submissions to
     openstack-docs@lists.openstack.org
 
 To subscribe or unsubscribe via the World Wide Web, visit
     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
 or, via email, send a message with subject or body 'help' to
     openstack-docs-request@lists.openstack.org
 
 You can reach the person managing the list at
     openstack-docs-owner@lists.openstack.org
 
 When replying, please edit your Subject line so it is more specific
 than "Re: Contents of OpenStack-docs digest..."
 
 
 Today's Topics:
 
  1. [docs] Documentation meeting Thursday (Petr Kovar)
 
 
 ----------------------------------------------------------------------
 
 Message: 1
 Date: Wed, 18 Oct 2017 15:07:39 +0200
 From: Petr Kovar pkovar@redhat.com
 To: openstack-docs@lists.openstack.org
 Cc: openstack-dev@lists.openstack.org
 Subject: [OpenStack-docs] [docs] Documentation meeting Thursday
 Message-ID: 20171018150739.28a243fd1691f243c3002da1@redhat.com
 Content-Type: text/plain; charset=US-ASCII
 
 Hi all,
 
 The docs meeting will continue tomorrow, Thursday at 16:00 UTC in
 #openstack-meeting, as scheduled. For more details, and the agenda, see the meeting page:
 
 https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting
 
 Cheers,
 pk
 
 
 
 ------------------------------
 
 Subject: Digest Footer
 
 _______________________________________________
 OpenStack-docs mailing list
 OpenStack-docs@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
 
 
 ------------------------------
 
 End of OpenStack-docs Digest, Vol 64, Issue 9
 *********************************************
 
 
 
 
 _______________________________________________
 OpenStack-docs mailing list
 OpenStack-docs@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
 
 __________________________________________________________________________
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Message: 16
Date: Fri, 20 Oct 2017 17:15:59 +0000
From: "Fox, Kevin M" Kevin.Fox@pnnl.gov
To: "heut2008@gmail.com" heut2008@gmail.com, "OpenStack Development
    Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]
    [keystone][all] v2.0    API removal
Message-ID:
    1A3C52DFCD06494D8528644858247BF01C018E10@EX10MBOX03.pnnl.gov
Content-Type: text/plain; charset="iso-8859-1"

That is a very interesting question.

It comes from the angle of OpenStack the product more then from the standpoint of any one OpenStack project.

I know the TC's been shying away from these sorts of questions, but this one has a pretty big impact. TC?

Thanks,
Kevin


From: Yaguang Tang [heut2008@gmail.com]
Sent: Thursday, October 19, 2017 7:59 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal

Should this kind of change  be discussed and have an agreement of the TC and User committee?

---------- Forwarded message ----------
From: Lance Bragstad lbragstad@gmail.com
Date: Fri, Oct 20, 2017 at 12:08 AM
Subject: [Openstack-operators] [keystone][all] v2.0 API removal
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org, openstack-operators@lists.openstack.org

Hey all,

Now that we're finishing up the last few bits of v2.0 removal, I'd like to send out a reminder that Queens will not include the v2.0 keystone APIs except the ec2-api. Authentication and validation of v2.0 tokens has been removed (in addition to the public and admin APIs) after a lengthy deprecation period.

Let us know if you have any questions.

Thanks!


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

--
Tang Yaguang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 17
Date: Fri, 20 Oct 2017 13:16:24 -0400
From: Jeremy Freudberg jeremyfreudberg@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Do you hate the new gerrit thing where
    the cursor jumps all over?
Message-ID:
    CAFntmSjoGDQrD_eGngOsyYWJ5Su+Jw3Tc3gX2aRNoqx07ZJw2A@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

I don't wanna turn this into a complaint session about new Gerrit. But
three little notes since the upgrade:

- I can't push the "e" key to go into editing mode anymore
- Cherry-picks change the gerrit topic (that's probably a feature)
- The patch I'm already looking at shows up under "Same Topic" (that's
probably a feature)

The only one that really kills me is the first one. Anyone know if the
keyboard shortcut changed, or if it's disabled but configurable, etc...?

On Fri, Oct 20, 2017 at 12:02 PM, Matt Riedemann mriedemos@gmail.com
wrote:

 When you're lower in a change trying to expand comments and it always
 jumps you back up to the top?

 Since not everyone might know about the solution, it's:

 1. Go into settings
 2. Diff Preference
 3. Change "Render" from Fast to Slow.
 4. Save

 Get back to reviewing stuff without losing your mind.

 --

 Thanks,

 Matt

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 18
Date: Fri, 20 Oct 2017 10:27:38 -0700
From: Clark Boylan cboylan@sapwetik.org
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Do you hate the new gerrit thing where
    the cursor jumps all over?
Message-ID:
    1508520458.2152876.1145647736.2707BF5D@webmail.messagingengine.com
Content-Type: text/plain; charset="utf-8"

On Fri, Oct 20, 2017, at 10:16 AM, Jeremy Freudberg wrote:
 I don't wanna turn this into a complaint session about new Gerrit. But
 three little notes since the upgrade:
 
 - I can't push the "e" key to go into editing mode anymore
 - Cherry-picks change the gerrit topic (that's probably a feature)
 - The patch I'm already looking at shows up under "Same Topic" (that's
 probably a feature)
 
 
 The only one that really kills me is the first one. Anyone know if the
 keyboard shortcut changed, or if it's disabled but configurable, etc...?

The help overlay on the diff screen (brought up by hitting '?') says it
is now " +  + e : Open Inline Editor".

This seems to work for me in firefox on linux.

Hope this helps,
Clark


Message: 19
Date: Fri, 20 Oct 2017 17:43:02 +0000
From: Jeremy Stanley fungi@yuggoth.org
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]
    [keystone][all] v2.0 API removal
Message-ID: 20171020174302.GC28203@yuggoth.org
Content-Type: text/plain; charset="utf-8"

On 2017-10-20 10:59:36 +0800 (+0800), Yaguang Tang wrote:
 Should this kind of change  be discussed and have an agreement of
 the TC and User committee?
[...]

Looks like this thread has split since bouncing back in from the
operators ML, but I replied in the "other" dev ML thread for this
topic already:

http://lists.openstack.org/pipermail/openstack-dev/2017-October/123813.html

Do you have any suggested guidelines for the scope or scale of
impact for some deprecations and removals which should be held to a
higher standard? Would you be willing to work with the TC to update
the existing deprecation tag (or come up with an additional one) to
covers this additional policy?
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: 


Message: 20
Date: Fri, 20 Oct 2017 17:53:47 +0000
From: Jeremy Stanley fungi@yuggoth.org
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]
    [keystone][all] v2.0    API removal
Message-ID: 20171020175347.GD28203@yuggoth.org
Content-Type: text/plain; charset="utf-8"

On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:
[...]
 I know the TC's been shying away from these sorts of questions,
 but this one has a pretty big impact. TC?
[...]

The OpenStack Technical Committee isn't really a bludgeon with which
to beat teams when someone in the community finds fault with a
decision; it drafts/revises policy and arbitrates disputes between
teams. What sort of action are you seeking in regard to the Keystone
team finally acting this cycle on removal of their long-deprecated
legacy API, and with what choices of theirs do you disagree?

Do you feel the deprecation was not communicated widely enough? Do
you feel that SDKs haven't been updated with sufficient support for
the v3 API? Are you concerned that lack of v2 API support will
prevent organizations running the upcoming Queens release from
qualifying for interoperability trademarks? Something else entirely?
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: 


Message: 21
Date: Fri, 20 Oct 2017 14:08:26 -0400
From: Jeremy Freudberg jeremyfreudberg@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Do you hate the new gerrit thing where
    the cursor jumps all over?
Message-ID:
    CAFntmSiVoKem0XFkRyzz11sZ7ANGoK9d0eeA=Fbfs00aLzXmXg@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

Indeed it helps. Thanks!

On Fri, Oct 20, 2017 at 1:27 PM, Clark Boylan cboylan@sapwetik.org wrote:

 On Fri, Oct 20, 2017, at 10:16 AM, Jeremy Freudberg wrote:
 > I don't wanna turn this into a complaint session about new Gerrit. But
 > three little notes since the upgrade:
 >
 > - I can't push the "e" key to go into editing mode anymore
 > - Cherry-picks change the gerrit topic (that's probably a feature)
 > - The patch I'm already looking at shows up under "Same Topic" (that's
 > probably a feature)
 >
 >
 > The only one that really kills me is the first one. Anyone know if the
 > keyboard shortcut changed, or if it's disabled but configurable, etc...?

 The help overlay on the diff screen (brought up by hitting '?') says it
 is now " +  + e : Open Inline Editor".

 This seems to work for me in firefox on linux.

 Hope this helps,
 Clark

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 22
Date: Fri, 20 Oct 2017 11:17:52 -0700
From: Clark Boylan cboylan@sapwetik.org
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Distutils][pbr] Announcement: Pip
    10 is coming, and will move all internal APIs
Message-ID:
    1508523472.3134925.1145696440.0CC7B066@webmail.messagingengine.com
Content-Type: text/plain; charset="utf-8"

On Fri, Oct 20, 2017, at 07:23 AM, Doug Hellmann wrote:
 It sounds like the PyPI/PyPA folks are planning some major changes to
 pip internals, soon.
 
 I know pbr uses setuptools, and I don't think it uses pip, but if
 someone has time to verify that it would be helpful.
 
 We'll also want to watch out for breakage in normal use of pip 10. If
 they're making changes this big, they may miss something in their own
 test coverage that affects our jobs.
 

After a quick skim of PBR I don't think we use pip internals anywhere.
Its all executed via the command itself. That said we should test this
so I've put up https://review.openstack.org/513825 (others should feel
free to iterate on it if it doesn't work) to install latest pip master
in a devstack run.

Clark


Message: 23
Date: Fri, 20 Oct 2017 12:17:11 -0700
From: Clark Boylan cboylan@sapwetik.org
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Distutils][pbr] Announcement: Pip
    10 is coming, and will move all internal APIs
Message-ID:
    1508527031.3146731.1145751688.60C55938@webmail.messagingengine.com
Content-Type: text/plain; charset="utf-8"

On Fri, Oct 20, 2017, at 11:17 AM, Clark Boylan wrote:
 On Fri, Oct 20, 2017, at 07:23 AM, Doug Hellmann wrote:
 > It sounds like the PyPI/PyPA folks are planning some major changes to
 > pip internals, soon.
 > 
 > I know pbr uses setuptools, and I don't think it uses pip, but if
 > someone has time to verify that it would be helpful.
 > 
 > We'll also want to watch out for breakage in normal use of pip 10. If
 > they're making changes this big, they may miss something in their own
 > test coverage that affects our jobs.
 > 
 
 After a quick skim of PBR I don't think we use pip internals anywhere.
 Its all executed via the command itself. That said we should test this
 so I've put up https://review.openstack.org/513825 (others should feel
 free to iterate on it if it doesn't work) to install latest pip master
 in a devstack run.

And it has already caught its first bug. Fix and details at
https://review.openstack.org/#/c/513832/.

Clark


Message: 24
Date: Fri, 20 Oct 2017 19:25:34 +0000
From: "Waines, Greg" Greg.Waines@windriver.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: [openstack-dev] [ironic] Support for single OpenStack system
    supporting VM and Baremetal Instances simultaneously ?
Message-ID: 9890703D-EFD0-4BA5-8947-171302BF0A64@windriver.com
Content-Type: text/plain; charset="utf-8"

Hey,

We are in the process of integrating OpenStack Ironic into our own OpenStack Distribution.

Is there support for a single OpenStack system supporting VM and Baremetal Instances simultaneously ?  ( in NEWTON ?  in PIKE ? )
I BELIEVE the answer is yes.
BUT can someone confirm ?

And then, if YES,
THEN in such a system

·         i know there is a nova-compute for each COMPUTE NODE, and

·         i know there is a nova-compute for ALL the IRONIC NODEs

·         QUESTION:

o    Is there still ONLY A SINGLE nova-scheduler ?

o    i.e. which, based on the baremetal extraspec, schedules over the COMPUTE NODES or the IRONIC NODES ?

Greg.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 25
Date: Sat, 21 Oct 2017 06:55:48 +1100
From: Ian Wienand iwienand@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [infra] Short gerrit / zuul outage
    2017-10-20    20:00UTC
Message-ID: cbb313c9-e54d-8f8b-3ad6-8ffc8e09631e@redhat.com
Content-Type: text/plain; charset=utf-8; format=flowed

On 10/20/2017 03:46 PM, Ian Wienand wrote:
 We plan a short outage (<30 minutes) of gerrit and zuul on 2017-10-20
 20:00UTC to facilitate project rename requests.

Note this has been postponed to a future (TBD) date

Thanks,

-i


Message: 26
Date: Fri, 20 Oct 2017 13:14:13 -0700
From: Clark Boylan cboylan@sapwetik.org
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Distutils][pbr] Announcement: Pip
    10 is coming, and will move all internal APIs
Message-ID:
    1508530453.4124986.1145802896.63B3365C@webmail.messagingengine.com
Content-Type: text/plain; charset="utf-8"

On Fri, Oct 20, 2017, at 11:17 AM, Clark Boylan wrote:
 On Fri, Oct 20, 2017, at 07:23 AM, Doug Hellmann wrote:
 > It sounds like the PyPI/PyPA folks are planning some major changes to
 > pip internals, soon.
 > 
 > I know pbr uses setuptools, and I don't think it uses pip, but if
 > someone has time to verify that it would be helpful.
 > 
 > We'll also want to watch out for breakage in normal use of pip 10. If
 > they're making changes this big, they may miss something in their own
 > test coverage that affects our jobs.
 > 
 
 After a quick skim of PBR I don't think we use pip internals anywhere.
 Its all executed via the command itself. That said we should test this
 so I've put up https://review.openstack.org/513825 (others should feel
 free to iterate on it if it doesn't work) to install latest pip master
 in a devstack run.

The current issue this change is facing can be seen at
http://logs.openstack.org/25/513825/4/check/legacy-tempest-dsvm-py35/c31deb2/logs/devstacklog.txt.gz#_2017-10-20_20_07_54_838.
The tl;dr is that for distutils installed packages (basically all the
distro installed python packges) pip refuses to uninstall them in order
to perform upgrades because it can't reliably determine where all the
files are. I think this is a new pip 10 behavior.

In the general case I think this means we can not rely on global pip
installs anymore. This may be a good thing to bring up with upstream
PyPA as I expect it will break a lot of people in a lot of places (it
will break infra for example too).

Clark


Message: 27
Date: Fri, 20 Oct 2017 15:15:34 -0500
From: Miguel Lavalle miguel@mlavalle.com
To: OpenStack Development Mailing List
    openstack-dev@lists.openstack.org
Subject: [openstack-dev]  [neutron] - are you attending the Sydney
    summit?
Message-ID:
    CAEzGLDh=68Gn__FAnex-TfBxwnKcgq=4sORe92scmr-M-CdwYA@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

Hi,

If you are a Neutron developer attending the Sydney Summit, please add your
name to the following etherpad so we can plan a team social event and
easily coordinate in person meetings:

https://etherpad.openstack.org/p/neutron-sydney-summit-attendees

Safe travels and see you Down Under!

Cheers

Miguel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 28
Date: Fri, 20 Oct 2017 16:32:05 -0400
From: Doug Hellmann doug@doughellmann.com
To: openstack-dev openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Distutils][pbr][devstack][qa]
    Announcement: Pip 10 is coming, and will move all internal APIs
Message-ID: 1508531248-sup-3881@lrrr.local
Content-Type: text/plain; charset=UTF-8

Excerpts from Clark Boylan's message of 2017-10-20 13:14:13 -0700:

 On Fri, Oct 20, 2017, at 11:17 AM, Clark Boylan wrote:
 > On Fri, Oct 20, 2017, at 07:23 AM, Doug Hellmann wrote:
 > > It sounds like the PyPI/PyPA folks are planning some major changes to
 > > pip internals, soon.
 > > 
 > > I know pbr uses setuptools, and I don't think it uses pip, but if
 > > someone has time to verify that it would be helpful.
 > > 
 > > We'll also want to watch out for breakage in normal use of pip 10. If
 > > they're making changes this big, they may miss something in their own
 > > test coverage that affects our jobs.
 > > 
 > 
 > After a quick skim of PBR I don't think we use pip internals anywhere.
 > Its all executed via the command itself. That said we should test this
 > so I've put up https://review.openstack.org/513825 (others should feel
 > free to iterate on it if it doesn't work) to install latest pip master
 > in a devstack run.
 
 The current issue this change is facing can be seen at
 http://logs.openstack.org/25/513825/4/check/legacy-tempest-dsvm-py35/c31deb2/logs/devstacklog.txt.gz#_2017-10-20_20_07_54_838.
 The tl;dr is that for distutils installed packages (basically all the
 distro installed python packges) pip refuses to uninstall them in order
 to perform upgrades because it can't reliably determine where all the
 files are. I think this is a new pip 10 behavior.
 
 In the general case I think this means we can not rely on global pip
 installs anymore. This may be a good thing to bring up with upstream
 PyPA as I expect it will break a lot of people in a lot of places (it
 will break infra for example too).
 
 Clark
 

Yes, it would be good for someone who understands the cases where we're
doing these sorts of global package installations using pip to post on
distutils-sig explaining the breakage and asking for some time to let us
work around the issue.

We have a couple of ways to mitigate it, depending on the situation.

1. Pin the affected packages to the system package versions in our
   constraints list.

2. Install into a virtualenv that ignores system packages, avoiding the
   need to upgrade at all.

3. Remove the system package before installing from pip (why is it there
   in the first place?).

It's not clear to me which is the best approach.  I've added
[devstack][qa] to the subject line to draw some more attention to
this thread from folks familiar with these jobs.

Doug


Message: 29
Date: Fri, 20 Oct 2017 20:43:59 +0000
From: Andrea Frittoli andrea.frittoli@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: [openstack-dev] [qa] Proposing changes to 17UTC team meeting
Message-ID:
    CAB7WYGUUXNcbROknz_O4DCoZjC7poZyPdvJuRLgem9-FHqw42Q@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

Dear all,

The current schedule for QA meetings and office hours is as follows
(alternating weeks):

Week1:
- Tue 9:00 UTC Office hours in #openstack-qa
- Tue 17:00 UTC Meeting in #openstack-meeting
Week2:
- Tue 8:00 UTC Meeting in #openstack-meeting

Since the 17:00 UTC as a rather low attendance, but not zero, I would
propose to drop that meeting in favour of a second office hours slot, so
that we have one slot every week and the meeting would be every
second week:

Week1:
- Tue 9:00 UTC Office hours in #openstack-qa
Week2:
- Tue 8:00 UTC Meeting in #openstack-meeting
- [TBD] Office hours in #openstack-qa

Proposals for the office hours schedule in the doodle [0]

Let me know your thoughts on this proposal and please vote for the
time slot in the doodle.

Thank you!

Andrea Frittoli (andreaf)

[0] https://doodle.com/poll/kf6b8847wa2s5mxv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 30
Date: Fri, 20 Oct 2017 21:25:26 +0000
From: Kendall Nelson kennelson11@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: [openstack-dev] [All][Elections] Vote Vote Vote in the TC
    election!
Message-ID:
    CAJ6yrQiTjFc5+-K-wCF_4nz7Ky0V7pbO8sjSKatua8Ui_EyE0g@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

Hello!

We are coming down to the last hours for voting in the TC election. Voting
ends 23:45 October 20th, 2017.

Search your gerrit preferred email address[0] for the following subject:
    Poll: Queens TC Election

That is your ballot and links you to the voting application. Please vote.
If you have voted, please encourage your colleagues to vote.

Candidate statements are linked to the names of all confirmed candidates:
http://governance.openstack.org/election/#
pike
-tc-candidates

What to do if you don't see the email and have a commit in at least one of
the official programs projects1:
   check the trash of your gerrit Preferred Email address[0], in case it
went into trash or spam
  
 wait a bit and check again, in case your email server is a bit slow
  * find the sha of at least one commit from the program project repos1
and email the election officials[2]. If we can confirm that you are
entitled to vote, we will add you to the voters list and you will be
emailed a ballot.

Please vote!

Thank you,

Kendall Nelson (diablo_rojo)

[0] Sign into review.openstack.org: Go to Settings > Contact
    Information. Look at the email listed as your Preferred Email.
    That is where the ballot has been sent.
oct

-2017

-elections

[2] http://governance.openstack.org/election/#election-officials
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 31
Date: Fri, 20 Oct 2017 17:50:15 -0400
From: Sam Yaple samuel@yaple.net
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Distutils][pbr][devstack][qa]
    Announcement: Pip 10 is coming, and will move all internal APIs
Message-ID:
    CAJ3CzQVG+R+DeYf89uGWEeK36w+n+t6AuAE5MD2S8_=nyiOJPA@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

On Fri, Oct 20, 2017 at 4:32 PM, Doug Hellmann doug@doughellmann.com
wrote:

 Excerpts from Clark Boylan's message of 2017-10-20 13:14:13 -0700:
 > On Fri, Oct 20, 2017, at 11:17 AM, Clark Boylan wrote:
 > > On Fri, Oct 20, 2017, at 07:23 AM, Doug Hellmann wrote:
 > > > It sounds like the PyPI/PyPA folks are planning some major changes to
 > > > pip internals, soon.
 > > >
 > > > I know pbr uses setuptools, and I don't think it uses pip, but if
 > > > someone has time to verify that it would be helpful.
 > > >
 > > > We'll also want to watch out for breakage in normal use of pip 10. If
 > > > they're making changes this big, they may miss something in their own
 > > > test coverage that affects our jobs.
 > > >
 > >
 > > After a quick skim of PBR I don't think we use pip internals anywhere.
 > > Its all executed via the command itself. That said we should test this
 > > so I've put up https://review.openstack.org/513825 (others should feel
 > > free to iterate on it if it doesn't work) to install latest pip master
 > > in a devstack run.
 >
 > The current issue this change is facing can be seen at
 > http://logs.openstack.org/25/513825/4/check/legacy-tempest-
 dsvm-py35/c31deb2/logs/devstacklog.txt.gz#_2017-10-20_20_07_54_838.
 > The tl;dr is that for distutils installed packages (basically all the
 > distro installed python packges) pip refuses to uninstall them in order
 > to perform upgrades because it can't reliably determine where all the
 > files are. I think this is a new pip 10 behavior.
 >
 > In the general case I think this means we can not rely on global pip
 > installs anymore. This may be a good thing to bring up with upstream
 > PyPA as I expect it will break a lot of people in a lot of places (it
 > will break infra for example too).
 >
 > Clark
 >

 Yes, it would be good for someone who understands the cases where we're
 doing these sorts of global package installations using pip to post on
 distutils-sig explaining the breakage and asking for some time to let us
 work around the issue.

 We have a couple of ways to mitigate it, depending on the situation.

 1. Pin the affected packages to the system package versions in our
    constraints list.

 2. Install into a virtualenv that ignores system packages, avoiding the
    need to upgrade at all.

 3. Remove the system package before installing from pip (why is it there
    in the first place?).

 It's not clear to me which is the best approach.  I've added
 [devstack][qa] to the subject line to draw some more attention to
 this thread from folks familiar with these jobs.

 Doug

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

I have used option 2 with great success to avoid the issue of system
package conflicts for a couple of years now, back when pip would still
uninstall system packages for upgrades.

Option 3 is difficult to make work since so many packages have dependancies
on python-* packages, I abandoned that approach fairly quickly.

Thanks,
SamYaple
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 32
Date: Fri, 20 Oct 2017 22:50:53 +0000
From: "Fox, Kevin M" Kevin.Fox@pnnl.gov
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]
    [keystone][all] v2.0    API removal
Message-ID:
    1A3C52DFCD06494D8528644858247BF01C019FFD@EX10MBOX03.pnnl.gov
Content-Type: text/plain; charset="us-ascii"

No, I'm not saying its the TC teams job to bludgeon folks.

I'm suggesting that some folks other then Keystone should look at the impact of the final removal an api that a lot of external clients may be coded against and since it effects all projects and not just Keystone. And have some say on delaying the final removal if appropriate. 

I personally would like to see v2 go away. But I get that the impact could be far wider ranging and affecting many other teams then just Keystone due to the unique position Keystone is in the architecture. As others have raised.

Ideally, there should be an OpenStack overarching architecture team of some sort to handle this kind of thing I think. Without such an entity though, I think the TC is probably currently the best place to discuss it though?

Thanks,
Kevin


From: Jeremy Stanley [fungi@yuggoth.org]
Sent: Friday, October 20, 2017 10:53 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0        API removal

On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:
[...]
 I know the TC's been shying away from these sorts of questions,
 but this one has a pretty big impact. TC?
[...]

The OpenStack Technical Committee isn't really a bludgeon with which
to beat teams when someone in the community finds fault with a
decision; it drafts/revises policy and arbitrates disputes between
teams. What sort of action are you seeking in regard to the Keystone
team finally acting this cycle on removal of their long-deprecated
legacy API, and with what choices of theirs do you disagree?

Do you feel the deprecation was not communicated widely enough? Do
you feel that SDKs haven't been updated with sufficient support for
the v3 API? Are you concerned that lack of v2 API support will
prevent organizations running the upcoming Queens release from
qualifying for interoperability trademarks? Something else entirely?
--
Jeremy Stanley


Message: 33
Date: Fri, 20 Oct 2017 22:51:29 +0000
From: "Steven Dake (stdake)" stdake@cisco.com
To: "sam@yaple.net" sam@yaple.net, "OpenStack Development Mailing
    List (not for usage questions)" openstack-dev@lists.openstack.org,
    Gabriele Cerami gcerami@redhat.com
Subject: Re: [openstack-dev] [TripleO][Kolla] Concerns about
    containers images in DockerHub
Message-ID: 6F137552-59BD-40E2-B498-4564A6250B73@cisco.com
Content-Type: text/plain; charset="utf-8"

Sam,

Agreed this matches my experience. Building one by one though will result in massive image size sprawl.

Regards
-steve

From: Sam Yaple samuel@yaple.net
Reply-To: "sam@yaple.net" sam@yaple.net, "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Date: Thursday, October 19, 2017 at 10:37 PM
To: Gabriele Cerami gcerami@redhat.com
Cc: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO][Kolla] Concerns about containers images in DockerHub

On Thu, Oct 19, 2017 at 11:23 PM, Gabriele Cerami gcerami@redhat.com wrote:
On 19 Oct, Sam Yaple wrote:
 So it seems tripleo is building all images and then pushing them.
 Reworking your number leads me to believe you will be consuming 10-15GB in
 total on Dockerhub. Kolla images are only the size that you posted when
 built as seperate services. Just keep building all the images at the same
 time and you wont get anywhere near the numbers you posted.

Makes sense, so considering the shared layers
- a size of 10-15GB per build.
- 4-6 builds rotated per release
- 3-4 releases

- a size of 1-2GB per build
- 4-6 builds rotated per release
- 3-4 releases

At worst you are looking at 48GB not 360GB. Dont worry so much there!

total size will be approximately be 360GB in the worst case, and 120GB in
the best case, which seems a bit more reasonable.

Thanks for he clarifications

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 34
Date: Fri, 20 Oct 2017 16:06:00 -0700
From: Tim Burke tim@swiftstack.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Do you hate the new gerrit thing where
    the cursor jumps all over?
Message-ID: C9C23ACB-2DFC-453E-A8AA-8475E448C7E3@swiftstack.com
Content-Type: text/plain; charset=us-ascii

OMG yes! I can actually search when looking at a diff now!

Thanks Matt.

Tim

 On Oct 20, 2017, at 9:02 AM, Matt Riedemann mriedemos@gmail.com wrote:
 
 When you're lower in a change trying to expand comments and it always jumps you back up to the top?
 
 Since not everyone might know about the solution, it's:
 
 1. Go into settings
 2. Diff Preference
 3. Change "Render" from Fast to Slow.
 4. Save
 
 Get back to reviewing stuff without losing your mind.
 
 -- 
 
 Thanks,
 
 Matt
 
 __________________________________________________________________________
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Message: 35
Date: Fri, 20 Oct 2017 23:59:15 +0000
From: Kendall Nelson kennelson11@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: [openstack-dev] [all] [elections] Technical Committee
    Election    Results
Message-ID:
    CAJ6yrQg=OsmSwg4z11jy=vGCsBDL4C7vG-DhfiReJnRck018hw@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

Hello Everyone :)

Please join me in congratulating the 6 newly elected members of the
Technical Committee (TC)!

Colleen Murphy (cmurphy)
Doug Hellmann (dhellmann)
Emilien Macchi (emilienm)
Jeremy Stanley (fungi)
Julia Kreger (TheJulia)
Paul Belanger (pabelanger)

Full results:
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae

Election process details and results are also available here:
https://governance.openstack.org/election/

Thank you to all of the candidates, having a good group of candidates helps
engage the community in our democratic process.

Thank you to all who voted and who encouraged others to vote. We need to
ensure your voice is heard.

Thank you for another great round.

-Kendall Nelson (diablo_rojo)

1 https://review.openstack.org/#/c/513881/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 36
Date: Sat, 21 Oct 2017 02:12:46 +0200
From: Ildiko Vancsa ildiko.vancsa@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] [elections] Technical Committee
    Election Results
Message-ID: 714F6FEF-F841-4594-A7B6-364F926DB951@gmail.com
Content-Type: text/plain; charset=utf-8

Congratulations to our new TC members! :)

Best Regards,
Ildikó

 On 2017. Oct 21., at 1:59, Kendall Nelson kennelson11@gmail.com wrote:
 
 Hello Everyone :) 
 
 Please join me in congratulating the 6 newly elected members of the Technical Committee (TC)!
 
 Colleen Murphy (cmurphy)
 Doug Hellmann (dhellmann)
 Emilien Macchi (emilienm)
 Jeremy Stanley (fungi)
 Julia Kreger (TheJulia)
 Paul Belanger (pabelanger)
 
 Full results: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae 
 
 Election process details and results are also available here: https://governance.openstack.org/election/ 
 
 Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process.
 
 Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard.
 
 Thank you for another great round.
 
 -Kendall Nelson (diablo_rojo)
 
 1 https://review.openstack.org/#/c/513881/ 
 __________________________________________________________________________
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Message: 37
Date: Fri, 20 Oct 2017 17:16:31 -0700
From: Morgan Fainberg morgan.fainberg@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]
    [keystone][all] v2.0 API removal
Message-ID:
    CAGnj6atBqi5Vo0xpsuNo7+x4U=ixLoRfoQ1Xkq5+ZqVHNaDvBg@mail.gmail.com
Content-Type: text/plain; charset="UTF-8"

Let me clarify a few things regarding the V2.0 removal:

* This has been planned for years at this point. At one time (I am
looking for the documentation, once I find it I'll include it on this
thread) we worked with Nova and the TC to set forth a timeline on the
removal. Part of that agreement was that this was a one-time deal. We
would remove the V2.0 API in favor of the v3 API but would never
remove another API going forward.

   A few reasons for removing the V2.0 API that were discussed and
drove the decision:

   1) The V2.0 API had behavior that was explicitly breaking the security model:

       * A user could authenticate with a scope not the default
domain) which could lead to oddities in enforcement when using v2.0
APIs and introduced a number of edge cases. This could not be fixed
without breaking the V2.0 API contract and every single change to V3
and features required a lot of time to ensure V2.0 was not breaking
and had appropriate translations to/from the different data formats.

       * The V2.0 AUTH API included the token (secure) data in the URL
path, this means that all logs from apache (or other web servers and
wsgi apps) had to be considered privileged and could not be exposed
for debugging purposes (and in some environments may not be accessed
without significant access-controls). This also could not be fixed
without breaking the V2.0 API contract.

       * The V2.0 policy was effectively hard coded (effectively) to
use "admin" and "member" roles. Retrofitting the APIs to support fully
policy was extremely difficult and could break default behaviors
(easily) in many environments. This was also deemed to be mostly
unfix-able without breaking the V2.0 API contract.

     In short, the maintenance on V2.0 API was significant, it was a
lot of work to maintain especially since the API could not receive any
active development due to lacking basic features introduced in v3.0.
There were also a significant number of edge cases where v3 had some
very hack-y support for features (required in openstack services) via
auth to support the possibility of v2->v3 translations.

   2) V2.0 had been bit rotting. Many items had limited testing and
were found to be broken. Adding tests that were both V3 and V2.0 aware
added another layer of difficulty in maintaining the API, much of the
time we had to spin many new patches to ensure that we didn't break
v2.0 contracts with a non-breaking v3 change (or in fixing a v2 API
call, we would be somewhat forced into breaking the API contract).

   3) The Keystone team is acutely aware that this was a painful
transition and made the choice to drop the API even in that light. The
choice of "breaking the API contract" a number of times verses
lightening the developer load (we are strapped for resources working
on Keystone as are many services, the overhead and added load makes it
mostly untenable) and do a single (large) change with the
understanding that V3 APIs cannot be removed was preferable.

The TC agreed to this removal. The service teams agreed to this
removal. This was telegraphed as much as we could via deprecation and
many, many, many discussions on this topic. There really was no good
solution, we took the solution that was the best for OpenStack in our
opinion based upon the place where Keystone is.

We can confidently commit to the following:
   v3 APIs (Even the ones we dislike) will not go away
  
 barring a massive security hole, we will not break the API
contracts on V3] (we may add data, we will not remove/restructure
data)
  * If we implement microversions, you may see API changes (similar to
how nova works), but as of today, we do not implement microversions

We have worked with defcore/refstack, qa teams, all services (I think
we missed one, it has since been fixed), clients, SDK(s), etc to
ensure that as much support as possible is in place to make utilizing
V3 easy.

On Fri, Oct 20, 2017 at 3:50 PM, Fox, Kevin M Kevin.Fox@pnnl.gov wrote:
 No, I'm not saying its the TC teams job to bludgeon folks.

 I'm suggesting that some folks other then Keystone should look at the impact of the final removal an api that a lot of external clients may be coded against and since it effects all projects and not just Keystone. And have some say on delaying the final removal if appropriate.

 I personally would like to see v2 go away. But I get that the impact could be far wider ranging and affecting many other teams then just Keystone due to the unique position Keystone is in the architecture. As others have raised.

 Ideally, there should be an OpenStack overarching architecture team of some sort to handle this kind of thing I think. Without such an entity though, I think the TC is probably currently the best place to discuss it though?

 Thanks,
 Kevin
 ________________________________________
 From: Jeremy Stanley [fungi@yuggoth.org]
 Sent: Friday, October 20, 2017 10:53 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0        API removal

 On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:
 [...]

 I know the TC's been shying away from these sorts of questions,
 but this one has a pretty big impact. TC?
 [...]

 The OpenStack Technical Committee isn't really a bludgeon with which
 to beat teams when someone in the community finds fault with a
 decision; it drafts/revises policy and arbitrates disputes between
 teams. What sort of action are you seeking in regard to the Keystone
 team finally acting this cycle on removal of their long-deprecated
 legacy API, and with what choices of theirs do you disagree?

 Do you feel the deprecation was not communicated widely enough? Do
 you feel that SDKs haven't been updated with sufficient support for
 the v3 API? Are you concerned that lack of v2 API support will
 prevent organizations running the upcoming Queens release from
 qualifying for interoperability trademarks? Something else entirely?
 --
 Jeremy Stanley

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


Message: 38
Date: Sat, 21 Oct 2017 11:20:29 +1100
From: Tony Breeds tony@bakeyournoodle.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] [elections] Technical Committee
    Election Results
Message-ID: 20171021002027.GB2430@thor.bakeyournoodle.com
Content-Type: text/plain; charset="utf-8"

Hi All,
    With the election behind us it's somewhat traditional to look at
some simple stats from the elections:

+----------+-----------------------+-------------------+-----------------------+
| Election | Electorate  (delta %) | Voted   (delta %) | Turnout %   (delta %) |
+----------+-----------------------+-------------------+-----------------------+
|  10/2013 |       1106  (    nan) |   342   (    nan) |     30.92   (    nan) |
|  04/2014 |       1510  (  36.53) |   448   (  30.99) |     29.67   (  -4.05) |
|  10/2014 |       1893  (  25.36) |   506   (  12.95) |     26.73   (  -9.91) |
|  04/2015 |       2169  (  14.58) |   548   (   8.30) |     25.27   (  -5.48) |
|  10/2015 |       2759  (  27.20) |   619   (  12.96) |     22.44   ( -11.20) |
|  04/2016 |       3284  (  19.03) |   652   (   5.33) |     19.85   ( -11.51) |
|  10/2016 |       3517  (   7.10) |   801   (  22.85) |     22.78   (  14.71) |
|  04/2017 |       3191  (  -9.27) |   427   ( -46.69) |     13.38   ( -41.25) |
|  10/2017 |       2430  ( -23.85) |   420   (  -1.64) |     17.28   (  29.16) |
+----------+-----------------------+-------------------+-----------------------+

Election CIVS links
 10/2014: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_c105db929e6c11f4
 04/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ef1379fee7b94688
 10/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4ef58718618691a0
 04/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
 10/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010
 04/2017: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_072c4cd7ff0673b5
 10/2017: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae

I don't have a feel for with the Pike electorate decreased but my gut
feel is that it was organic drop-off possibly in part to the shorter
Ocata development cycle.  The Queens drop-off was due to a new1
membership API being available that meant we could validate Foundation
membership instead of using gerrit permission as a proxy.

I'd like to call out that with Pike we had a very dramatic decrease in
voter turnout both in absolute and relative terms.  As a community it's
worth trying to understand whether this is a problem and/or a trend that
needs to change.

Yours Tony.

1 It wasn't that new it was also used during the PTL election[2]
[2] See:
    http://lists.openstack.org/pipermail/openstack-dev/2017-July/119786.html ; and
    http://lists.openstack.org/pipermail/openstack-dev/2017-August/120544.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: 


Message: 39
Date: Fri, 20 Oct 2017 17:21:27 -0700
From: Morgan Fainberg morgan.fainberg@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]
    [keystone][all] v2.0 API removal
Message-ID:
    CAGnj6atmmK6KPhyy-Bvx6JMwNZ9-f0p+Jr_iW-tpUe8ykM_VCg@mail.gmail.com
Content-Type: text/plain; charset="UTF-8"

In addendum, the final v2.0 (EC2-API) path will eventually be removed
(mitaka +7, the "T" release). The v3 versions (where they exist) will
continue to be maintained and not removed.

On Fri, Oct 20, 2017 at 5:16 PM, Morgan Fainberg
morgan.fainberg@gmail.com wrote:
 Let me clarify a few things regarding the V2.0 removal:

 * This has been planned for years at this point. At one time (I am
 looking for the documentation, once I find it I'll include it on this
 thread) we worked with Nova and the TC to set forth a timeline on the
 removal. Part of that agreement was that this was a one-time deal. We
 would remove the V2.0 API in favor of the v3 API but would never
 remove another API going forward.

    A few reasons for removing the V2.0 API that were discussed and
 drove the decision:

    1) The V2.0 API had behavior that was explicitly breaking the security model:

        * A user could authenticate with a scope not the default
 domain) which could lead to oddities in enforcement when using v2.0
 APIs and introduced a number of edge cases. This could not be fixed
 without breaking the V2.0 API contract and every single change to V3
 and features required a lot of time to ensure V2.0 was not breaking
 and had appropriate translations to/from the different data formats.

        * The V2.0 AUTH API included the token (secure) data in the URL
 path, this means that all logs from apache (or other web servers and
 wsgi apps) had to be considered privileged and could not be exposed
 for debugging purposes (and in some environments may not be accessed
 without significant access-controls). This also could not be fixed
 without breaking the V2.0 API contract.

        * The V2.0 policy was effectively hard coded (effectively) to
 use "admin" and "member" roles. Retrofitting the APIs to support fully
 policy was extremely difficult and could break default behaviors
 (easily) in many environments. This was also deemed to be mostly
 unfix-able without breaking the V2.0 API contract.

      In short, the maintenance on V2.0 API was significant, it was a
 lot of work to maintain especially since the API could not receive any
 active development due to lacking basic features introduced in v3.0.
 There were also a significant number of edge cases where v3 had some
 very hack-y support for features (required in openstack services) via
 auth to support the possibility of v2->v3 translations.

    2) V2.0 had been bit rotting. Many items had limited testing and
 were found to be broken. Adding tests that were both V3 and V2.0 aware
 added another layer of difficulty in maintaining the API, much of the
 time we had to spin many new patches to ensure that we didn't break
 v2.0 contracts with a non-breaking v3 change (or in fixing a v2 API
 call, we would be somewhat forced into breaking the API contract).

    3) The Keystone team is acutely aware that this was a painful
 transition and made the choice to drop the API even in that light. The
 choice of "breaking the API contract" a number of times verses
 lightening the developer load (we are strapped for resources working
 on Keystone as are many services, the overhead and added load makes it
 mostly untenable) and do a single (large) change with the
 understanding that V3 APIs cannot be removed was preferable.

 The TC agreed to this removal. The service teams agreed to this
 removal. This was telegraphed as much as we could via deprecation and
 many, many, many discussions on this topic. There really was no good
 solution, we took the solution that was the best for OpenStack in our
 opinion based upon the place where Keystone is.

 We can confidently commit to the following:
    v3 APIs (Even the ones we dislike) will not go away
   
 barring a massive security hole, we will not break the API
 contracts on V3] (we may add data, we will not remove/restructure
 data)
   * If we implement microversions, you may see API changes (similar to
 how nova works), but as of today, we do not implement microversions

 We have worked with defcore/refstack, qa teams, all services (I think
 we missed one, it has since been fixed), clients, SDK(s), etc to
 ensure that as much support as possible is in place to make utilizing
 V3 easy.

 On Fri, Oct 20, 2017 at 3:50 PM, Fox, Kevin M Kevin.Fox@pnnl.gov wrote:

 No, I'm not saying its the TC teams job to bludgeon folks.

 I'm suggesting that some folks other then Keystone should look at the impact of the final removal an api that a lot of external clients may be coded against and since it effects all projects and not just Keystone. And have some say on delaying the final removal if appropriate.

 I personally would like to see v2 go away. But I get that the impact could be far wider ranging and affecting many other teams then just Keystone due to the unique position Keystone is in the architecture. As others have raised.

 Ideally, there should be an OpenStack overarching architecture team of some sort to handle this kind of thing I think. Without such an entity though, I think the TC is probably currently the best place to discuss it though?

 Thanks,
 Kevin
 ________________________________________
 From: Jeremy Stanley [fungi@yuggoth.org]
 Sent: Friday, October 20, 2017 10:53 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0        API removal

 On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:
 [...]

 I know the TC's been shying away from these sorts of questions,
 but this one has a pretty big impact. TC?
 [...]

 The OpenStack Technical Committee isn't really a bludgeon with which
 to beat teams when someone in the community finds fault with a
 decision; it drafts/revises policy and arbitrates disputes between
 teams. What sort of action are you seeking in regard to the Keystone
 team finally acting this cycle on removal of their long-deprecated
 legacy API, and with what choices of theirs do you disagree?

 Do you feel the deprecation was not communicated widely enough? Do
 you feel that SDKs haven't been updated with sufficient support for
 the v3 API? Are you concerned that lack of v2 API support will
 prevent organizations running the upcoming Queens release from
 qualifying for interoperability trademarks? Something else entirely?
 --
 Jeremy Stanley

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


Message: 40
Date: Sat, 21 Oct 2017 00:28:11 +0000
From: "Fox, Kevin M" Kevin.Fox@pnnl.gov
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]
    [keystone][all] v2.0 API removal
Message-ID:
    1A3C52DFCD06494D8528644858247BF01C01A08D@EX10MBOX03.pnnl.gov
Content-Type: text/plain; charset="us-ascii"

Ok. Cool. Didn't know that. Sounds like all due diligence was done then (and maybe plus some :). Thanks for the background info.

Kevin


From: Morgan Fainberg [morgan.fainberg@gmail.com]
Sent: Friday, October 20, 2017 5:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal

Let me clarify a few things regarding the V2.0 removal:

* This has been planned for years at this point. At one time (I am
looking for the documentation, once I find it I'll include it on this
thread) we worked with Nova and the TC to set forth a timeline on the
removal. Part of that agreement was that this was a one-time deal. We
would remove the V2.0 API in favor of the v3 API but would never
remove another API going forward.

   A few reasons for removing the V2.0 API that were discussed and
drove the decision:

   1) The V2.0 API had behavior that was explicitly breaking the security model:

       * A user could authenticate with a scope not the default
domain) which could lead to oddities in enforcement when using v2.0
APIs and introduced a number of edge cases. This could not be fixed
without breaking the V2.0 API contract and every single change to V3
and features required a lot of time to ensure V2.0 was not breaking
and had appropriate translations to/from the different data formats.

       * The V2.0 AUTH API included the token (secure) data in the URL
path, this means that all logs from apache (or other web servers and
wsgi apps) had to be considered privileged and could not be exposed
for debugging purposes (and in some environments may not be accessed
without significant access-controls). This also could not be fixed
without breaking the V2.0 API contract.

       * The V2.0 policy was effectively hard coded (effectively) to
use "admin" and "member" roles. Retrofitting the APIs to support fully
policy was extremely difficult and could break default behaviors
(easily) in many environments. This was also deemed to be mostly
unfix-able without breaking the V2.0 API contract.

     In short, the maintenance on V2.0 API was significant, it was a
lot of work to maintain especially since the API could not receive any
active development due to lacking basic features introduced in v3.0.
There were also a significant number of edge cases where v3 had some
very hack-y support for features (required in openstack services) via
auth to support the possibility of v2->v3 translations.

   2) V2.0 had been bit rotting. Many items had limited testing and
were found to be broken. Adding tests that were both V3 and V2.0 aware
added another layer of difficulty in maintaining the API, much of the
time we had to spin many new patches to ensure that we didn't break
v2.0 contracts with a non-breaking v3 change (or in fixing a v2 API
call, we would be somewhat forced into breaking the API contract).

   3) The Keystone team is acutely aware that this was a painful
transition and made the choice to drop the API even in that light. The
choice of "breaking the API contract" a number of times verses
lightening the developer load (we are strapped for resources working
on Keystone as are many services, the overhead and added load makes it
mostly untenable) and do a single (large) change with the
understanding that V3 APIs cannot be removed was preferable.

The TC agreed to this removal. The service teams agreed to this
removal. This was telegraphed as much as we could via deprecation and
many, many, many discussions on this topic. There really was no good
solution, we took the solution that was the best for OpenStack in our
opinion based upon the place where Keystone is.

We can confidently commit to the following:
   v3 APIs (Even the ones we dislike) will not go away
  
 barring a massive security hole, we will not break the API
contracts on V3] (we may add data, we will not remove/restructure
data)
  * If we implement microversions, you may see API changes (similar to
how nova works), but as of today, we do not implement microversions

We have worked with defcore/refstack, qa teams, all services (I think
we missed one, it has since been fixed), clients, SDK(s), etc to
ensure that as much support as possible is in place to make utilizing
V3 easy.

On Fri, Oct 20, 2017 at 3:50 PM, Fox, Kevin M Kevin.Fox@pnnl.gov wrote:
 No, I'm not saying its the TC teams job to bludgeon folks.

 I'm suggesting that some folks other then Keystone should look at the impact of the final removal an api that a lot of external clients may be coded against and since it effects all projects and not just Keystone. And have some say on delaying the final removal if appropriate.

 I personally would like to see v2 go away. But I get that the impact could be far wider ranging and affecting many other teams then just Keystone due to the unique position Keystone is in the architecture. As others have raised.

 Ideally, there should be an OpenStack overarching architecture team of some sort to handle this kind of thing I think. Without such an entity though, I think the TC is probably currently the best place to discuss it though?

 Thanks,
 Kevin
 ________________________________________
 From: Jeremy Stanley [fungi@yuggoth.org]
 Sent: Friday, October 20, 2017 10:53 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0        API removal

 On 2017-10-20 17:15:59 +0000 (+0000), Fox, Kevin M wrote:
 [...]

 I know the TC's been shying away from these sorts of questions,
 but this one has a pretty big impact. TC?
 [...]

 The OpenStack Technical Committee isn't really a bludgeon with which
 to beat teams when someone in the community finds fault with a
 decision; it drafts/revises policy and arbitrates disputes between
 teams. What sort of action are you seeking in regard to the Keystone
 team finally acting this cycle on removal of their long-deprecated
 legacy API, and with what choices of theirs do you disagree?

 Do you feel the deprecation was not communicated widely enough? Do
 you feel that SDKs haven't been updated with sufficient support for
 the v3 API? Are you concerned that lack of v2 API support will
 prevent organizations running the upcoming Queens release from
 qualifying for interoperability trademarks? Something else entirely?
 --
 Jeremy Stanley

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


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

Message: 41
Date: Fri, 20 Oct 2017 21:08:51 -0500
From: "Cody A.W. Somerville" cody.somerville@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Fwd: [Openstack-operators][tc]
    [keystone][all] v2.0 API removal
Message-ID:
    CAF=aq-hxBnDazHri_LzRieGcJA59g0FvV9Z50kfOykEGWNf7Ng@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

On Fri, Oct 20, 2017 at 7:16 PM, Morgan Fainberg morgan.fainberg@gmail.com
wrote:

 Let me clarify a few things regarding the V2.0 removal:

 * This has been planned for years at this point. At one time (I am
 looking for the documentation, once I find it I'll include it on this
 thread) we worked with Nova and the TC to set forth a timeline on the
 removal. Part of that agreement was that this was a one-time deal. We
 would remove the V2.0 API in favor of the v3 API but would never
 remove another API going forward.

Glad to hear this. Does this apply to all projects? Deprecation and removal
of API versions or versions of features (especially before new version of
feature has parity and proven scale to older version of feature) has been a
pain point for large production public clouds in terms of keeping in sync
with upstream which then adversely affects the ability of that organization
to contribute back to upstream due to having to stay on older versions. It
can quickly become too painful, risky, and costly to ever reconcile
eventually leading to the organization no longer meaningful contributing to
projects where they've drifted too far all together. I consider this
scenario to be very unfortunate for the customer's of that public cloud as
well as the OpenStack project itself.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 42
Date: Fri, 20 Oct 2017 23:06:28 -0700
From: Michał Jastrzębski inc007@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO][Kolla] Concerns about
    containers images in DockerHub
Message-ID:
    CALc0zUBhpO18m5XLospXpNKRmVsxBDXTepyMuSNARhb=0kV6fQ@mail.gmail.com
Content-Type: text/plain; charset="utf-8"

Additionally you can build only images you need. Some of images we have are
quite.. niche. If you limit number of images to only those you care about,
that will lower total size significantly

On Oct 20, 2017 3:51 PM, "Steven Dake (stdake)" stdake@cisco.com wrote:

 Sam,

 Agreed this matches my experience. Building one by one though will result
 in massive image size sprawl.

 Regards

 -steve

 From: Sam Yaple samuel@yaple.net
 Reply-To: "sam@yaple.net" sam@yaple.net, "OpenStack Development
 Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org
 >
 Date: Thursday, October 19, 2017 at 10:37 PM
 To: Gabriele Cerami gcerami@redhat.com
 Cc: "OpenStack Development Mailing List (not for usage questions)" <
 openstack-dev@lists.openstack.org>
 Subject: Re: [openstack-dev] [TripleO][Kolla] Concerns about containers
 images in DockerHub

 On Thu, Oct 19, 2017 at 11:23 PM, Gabriele Cerami gcerami@redhat.com
 wrote:

 On 19 Oct, Sam Yaple wrote:
 > So it seems tripleo is building all images and then pushing them.
 > Reworking your number leads me to believe you will be consuming 10-15GB
 in
 > total on Dockerhub. Kolla images are only the size that you posted when
 > built as seperate services. Just keep building all the images at the same
 > time and you wont get anywhere near the numbers you posted.

 Makes sense, so considering the shared layers
 - a size of 10-15GB per build.
 - 4-6 builds rotated per release
 - 3-4 releases

 - a size of 1-2GB per build

 - 4-6 builds rotated per release

 - 3-4 releases

 At worst you are looking at 48GB not 360GB. Dont worry so much there!

 total size will be approximately be 360GB in the worst case, and 120GB in
 the best case, which seems a bit more reasonable.

 Thanks for he clarifications

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 


Message: 43
Date: Sat, 21 Oct 2017 01:00:10 -0600
From: Diana Clarke diana.joan.clarke@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc][election] Question for candidates:
    How do you think we can make our community more inclusive?
Message-ID:
    CAEZAPrCiNHTN96-9U6O67O_ikf-aX4vPgBFjCRWRGfSPiF-Bug@mail.gmail.com
Content-Type: text/plain; charset="UTF-8"

Congrats on being elected to the TC, Colleen!

You mentioned earlier in this thread that, "a major problem in the
tech world is not just attracting underrepresented contributors, but
retaining them".

I'm curious if the TC has considered polling the people that have left
OpenStack for their experiences on this front.

Something along the lines of:

    "I see you contributed 20 patches in the last cycle, but haven't
contributed recently, why did you stop contributing?".

Given the recent layoffs, I suspect many of the responses will be
predicable, but you might find some worthwhile nuggets there
nonetheless.

Congrats again,

--diana

On Sun, Oct 15, 2017 at 3:38 AM, Colleen Murphy colleen@gazlene.net wrote:
 A major problem in the tech world is not just attracting underrepresented
 contributors, but retaining them. They leave their communities or careers
 because of bias problems. To my knowledge, that doesn't happen in OpenStack,
 but just because I can't see it doesn't mean it's not there. A long-term
 study of participation by underrepresented demographics will help us answer
 this and fix it if necessary.


Message: 44
Date: Sat, 21 Oct 2017 15:40:49 +0800
From: Fred Li yongle.li@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
    openstack-dev@lists.openstack.org
Subject: [openstack-dev] OpenStack Bug Smash for Queens
Message-ID:
    CAC0=-7WKWcL_+K3SNiL2bqRL_TMK3PMLa7uuP8eq=vMAJ1r6Sw@mail.gmail.com
Content-Type: text/plain; charset="UTF-8"

Hi all OpenStackers,

Since April 2015, there have been 6 OpenStack Bug Smash events in
China. OpenStack Bug Smash has been a routine and exciting event by
OpenStacker expects. In the past 5 bug smashes, over 300 top
developers from many companies(Huawei,Intel,CMCC, IBM, Mirantis,
Awcloud, 99cloud, UnitedStack, EasyStack, LeTV, ZTE, and etc.)
contributed 600+ bugs to community. This achievement significantly
demonstrated the technical strength of Chinese engineers. Huawei,
Intel and those companies show the commitment of OpenStack Stability
to enterprise customers.

Now, the 7th OpenStack bug smash is coming. Intel, Huawei, Fiberhome
and CESI will host this event. Intel, Huawei and Fiberhome are all
OpenStack members1.
Come to join other OpenStackers to make Queens a grand success!
Come to learn tips and gain a better understanding by working closely
with other talents.
Each focused project will have a core on standby to review patches and
vote for merges.

Queens Bug SmashObject: smash the critical and high bugs in key
projects. Focused projects: Nova, Neutron, Cinder, Keystone, Manila,
Heat, Telemetry, Karbor, Tricircle, and the ones you want to add.

To all the projects team leaders, you can discuss with your team
members in the project meeting and mark the bugs you expect OpenStack
Bug Smash Queens to fix. If you can arrange core reviewers to take
care of the patches during that week, that will be more efficient.

Date: from Nov 22 to Nov 24, which is 2 weeks prior to Queens-2 milestone[2].

Location: 中国湖北省武汉市洪山区邮科院路88号,烽火创新谷武汉国际创客中心五楼一号会议室 [3]

Please start to register in [4].
And start to list the bugs to be fixed in [5].

1 https://www.openstack.org/foundation/companies/
[2] https://releases.openstack.org/queens/schedule.html
[3] https://www.google.co.jp/maps/place/88+You+Ke+Yuan+Lu,+GuangGu+ShangQuan,+Hongshan+Qu,+Wuhan+Shi,+Hubei+Sheng,+China,+430073/@30.5107646,114.392814,17z/data=!3m1!4b1!4m5!3m4!1s0x342ea4ce1537ed17:0x52ff45d6b5dba38c!8m2!3d30.51076!4d114.395008?hl=en
[4] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Queens-Wuhan
[5] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Queens-Wuhan-Bugs-List

Regards
Fred Li (李永乐)


Subject: Digest Footer


OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

End of OpenStack-dev Digest, Vol 66, Issue 36



responded Oct 23, 2017 by zhang.yanxian_at_zte (140 points)  
Drop us a note if you have suggestions on other community mailing lists that should be made searchable here.

For the corporate mailing lists, visit nimeyo.com or send a note here

31,319 questions

91,190 responses

13 comments

5,642 users

...