Re: [openstack-dev] [oslo] pbr and warnerrors status

[Andreas Jaeger]

On 2017-02-08 00:56, Ian Cordasco  wrote:
> 
> 
> On Feb 7, 2017 5:47 PM, "Joshua Harlow"  > wrote:
> 
> Likely just never pulled the trigger.
> 
> Seems like we should pull it though.
> 
> 
> 
> Will have to wait until Pike given the library release freeze

I've pushed a patch to release pbr so that we won't forget about it:

https://review.openstack.org/430618

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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

[openstack-dev] [tripleo] Blueprints for DPDK in OvS2.6

[Saravanan KR]

Hello,

We have raised 2 BP for OvS2.6 integration with DPDK support.

Basic Migration -
https://blueprints.launchpad.net/tripleo/+spec/ovs-2.6-dpdk (Targeted
for March)
OvS 2.6 Features -
https://blueprints.launchpad.net/tripleo/+spec/ovs-2.6-features-dpdk
(Targeted for Pike)

We find the changes to be straight forward and minor. And the required
changes has been updated on the BP description. Please let us know if
it requires a spec.

Regards,
Saravanan KR

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

Re: [openstack-dev] [neutron][taas] ocata

[Soichi Shigeta]

 Hi Yamamoto,

   We discussed this on today's IRC and agreed to make an ocata release.

   Best regards,
   Soichi




tap-as-a-service folks,

unless anyone objects, i'll make a ocata release and thus stable
branch this week.
(otherwise the CI of consuming subprojects will break)

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




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

[openstack-dev] [tricircle]weekly meeting of Feb. 8

[joehuang]

Hello, team,

Let's resume weekly meeting after breaks for Chinese New Year.

Agenda of Feb. 8 weekly meeting:

  1.  Ocata release dates
  2.  Pike meetup before PTG: 
https://etherpad.openstack.org/p/tricircle-pike-design-topics
  3.  Representative and topics to PTG
  4.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 13:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

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

[openstack-dev] [Blazar] bug list before next release

[Masahito MUROI]

Hello Blazar folks,

I listed all tasks needed to do by 0.2.0 release. Let's pick up bugs and  
don't forget to add you as an Assignee.


https://launchpad.net/blazar/+milestone/0.2.0

best regards,
Masahito



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

Re: [openstack-dev] [release][oslo] recreating the stable/ocata branch for mox3

[ChangBo Guo]

Thanks Doug and amoralej,  we should avoid this :(．

One more thought about mox3: Is it used outside of OpenStack? If yes,
Maybe we can retire mox3 if all projects move mox to mock.



2017-02-07 23:00 GMT+08:00 Doug Hellmann :

> The stable/ocata branch for mox3 was created from 0.19.0 and then 0.20.0
> was released from master. Because that repository sees a very low rate
> of changes, and because the current stable/ocata branch only contained
> the patch to update the .gitreview file, we decided to recreate the
> branch to accurately reflect the intent of having 0.20.0 be part of the
> ocata series of releases.
>
> https://review.openstack.org/430283
>
> Thanks go to amoralej for pointing out the issue today.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] Refstack - final mascot

[Rochelle Grober]

Looks great to me.

--Rocky

From: Catherine Cuong Diep [mailto:cd...@us.ibm.com]
Sent: Monday, February 06, 2017 4:25 PM
To: OpenStack Dev Mailer 
Subject: [openstack-dev] Refstack - final mascot


Hello RefStack team,

Please see RefStack mascot in Heidi's note below.

Catherine Diep
- Forwarded by Catherine Cuong Diep/San Jose/IBM on 02/06/2017 04:18 PM 
-

From: Heidi Joy Tretheway 
mailto:heidi...@openstack.org>>
To: Catherine Cuong Diep/San Jose/IBM@IBMUS
Date: 02/02/2017 11:42 AM
Subject: Refstack - final mascot





Hi Catherine,

I have a new revision from our illustration team for your team’s project 
mascot. We’re pushing hard to get all 60 of the mascots finalized by the PTG, 
so I’d love any feedback from your team as swiftly as possible. As a reminder, 
we can’t change the illustration style (since it’s consistent throughout the 
full mascot set) and so we’re just looking for problems with the creatures. 
Could you please let me know if your team has any final concerns?

Thank you!

[cid:image001.png@01D28171.0E28D410]




Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769 | Skype: 
heidi.tretheway




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

[openstack-dev] [tricircle]Ocata branch creation

[joehuang]

Hello,

Tricircle Ocata branch will be created after these two patches are merged 
before this Friday:

1. https://review.openstack.org/#/c/429457/
2. https://review.openstack.org/#/c/424601/

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

Re: [openstack-dev] [tricircle] Example EVPN question/use-case

[joehuang]

Hello, Curtis and Greg,

This is a quite good use case. Thanks for the sharing.

Tricircle is working on VxLAN based L2 network across OpenStack clouds for 
different backends (non-SDN, SDN, L2 GW or non L2 GW). The spec is in review: 
https://review.openstack.org/#/c/429155/.

Currently only SDN controllers which can support using BGP to exchange 
tunneling endpoint information is considered. It's worth to take this use case 
into consideration.

Please join the review and give your comments, thanks.

Best Regards
Chaoyi Huang (joehuang)


From: Curtis [serverasc...@gmail.com]
Sent: 08 February 2017 1:49
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tricircle] Example EVPN question/use-case

Hi,

I'm not sure if this is useful at all, but there is a blog post [1]
from one of the people behind the PacketPushers podcast regarding
connecting two OpenStack clouds with a EVPN. They are wondering how to
do it.

They want to connect an NSX based cloud with a OpenContrail based
cloud and do it at very high speeds. Interesting use case, real world.

Thanks,
Curtis.

[1]: 
http://etherealmind.com/help-wanted-stitching-a-federated-sdn-on-openstack-with-evpn/

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

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

Re: [openstack-dev] [requirements] [Horizon][Karbor][Magnum] Requesting FFE for xstatic packages

[Richard Jones]

It looks like Magnum-UI only has one xstatic package in their
requirements that isn't already in Horizon's requirements (and
therefore is superfluous), and that's xstatic-magic-search, which has
been replaced in Horizon by pulling magic search into the Horizon tree
(we forked because maintaining our own extensions against the package
was getting out of hand - we'd basically rewritten a large proportion
of the code).

I would recommend that the Magnum-UI project remove all xstatic
packages from requirements.txt


Richard

On 7 February 2017 at 14:17, Tony Breeds  wrote:
> On Tue, Feb 07, 2017 at 10:39:41AM +1100, Richard Jones wrote:
>> Hi requirements team,
>>
>> We've had a downstream packager come to us with issues packaging the
>> Horizon RC as described in this bug report:
>>
>>  https://bugs.launchpad.net/horizon/+bug/1662180
>>
>> The issues stems from the requirements file having several xstatic
>> package minimum versions specified that are no longer compatible with
>> Horizon, and the RDO build system honors those minimum version
>> specifications, and boom!
>
> This is a specific case of OpenStack provides poor tools for 
> testing/validating
> minimum requirements.  This is a thing we started trying to fix in Ocata but
> the work is slow going :(   I'm a little confused how this wasn't caught 
> sooner
> by RDO (given they would appear to have been testing the minimums for 
> xstatic-*)
>
>> Rob Cresswell has proposed a patch to bump those minimum versions up
>> to the versions specified in upper-constraints.txt:
>>
>>   https://review.openstack.org/#/c/429753
>
> That review seems to adjust all Xstatic packages where the minimu != the
> constrained version which is probably more than is required but it doesn't
> actually increase the knock-on effects so it seems like a good idea to me :)
>
> Looking at the projects that are affected by Rob's review:
>
> Package  : xstatic-angular [xstatic-angular>=1.3.7] (used by 3 projects)
> Package  : xstatic-angular-bootstrap 
> [xstatic-angular-bootstrap>=0.11.0.2] (used by 3 projects)
> Package  : xstatic-angular-gettext [xstatic-angular-gettext>=2.1.0.2] 
> (used by 3 projects)
> Package  : xstatic-bootstrap-scss [xstatic-bootstrap-scss>=3.1.1.1] (used 
> by 3 projects)
> Package  : xstatic-d3 [xstatic-d3>=3.1.6.2] (used by 3 projects)
> Package  : xstatic-font-awesome [xstatic-font-awesome>=4.3.0] (used by 3 
> projects)
> Package  : xstatic-jasmine [xstatic-jasmine>=2.1.2.0] (used by 3 projects)
> Package  : xstatic-jsencrypt [xstatic-jsencrypt>=2.0.0.2] (used by 3 
> projects)
> Package  : xstatic-rickshaw [xstatic-rickshaw>=1.5.0] (used by 3 projects)
> Package  : xstatic-smart-table [xstatic-smart-table!=1.4.13.0,>=1.4.5.3] 
> (used by 3 projects)
> Package  : xstatic-term-js [xstatic-term-js>=0.0.4.1] (used by 3 projects)
> openstack/horizon [tc:approved-release]
> openstack/karbor-dashboard[]
> openstack/magnum-ui   []
>
>
> Package  : xstatic-bootswatch [xstatic-bootswatch>=3.3.5.3] (used by 1 
> projects)
> openstack/horizon [tc:approved-release]
>
> And obviously RDO
>
> This will mean that Horizon will need an RC2, and any packaging/distro testing
> for horizon (and plugins/dashboards) will need to be restarted (iff said
> testing was done with an xstatic package not listed in 
> upper-constraaints.txt[1])
>
> I tried to determine the impact on magnum-ui and karbor-dashboard and AFAICT
> they're already using constraints.  The next thing to look at is the release
> model which is:
> magnum-ui:
>  type: horizon-plugin
>  model: cycle-with-intermediary
> karbor-dashboard:
>  type:  unknown
>  model: unknown
>
> I think this means it's safe grant this FFE as the affected plugins aren't
> necessarily in a stabilisation phase.
>
> So as far as I can see we have 2 options:
> 1. Do nothing: there will be other cases that minimums are not functional.
>RDO have tools and data to fix this in there own repos so we're not
>actually blocking them
> 2. Take the patch, and accept the knock on effects.
>
> I'm okay with taking this FFE if Karbor and Magnum PTLs sign off here (or on 
> the review)
>
>> Additionally to the above I will be proposing a patch to Horizon's
>> documented processes to ensure that when an xstatic upper-constraints
>> version is bumped we also bump the minimum version in
>> global-requirements to avoid this sort of thing in the future.
>
> Cool.  That'll help
>
> Yours Tony.
>
> [1] We've communicated that u-c should be the source here before
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

[openstack-dev] [all][elections] Project Team Lead Election Conclusion and Results

[Kendall Nelson]

Thank you to the electorate, to all those who voted and to all
candidates who put their name forward for Project Team Lead (PTL) in
this election. A healthy, open process breeds trust in our decision
making capability thank you to all those who make this process
possible.

Now for the results of the PTL election process, please join me in
extending congratulations to the following PTLs!

 * Barbican  : Dave McCowan
 * Chef OpenStack: Jan Klare
 * Cinder: Sean McGinnis
 * Cloudkitty: Christophe Sauthier
 * Community App Catalog : Matthew Wagoner
 * Congress  : Eric K
 * Designate : Tim Simmons
 * Documentation : Alexandra Settle
 * Dragonflow: Omer Anson
 * Ec2 Api   : Alexandre Levine
 * Freezer   : Saad Zaher
 * Fuel  : Vladimir Kuklin
 * Glance: Brian Rosmaita
 * Heat  : Rico Lin
 * Horizon   : Rob Cresswell
 * I18n  : Ian Y. Choi
 * Infrastructure: Jeremy Stanley
 * Ironic: Dmitry Tantsur
 * Karbor: Yuval Brik
 * Keystone  : Lance Bragstad
 * Kolla : Michal Jastrzebski
 * Kuryr : Antoni Segura Puimedon
 * Magnum: Adrian Otto
 * Manila: Ben Swartzlander
 * Mistral   : Renat Akhmerov
 * Monasca   : Roland Hochmuth
 * Murano: Felipe Monteiro
 * Neutron   : Kevin Benton
 * Nova  : Matt Riedemann
 * Octavia   : Michael Johnson
 * OpenStackAnsible  : Andy McCrae
 * OpenStackClient   : Dean Troyer
 * OpenStack Charms  : James Page
 * Oslo  : ChangBo Guo
 * Packaging Deb : Thomas Goirand
 * Packaging Rpm : Igor Yozhikov
 * Puppet OpenStack  : Alex Schultz
 * Quality Assurance : Andrea Frittoli
 * Rally : Andrey Kurilin
 * RefStack  : Catherine Diep
 * Release Management: Thierry Carrez
 * Requirements  : Tony Breeds
 * Sahara: Telles Mota Vidal Nóbrega
 * Searchlight   : Steve McLellan
 * Security  : Robert Clark
 * Senlin: Qiming Teng
 * Solum : Devdatta-kulkarni Devdatta-kulkarni
 * Stable Branch Maintenance : Tony Breeds
 * Storlets  : Eran Rom
 * Swift : John Dickinson
 * Tacker: Gongysh Gongysh
 * Telemetry : Julien Danjou
 * Tricircle : Chaoyi Huang
 * Tripleo   : Emilien Macchi
 * Trove : Amrith Amrith
 * Vitrage   : Ifat Afek
 * Watcher   : Alexander Chadin
 * Winstackers   : Claudiu Belu
 * Zaqar : Fei Long Wang
 * Zun   : Hongbin Lu

Elections:
* Ironic: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_08ff4080d37365ba
* Keystone: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_1d2eef76fdfc1ec4
* Neutron: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_6df9c8e056680402
* Quality_Assurance:
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_99413ba03ba1c6b3
* Stable_Branch_Maintenance:
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_b719c6a5a681033b

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

Thank you to all involved in the PTL election process,

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

Re: [openstack-dev] [oslo] pbr and warnerrors status

[Ian Cordasco]

On Feb 7, 2017 5:47 PM, "Joshua Harlow"  wrote:

Likely just never pulled the trigger.

Seems like we should pull it though.



Will have to wait until Pike given the library release freeze
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] pbr and warnerrors status

[Joshua Harlow]

Likely just never pulled the trigger.

Seems like we should pull it though.

-Josh

Ben Nemec wrote:

Someone just spent a bunch of effort fixing all the warnings in our docs
project and I'd like to turn on warnerrors so we keep it that way.
Unfortunately, I discovered that warnerrors is still not effective in
setup.cfg.

After digging a little more, I see we never released pbr after the
discussion in
http://lists.openstack.org/pipermail/openstack-dev/2016-June/097849.html
The last release is 1.10, which doesn't include the fix. Was there a
reason for this, or did we just never pull the trigger on the release?

Thanks.

-Ben

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


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

[openstack-dev] [oslo] pbr and warnerrors status

[Ben Nemec]

Someone just spent a bunch of effort fixing all the warnings in our docs 
project and I'd like to turn on warnerrors so we keep it that way. 
Unfortunately, I discovered that warnerrors is still not effective in 
setup.cfg.


After digging a little more, I see we never released pbr after the 
discussion in 
http://lists.openstack.org/pipermail/openstack-dev/2016-June/097849.html 
 The last release is 1.10, which doesn't include the fix.  Was there a 
reason for this, or did we just never pull the trigger on the release?


Thanks.

-Ben

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

[openstack-dev] [tacker] Tacker Mascot

[Sridhar Ramaswamy]

Tackers,

I received a draft version of our project logo, using the mascot we
selected together. A final version will be ready for us before the Project
Team Gathering in February. Before they make our logo final, they want to
be sure we're happy with our mascot.

Let me know if anyone have suggestions to change. We can briefly discuss
this in our meeting today.

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

[openstack-dev] [fuel][release] Opting out of Ocata?

[Davanum Srinivas]

Dear Fuel Team,

There have been no releases for fuel-* projects in the Ocata time frame:
https://git.openstack.org/cgit/openstack/releases/tree/deliverables/ocata

Fuel projects under governance are supposed to be following the
"cycle-trailing" schedule:
https://releases.openstack.org/reference/release_models.html#cycle-trailing

Please see Ocata schedule:
https://releases.openstack.org/ocata/schedule.html#o-trailing

Is anyone still around keeping the lights on?

Thanks,
Dims

-- 
Davanum Srinivas :: https://twitter.com/dims

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

[openstack-dev] [manila] manila 4.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for manila for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/manila/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:

http://git.openstack.org/cgit/openstack/manila/log/?h=stable/ocata

Release notes for manila can be found at:

http://docs.openstack.org/releasenotes/manila/



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

[openstack-dev] [Congress] PTG Activities options

[Tim Hinrichs]

Hi all,

At the last IRC I volunteered to pick out a couple of group activities for
the upcoming PTG.  First cut is below.  I could imagine dinner, an outing,
or both.

Restaurants
---
Two options jumped out at me.  If neither of these seems good I can keep
looking.

1. Desta Ethiopian Kitchen
# 10 on Trip Advisor
Ethiopian
20 min drive
Vegetarian-friendly
https://www.tripadvisor.com/Restaurant_Review-g60898-d1597692-Reviews-Desta_Ethiopian_Kitchen-Atlanta_Georgia.html

2. R. Thomas Deluxe Grill
#185 on TripAdvisor
American; large menu; "visually stimulating" restaurant
12 min drive
Vegetarian-friendly
https://www.tripadvisor.com/Restaurant_Review-g60898-d435430-Reviews-R_Thomas_Deluxe_Grill-Atlanta_Georgia.html

Outings
--
1. Botanical gardens
# 3 on TripAdvisor
13 min drive
open 9a-5p
https://www.tripadvisor.com/Attraction_Review-g60898-d104713-Reviews-Atlanta_Botanical_Garden-Atlanta_Georgia.html

2. Aquarium
#1 on TripAdvisor
1 mile from PTG hotel
open 10a-5p
https://www.tripadvisor.com/Attraction_Review-g60898-d588792-Reviews-Georgia_Aquarium-Atlanta_Georgia.html

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

Re: [openstack-dev] [all][api] POST /api-wg/news

[Everett Toews]

On Feb 6, 2017, at 3:28 PM, Ken'ichi Ohmichi 
mailto:ken1ohmi...@gmail.com>> wrote:

2017-02-06 6:45 GMT-08:00 Brian Rosmaita 
mailto:rosmaita.foss...@gmail.com>>:
On 2/6/17 5:51 AM, Jordan Pittier wrote:
[super-enormous snip -- Chris, Ken, and Jordan make good points, I
encourage you to read the entire thread; I just want to concentrate on
one point]

I would say we should make compromise, not solve dilemma. I can live in a
world where we sometimes allow an API change and sometimes prevent it.

+1000

I agree with Jordan.  We need to look at the context of each specific
case and decide whether a change is OK based on the details.  We've
already got the guideline that says "in general", you shouldn't change
the response code, and we respect that.  The Glance team isn't claiming
that the guideline is incorrect--we're just saying that given the
context of this specific bug (that is, it's been documented for a long
time to return a 204, all other metadefs DELETE calls are documented to
return a 204, all the other metadefs DELETE calls do in fact return a
204, etc.), it makes sense that this case is an exception.

Granting an exception here doesn't mean that the floodgates have opened
for an "anything goes" approach to API changes.  It just means that an
exception is appropriate in this particular case.  I am being a bit
disingenuous there because if an exception is appropriate in this case,
then it will be appropriate in other relevantly similar cases.  But
"relevant similarity" will include the entire context of the case, for
example, whether there was a published API contract, whether the other
similar calls behave as documented, etc.  From 10,000 meters, it looks
like what we're advocating is "It's OK to change a response code".  But
when you look more closely, our claim is that given the details of this
particular bug, it makes sense to fix it in the code and not in the docs.

To summarize, my point is that we shouldn't be worried that this case is
going to set a precedent.  It would be worrisome if it were going to set
a *bad* precedent, but when you look at the details of the situation, I
don't think it will.  So it looks to me, anyway, that a compromise is in
order here.  (In case I'm being too obscure, what I mean is: we should
agree that it's OK for the Glance team to fix this bug in the code with
patch https://review.openstack.org/#/c/420038/.)

I feel this case is very common case when we want to chang success status code.
Because I cannot find the other motivation for changing success status
code except we are finding bugs like this case.

So if accepting this case, I guess we drop the following guideline completely[1]

 The following types of changes are generally *not* considered acceptable:
  Changing which response code is returned on success.

This isn't an all or nothing proposition and I don't think it needs to be 
dropped completely. Members of an OpenStack project that want to adhere to the 
guidelines can use their judgement and take the guidance, that those types of 
changes are generally not considered acceptable, into account.

Each and every OpenStack project are themselves responsible for providing a 
good UX for their users. They need to be willing to fix genuine code bugs in 
order to improve that UX. Human judgement is used to define "genuine" in this 
case.

If they become unwilling to fix bugs because it changes some aspect of the UX 
(the API in this case) and users have to react to that change then we'll 
eventually be left with a bug-ridden foundation. I abhor backwards incompatible 
changes as much as the next dev but building on buggy code is the worst UX of 
all. (Yes, I'm the one who made the Internet Explorer analogy.)

Discussion over this particular issue is helping us form the guideline. But 
please note how I specified "Members of an OpenStack project" above. I want to 
make it clear that it is not the API WG's role to adjudicate on particular 
issues. The API WG can offer opinions, clarify the intention of a guideline, 
adjust guidelines if they're not clear, etc. The responsibility lies with the 
project to make good decisions for their users.

Regards,
Everett


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

Re: [openstack-dev] [all][api] POST /api-wg/news

[Ken'ichi Ohmichi]

2017-02-07 10:31 GMT-08:00 Ed Leafe :
> On Feb 6, 2017, at 3:28 PM, Ken'ichi Ohmichi  wrote:
>>
>>> To summarize, my point is that we shouldn't be worried that this case is
>>> going to set a precedent.  It would be worrisome if it were going to set
>>> a *bad* precedent, but when you look at the details of the situation, I
>>> don't think it will.  So it looks to me, anyway, that a compromise is in
>>> order here.  (In case I'm being too obscure, what I mean is: we should
>>> agree that it's OK for the Glance team to fix this bug in the code with
>>> patch https://review.openstack.org/#/c/420038/.)
>>
>> I feel this case is very common case when we want to chang success status 
>> code.
>> Because I cannot find the other motivation for changing success status
>> code except we are finding bugs like this case.
>
> Success codes are different than failure codes, because when you fail, you 
> need to know why. When your request succeeds, that’s pretty much all you need 
> to know. So the pain involved should be much less.
>
> But aside from this particular case, there are a lot of differing opinions on 
> how APIs should be treated, so I wrote up my take on things:
>
> https://blog.leafe.com/api-longevity/
>
>> So if accepting this case, I guess we drop the following guideline 
>> completely[1]
>>
>>  The following types of changes are generally *not* considered acceptable:
>>   Changing which response code is returned on success.
>
> I’ll propose a change to the wording for that, but dropping the guideline 
> completely would be an overreaction, IMO.

I am not sure what you mean, I feel you are saying it is meaningless
to specify particular success status code on each API..
One my stupid idea is it is good to specify HTTP200 only on all APIs
on the guideline.
It would be easy to make APIs consistent and avoid this kind of bugs.
I know many people don't prefer this idea ;)

Thanks
Ken Ohmichi

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

Re: [openstack-dev] [all][api] POST /api-wg/news

[Ken'ichi Ohmichi]

2017-02-07 6:56 GMT-08:00 Brian Rosmaita :
> On 2/6/17 4:28 PM, Ken'ichi Ohmichi wrote:
>> 2017-02-06 6:45 GMT-08:00 Brian Rosmaita :
>>> On 2/6/17 5:51 AM, Jordan Pittier wrote:
>>> [super-enormous snip -- Chris, Ken, and Jordan make good points, I
>>> encourage you to read the entire thread; I just want to concentrate on
>>> one point]

 I would say we should make compromise, not solve dilemma. I can live in a
 world where we sometimes allow an API change and sometimes prevent it.

>>> +1000
>>>
>>> I agree with Jordan.  We need to look at the context of each specific
>>> case and decide whether a change is OK based on the details.  We've
>>> already got the guideline that says "in general", you shouldn't change
>>> the response code, and we respect that.  The Glance team isn't claiming
>>> that the guideline is incorrect--we're just saying that given the
>>> context of this specific bug (that is, it's been documented for a long
>>> time to return a 204, all other metadefs DELETE calls are documented to
>>> return a 204, all the other metadefs DELETE calls do in fact return a
>>> 204, etc.), it makes sense that this case is an exception.
>>>
>>> Granting an exception here doesn't mean that the floodgates have opened
>>> for an "anything goes" approach to API changes.  It just means that an
>>> exception is appropriate in this particular case.  I am being a bit
>>> disingenuous there because if an exception is appropriate in this case,
>>> then it will be appropriate in other relevantly similar cases.  But
>>> "relevant similarity" will include the entire context of the case, for
>>> example, whether there was a published API contract, whether the other
>>> similar calls behave as documented, etc.  From 10,000 meters, it looks
>>> like what we're advocating is "It's OK to change a response code".  But
>>> when you look more closely, our claim is that given the details of this
>>> particular bug, it makes sense to fix it in the code and not in the docs.
>>>
>>> To summarize, my point is that we shouldn't be worried that this case is
>>> going to set a precedent.  It would be worrisome if it were going to set
>>> a *bad* precedent, but when you look at the details of the situation, I
>>> don't think it will.  So it looks to me, anyway, that a compromise is in
>>> order here.  (In case I'm being too obscure, what I mean is: we should
>>> agree that it's OK for the Glance team to fix this bug in the code with
>>> patch https://review.openstack.org/#/c/420038/.)
>>
>> I feel this case is very common case when we want to chang success status 
>> code.
>> Because I cannot find the other motivation for changing success status
>> code except we are finding bugs like this case.
>>
>> So if accepting this case, I guess we drop the following guideline 
>> completely[1]
>>
>>   The following types of changes are generally *not* considered acceptable:
>>Changing which response code is returned on success.
>
> I think that's a separate discussion that shouldn't hold up whether we
> can get this particular bug properly fixed soon.
>
> It doesn't follow that if Glance makes this change, the guideline is
> pointless.  As I said earlier, given the context of this particular bug
> (the success code for the call has been documented as a 204, all the
> other metadefs DELETE calls return a 204, all the other calls are also
> documented to return 204s, etc.), one can argue that this is a
> legitimate exception allowed under the guideline.  And in fact the API
> Working Group has accepted that argument.  If the facts of the case were
> different, they might very well have told me to go boil my head.
>
> My point here is that we can accept the guideline *and* also accept this
> particular change.  Hence, worrying about the status of the guideline is
> not a reason to reject the fix proposed by the patch
> https://review.openstack.org/#/c/420038/ .

Again, this case is not particular case. Very common case.
It was just forgot to specify status code (204 in this case) in the
code, and the wsgi framework returns 200 as the default.
Nova also has multiple same bugs on the API, so I feel this is common case.

My point is "Do we really need to do that ?" with
- Possible to break the existing users APIs
- Break the OpenStack interoperability on multiple different version clouds
- Make the guideline fuzzy when facing the smiler issues

only for us, developers.

Thanks
Ken Ohmichi

---

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

[openstack-dev] DEADLINE EXTENDED––CFP for Openstack Summit Boston

[Erin Disney]

Huge thanks to everyone who has already submitted presentations for the 
upcoming OpenStack Summit in Boston. Great news for those that missed the 
deadline last night––we will now be accepting submissions until February 8th at 
11:59pm PST (February 9th at 7:59 UTC)!

You can submit/edit presentations HERE 
 up until 
the deadline, please send any questions to speakersupp...@openstack.org 
. 

Registration and discounted hotel block information available here 
 for your reference.  

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

Re: [openstack-dev] [all][api] POST /api-wg/news

[Ed Leafe]

On Feb 6, 2017, at 3:28 PM, Ken'ichi Ohmichi  wrote:
> 
>> To summarize, my point is that we shouldn't be worried that this case is
>> going to set a precedent.  It would be worrisome if it were going to set
>> a *bad* precedent, but when you look at the details of the situation, I
>> don't think it will.  So it looks to me, anyway, that a compromise is in
>> order here.  (In case I'm being too obscure, what I mean is: we should
>> agree that it's OK for the Glance team to fix this bug in the code with
>> patch https://review.openstack.org/#/c/420038/.)
> 
> I feel this case is very common case when we want to chang success status 
> code.
> Because I cannot find the other motivation for changing success status
> code except we are finding bugs like this case.

Success codes are different than failure codes, because when you fail, you need 
to know why. When your request succeeds, that’s pretty much all you need to 
know. So the pain involved should be much less.

But aside from this particular case, there are a lot of differing opinions on 
how APIs should be treated, so I wrote up my take on things:

https://blog.leafe.com/api-longevity/

> So if accepting this case, I guess we drop the following guideline 
> completely[1]
> 
>  The following types of changes are generally *not* considered acceptable:
>   Changing which response code is returned on success.

I’ll propose a change to the wording for that, but dropping the guideline 
completely would be an overreaction, IMO.


-- Ed Leafe






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

[openstack-dev] [tricircle] Example EVPN question/use-case

[Curtis]

Hi,

I'm not sure if this is useful at all, but there is a blog post [1]
from one of the people behind the PacketPushers podcast regarding
connecting two OpenStack clouds with a EVPN. They are wondering how to
do it.

They want to connect an NSX based cloud with a OpenContrail based
cloud and do it at very high speeds. Interesting use case, real world.

Thanks,
Curtis.

[1]: 
http://etherealmind.com/help-wanted-stitching-a-federated-sdn-on-openstack-with-evpn/

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

Re: [openstack-dev] [release] Support phase clarification

[Andreas Jaeger]

On 2017-02-07 18:52, Jay S Bryant  wrote:
> 
> On 2/7/2017 11:41 AM, Sean McGinnis wrote:
>> Just looking for clarification on our support phase timing now with the
>> shorter release cycle for Ocata.
>>
>> According to our published support phase schedule [1], each phase is in
>> 6 month increments from the release date.
>>
>> In the past, this had lined up nicely so that when N was release, N-1
>> and N-2 rolled over into the next support phase. Now with Ocata being
>> released less than six months from Newton, I am assuming this will not
>> be the case, and we are in fact sticking with the published phases. Or
>> are we adjusting for this cycle to stay with the N-1, N-2 convention?
>>
>> Thanks!
>>
>> Sean  (smcginnis)
>>
>> [1]
>> http://docs.openstack.org/project-team-guide/stable-branches.html#support-phases
>>
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> All,
> 
> Just to be explicit, if we are sticking with the 6 month statement, this
> would mean we would still accept backports to Newton and Security Fixes
> to Mitaka until 4/7/17 .  This would also mean we would need to be
> careful to ensure that any backports to Newton also make it into Ocata
> to avoid holes in fix coverage.

https://releases.openstack.org/ says "2017-04-10" as EOL date for Mitaka,

Andreas

-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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

Re: [openstack-dev] [release] Support phase clarification

[Jay S Bryant]

On 2/7/2017 11:41 AM, Sean McGinnis wrote:

Just looking for clarification on our support phase timing now with the
shorter release cycle for Ocata.

According to our published support phase schedule [1], each phase is in
6 month increments from the release date.

In the past, this had lined up nicely so that when N was release, N-1
and N-2 rolled over into the next support phase. Now with Ocata being
released less than six months from Newton, I am assuming this will not
be the case, and we are in fact sticking with the published phases. Or
are we adjusting for this cycle to stay with the N-1, N-2 convention?

Thanks!

Sean  (smcginnis)

[1] 
http://docs.openstack.org/project-team-guide/stable-branches.html#support-phases

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

All,

Just to be explicit, if we are sticking with the 6 month statement, this 
would mean we would still accept backports to Newton and Security Fixes 
to Mitaka until 4/7/17 .  This would also mean we would need to be 
careful to ensure that any backports to Newton also make it into Ocata 
to avoid holes in fix coverage.


Thanks,
Jay


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

[openstack-dev] [release] Support phase clarification

[Sean McGinnis]

Just looking for clarification on our support phase timing now with the
shorter release cycle for Ocata.

According to our published support phase schedule [1], each phase is in
6 month increments from the release date.

In the past, this had lined up nicely so that when N was release, N-1
and N-2 rolled over into the next support phase. Now with Ocata being
released less than six months from Newton, I am assuming this will not
be the case, and we are in fact sticking with the published phases. Or
are we adjusting for this cycle to stay with the N-1, N-2 convention?

Thanks!

Sean  (smcginnis)

[1] 
http://docs.openstack.org/project-team-guide/stable-branches.html#support-phases

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

[openstack-dev] [kuryr] Resource management videoconf meeting

[Antoni Segura Puimedon]

Hi all,

In the last weekly IRC meeting it was agreed to hold a videoconf meeting
about resource management. For those unaware, the topic revolves around the
reutilization of Neutron resources like ports and subports as well and
virtual devices like veths. This allows for things like batching neutron
calls and achieveng much shorter times when creating pods.

The meeting time will be 13:30UTC Thurdsay February 9th on bluejeans:

In order to join by phone:

You can find a local number to call at:


https://www.intercallonline.com/listNumbersByCode.action?confCode=5508709975

Meeting id: 844311720

In order to join with the computer:

https://bluejeans.com/844311720

The meeting recording link will be made available.

Regards,

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

[openstack-dev] [PWG] mid-cycle venue option

[Arkady.Kanevsky]

Team,
I finally checked on my side for the venue.

The address of my available venue is
Company: Dell
Street: Viale Piero e Alberto Pirelli 6
City: Milano

That is about 15 min drive or 20 min on public transport from coworking place.

I reserved 2 conf rooms for mon-tue.
While on Tue you'll benefit for a proper room for a roundtable, on Mon the only 
room available who could accommodate 15 people is a room with a table for 10 
people and chairs all around .

Let me know if we want to follow on it.


Arkady Kanevsky, Ph.D.
Director of SW Development
Dell EMC CPSD
Dell Inc. One Dell Way, MS PS2-91
Round Rock, TX 78682, USA
Phone: 512 723 5264

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

[openstack-dev] [ux] Poll for next team meeting

[Shamail Tahir]

Hi everyone,

Per the discussion on the dev mailing list last week[1], I am sending out a
poll to determine when the UX working group should meet. Please indicate
your time preference(s) in the poll if you are interested in participating
in the OpenStack UX efforts.  Agenda will be sent out after we determine a
time.  I will be closing the poll on Feb. 9th, 2017 @ 23:59 UTC.

Poll: http://doodle.com/poll/76bnere6ztdg7hgd

-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109622.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][ceilometer][postgresql][gate][telemetry] PostgreSQL gate failure (again)

[Chris Friesen]

On 02/07/2017 07:09 AM, Rui Chen wrote:

Actually, some users used postgresql in production deployment(8%), the following
photo extract from user survey report of April 2016.


Technically the 8% includes both production (4%) as well as dev/QA (3%), and 
proof-of-concept (1%).


Chris

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

Re: [openstack-dev] [nova] Config option cleanup burndown

[Szankin, Maciej]

On 2/7/17, 4:18 AM, "Markus Zoeller"  wrote:



>On 03.02.2017 21:37, Szankin, Maciej wrote:
>> On 2/3/17 2:26 PM, Singh, Sarafraj wrote:
>>> Matt,
>>> This chart is quite accurate. We are almost finished with this work. We 
>>> have ~10 outstanding patches that did not land in Ocata. There are few more 
>>> TODO’s left in the code to clean up and that should be it.
>>>
>>> -Raj
>>>
>>> On 2/3/17, 2:08 PM, "Matt Riedemann"  wrote:
>>>
>>> This is sort of a direct question to Markus, but how accurate is this 
>>> burndown chart now?
>>> 
>>> http://45.55.105.55:8082/config-options.html
>>> 
>>> I think there is still work for this in Pike, but would like to get an 
>>> idea of how much of the work is left from those more involved (maybe 
>>> johnthetubaguy or sfinucan can respond to that?).
>>> 
>>> -- 
>>> 
>>> Thanks,
>>> 
>>> Matt Riedemann
>>> 
>>> 
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> It is up-to-date for the categories/tags that it tracks, but there is
>> still a bit more underneath - there are few TODOs left in comments that
>> still require resolving, but we are close. I did not decide to put a
>> burndown chart up for them as there can be multiple reviews per file and
>> the whole thing can be messy. We have an etherpad [0] that tries to keep
>> track of every work item that is left for this bp. TODOs are up-to-date,
>> deprecation list requires an update (which I will do this evening or
>> Monday morning).
>> 
>> There are 50 TODOs left in code (10 [it is not a 1-1 relation, this is a
>> coincidence] of them resolved in outstanding patches that Raj
>> mentioned), so it leaves 40 to resolve. Some of them are invalid, as the
>> code base has changed infinite number of times during this release, so I
>> have a WIP patch that tries to remove all no longer valid TODOs.
>> 
>> [0] https://etherpad.openstack.org/p/config-options
>> 
>> Cheers,
>> macsz
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>
>Unfortunately, non-upstream work keeps me busy and I lost track what's
>happening upstream. :(
>@macsz: After you removed the no longer valid TODOs, would you ping me?
>I'll try to free some hours per week for upstream again.
>
>-- 
>Regards, Markus Zoeller (markus_z)
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


@markus_z: sure. Depending on my other workloads, it should be by the end of 
this week or the next one.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Nova API sub-team meeting

[Matt Riedemann]

On 2/7/2017 8:14 AM, Alex Xu wrote:

Hi,

We have weekly Nova API meeting tomorrow. And it is the time to talk
about the plan of Pike. I created an etherpad for Pike ideas
https://etherpad.openstack.org/p/nova-api-pike, please free feel to add
ideas and comments.


Thanks. I've added some things in there which were already topics from 
the PTG etherpad:


https://etherpad.openstack.org/p/nova-ptg-pike

--

Thanks,

Matt Riedemann

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

Re: [openstack-dev] [FFE][requirements][murano][murano-pkg-check]pdate constraint for murano-pkg-check to new release 0.3.0

[Jeffrey Zhang]

upper-constraints.txt  is enough. let merge the following patch in the next
cycle.

thanks tonyb.

On Tue, Feb 7, 2017 at 1:46 PM, Tony Breeds  wrote:

> On Tue, Feb 07, 2017 at 11:32:28AM +0800, Rong Zhu wrote:
> > The Bot Gerrit link is: https://review.openstack.org/#/c/428200/
> >
> > update constraint for murano-pkg-check to new release 0.3.0 Change-Id:
> > I4d8cbf55525c90efd5d46f4659b57197f4c6f9f3
> >  197f4c6f9f3,n,z>
> > meta:version: 0.3.0 meta:diff-start: - meta:series: independent
> > meta:release-type: release meta:pypi: yes meta:first: no
> > meta:release:Author: zhurong 
> meta:release:Commit:
> > zhurong  meta:release:Change-Id:
> > Ifa5de68fdf5f340e240a117563667ecd8903daff
> >  ecd8903daff,n,z>
> > meta:release:Code-Review+2: Doug Hellmann 
> > meta:release:Workflow+1: Doug Hellmann 
>
> It's a upper-constraints.txt bump so I'm fine with granting an exception
> for that.
>
> Howveer the follow-up patch to bump the minimum on global-requirements.txt
> is
> too disruptive to take.
>
> From my comment on the review:
> We can't take this as it would require a re-release of python-muranoclient,
> which inturn require a re-release of python-openstackclient which then
> quickly
> blows out:
>
>  Package  : murano-pkg-check [murano-pkg-check>=0.2.0] (used by 2
> projects)
>  Also affects : 2 projects
>  openstack/murano  []
>  openstack/python-muranoclient []
>  Package  : python-muranoclient [python-muranoclient>=0.8.2] (used by
> 6 projects)
>  Also affects : 6 projects
>  openstack/congress[]
>  openstack/mistral []
>  openstack/murano  []
>  openstack/murano-dashboard[]
>  openstack/openstackclient []
>  openstack/python-openstackclient  []
>  Package  : python-openstackclient [python-openstackclient>=3.3.0]
> (used by 25 projects)
>  Also affects : 25 projects
>  openstack/ec2-api []
>  openstack/freezer []
>  openstack/heat[tc:approved-release]
>  openstack/kingbird[]
>  openstack/kolla   []
>  openstack/kolla-ansible   []
>  openstack/networking-bgpvpn   []
>  openstack/networking-midonet  []
>  openstack/networking-sfc  []
>  openstack/python-barbicanclient   []
>  openstack/python-heatclient   []
>  openstack/python-ironic-inspector-client  []
>  openstack/python-ironicclient []
>  openstack/python-kingbirdclient   []
>  openstack/python-magnumclient []
>  openstack/python-manilaclient []
>  openstack/python-mistralclient[]
>  openstack/python-moganclient  []
>  openstack/python-neutronclient[]
>  openstack/python-saharaclient []
>  openstack/python-searchlightclient[]
>  openstack/python-tripleoclient[]
>  openstack/python-troveclient  []
>  openstack/vmware-nsx  []
>  openstack/watcher []
>
> The knock-on effects are just too far reaching for this to be granted in
> Ocata.
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

[openstack-dev] [puppet] No meeting Feb 7, 2017, next meeting Feb 14, 2017

[Alex Schultz]

Hey all,

The agenda etherpad[0] was empty so we're skipping today's meeting.
The next meeting will be on Feb 14th, 2017. If you have something to
discuss, please add it to the agenda etherpad[1].

Thanks,
-Alex


[0] https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20170207
[1] https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20170214

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

[openstack-dev] [release][oslo] recreating the stable/ocata branch for mox3

[Doug Hellmann]

The stable/ocata branch for mox3 was created from 0.19.0 and then 0.20.0
was released from master. Because that repository sees a very low rate
of changes, and because the current stable/ocata branch only contained
the patch to update the .gitreview file, we decided to recreate the
branch to accurately reflect the intent of having 0.20.0 be part of the
ocata series of releases.

https://review.openstack.org/430283

Thanks go to amoralej for pointing out the issue today.

Doug

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

Re: [openstack-dev] [nova] Next notification meeting on 02.14.

[Matt Riedemann]

On 2/7/2017 7:40 AM, Balazs Gibizer wrote:

Hi,

As we agreed last week's meeting there won't be meeting this week. The
next notification subteam meeting will be held on 2017.02.14 17:00 UTC
[1] on #openstack-meeting-4.

Cheers,
gibi

[1]
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170214T17




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


I certainly hope you'll be passing out Valentines.

--

Thanks,

Matt Riedemann

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

Re: [openstack-dev] [all][api] POST /api-wg/news

[Brian Rosmaita]

On 2/6/17 4:28 PM, Ken'ichi Ohmichi wrote:
> 2017-02-06 6:45 GMT-08:00 Brian Rosmaita :
>> On 2/6/17 5:51 AM, Jordan Pittier wrote:
>> [super-enormous snip -- Chris, Ken, and Jordan make good points, I
>> encourage you to read the entire thread; I just want to concentrate on
>> one point]
>>>
>>> I would say we should make compromise, not solve dilemma. I can live in a
>>> world where we sometimes allow an API change and sometimes prevent it.
>>>
>> +1000
>>
>> I agree with Jordan.  We need to look at the context of each specific
>> case and decide whether a change is OK based on the details.  We've
>> already got the guideline that says "in general", you shouldn't change
>> the response code, and we respect that.  The Glance team isn't claiming
>> that the guideline is incorrect--we're just saying that given the
>> context of this specific bug (that is, it's been documented for a long
>> time to return a 204, all other metadefs DELETE calls are documented to
>> return a 204, all the other metadefs DELETE calls do in fact return a
>> 204, etc.), it makes sense that this case is an exception.
>>
>> Granting an exception here doesn't mean that the floodgates have opened
>> for an "anything goes" approach to API changes.  It just means that an
>> exception is appropriate in this particular case.  I am being a bit
>> disingenuous there because if an exception is appropriate in this case,
>> then it will be appropriate in other relevantly similar cases.  But
>> "relevant similarity" will include the entire context of the case, for
>> example, whether there was a published API contract, whether the other
>> similar calls behave as documented, etc.  From 10,000 meters, it looks
>> like what we're advocating is "It's OK to change a response code".  But
>> when you look more closely, our claim is that given the details of this
>> particular bug, it makes sense to fix it in the code and not in the docs.
>>
>> To summarize, my point is that we shouldn't be worried that this case is
>> going to set a precedent.  It would be worrisome if it were going to set
>> a *bad* precedent, but when you look at the details of the situation, I
>> don't think it will.  So it looks to me, anyway, that a compromise is in
>> order here.  (In case I'm being too obscure, what I mean is: we should
>> agree that it's OK for the Glance team to fix this bug in the code with
>> patch https://review.openstack.org/#/c/420038/.)
> 
> I feel this case is very common case when we want to chang success status 
> code.
> Because I cannot find the other motivation for changing success status
> code except we are finding bugs like this case.
> 
> So if accepting this case, I guess we drop the following guideline 
> completely[1]
> 
>   The following types of changes are generally *not* considered acceptable:
>Changing which response code is returned on success.

I think that's a separate discussion that shouldn't hold up whether we
can get this particular bug properly fixed soon.

It doesn't follow that if Glance makes this change, the guideline is
pointless.  As I said earlier, given the context of this particular bug
(the success code for the call has been documented as a 204, all the
other metadefs DELETE calls return a 204, all the other calls are also
documented to return 204s, etc.), one can argue that this is a
legitimate exception allowed under the guideline.  And in fact the API
Working Group has accepted that argument.  If the facts of the case were
different, they might very well have told me to go boil my head.

My point here is that we can accept the guideline *and* also accept this
particular change.  Hence, worrying about the status of the guideline is
not a reason to reject the fix proposed by the patch
https://review.openstack.org/#/c/420038/ .

cheers,
brian

> 
> Thanks
> Ken Ohmichi
> 
> ---
> [1]: 
> https://specs.openstack.org/openstack/api-wg/guidelines/evaluating_api_changes.html#guidance
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] [QA] Announcing my candidacy for PTL of the Pike cycle

[Rodrigo Duarte]

On Tue, Feb 7, 2017 at 7:34 AM, Andrea Frittoli 
wrote:

>
> On Tue, Feb 7, 2017 at 1:55 AM Ghanshyam Mann 
> wrote:
>
>> Hi Jordan,
>>
>> Thanks for bring it up. I know we had both side of argument on those
>> changes.
>>
>> IMO in general, its all QA team responsibility to verify the requirement
>> very strictly and make sure no changes break existing released version and
>> so users. Many times QA team does not agree to development team :).
>>
>> But as we are working as community and one of our key goal is to smooth
>> development also. But as of now, strong rejection or formal approval from
>> QA team is something missing in formal guidelines or formal written.
>>
>> We have api-wg and its guidelines which are a great things in OpenStack
>> and helped a lot to improve the APIs. But those are just guidelines and no
>> hard restriction.
>>
>> Many of us can say if we are changing the APIs in backward incompatible
>> way, then api-wg and QA agreements are great to consider and then only
>> proceed but many of us can say if project team want then even disagreement
>> from QA or api-wg does not matter much.
>>
>> As we do not have any official statement anywhere about mandatory
>> agreement of QA team, i do not think we can stop any projects for such
>> changes but we can always put our strong opinion and try to make project
>> team understand that how harmful that changes can be.
>>
>> To make it in more smooth way in future, there is proposal in TC for new
>> tag "supports-api-compatibility" [1] (thanks matt for that) and cdent is
>> refactoring the api-wg guidelines accordingly [2].
>>
>> This is really nice direction and if any projects adopt to have that new
>> tag, then they have to honor the API compatibility and honor the api-wg, QA
>> and TC decision.
>>
>
> +1.
> I think the discussion around the referenced API changes has been quite
> positive, it has lead to a review of api-wg guidelines as well as the
> proposal for a new tag.
> As a QA team we have the responsibility - at least for the projects whose
> tests are hosted in Tempest - to identity changes that may break API
> compatibility and trigger such discussions in the community and help
> building consensus. Ideally in future the process will be much smoother as
> we keep improving guidelines and processes around API stability.
>

Changes that break APIs stability are not uncommon, in keystone, for
example, we already had to deal with some of them. Hopefully, we are
creating a culture where tempest-like tests are being more present and with
this, we can quickly spot such kind of changes.


>
>
>>
>> My opinion on that to have a clear responsibility of QA, api-wg to make
>> projects considering new tag strictly honor the compatibility guidelines.
>> So that we as QA team have formal rights to stop any incompatible changes.
>>
>>
>
>> I personally feel we have to have a very clear responsibility of QA team
>> over API incompatible changes which will be helped by TC and all of us to
>> have consensus on that and keep/make OpenStack APIs as one of the best APIs
>> for users.
>>
>> ..1 https://review.openstack.org/#/c/418010/3
>> ..2 https://review.openstack.org/#/c/421846/
>>
>>
>> -gmann
>>
>> On Mon, Feb 6, 2017 at 8:14 PM, Jordan Pittier <
>> jordan.pitt...@scality.com> wrote:
>>
>> Hi gmann,
>> Thanks for your candidacy. Let me ask one question if it's not too
>> late. What's the role of the QA team when it comes to API change ? I
>> have in mind the recent Glance change related to private vs shared
>> image status.
>>
>> Someone in our community asked :
>> * "I need to get an official decision from the QA team on whether
>> [such a] patch is acceptable or not"
>> * "what's needed is an "official" response from the QA team concerning
>> the acceptability of the patch"
>>
>> But we didn't provide such an answer. There could be a feeling that
>> the QA team is acting as a self-appointed activist judiciary.
>>
>> Now we have another occurrence of a disagreement between the QA team
>> and a project team: https://bugs.launchpad.net/glance/+bug/1656183,
>> https://review.openstack.org/#/c/420038/,
>> https://review.openstack.org/#/c/425487/
>>
>> I have myself no strong opinion on the matter, that why I need a leader
>> here :)
>>
>> Note, there *is* a question in this email :D
>>
>> Jordan
>>
>> On Thu, Jan 19, 2017 at 12:05 PM, Ghanshyam Mann
>>  wrote:
>> > Hi All,
>> >
>> >
>> >
>> > First and foremost would like to wish you all a successful 2017 ahead
>> and
>> > with this I'm announcing my PTL candidacy of the Quality Assurance team
>> for
>> > the Pike release cycle.
>> >
>> >
>> >
>> > I am glad to work in OpenStack community and would like to thank all the
>> > contributors who supported me to explore new things which brings out my
>> best
>> > for the community.
>> >
>> >
>> >
>> > Let me introduce myself, briefly. I have joined the OpenStack community
>> > development in 2014 during mid of Ice-House release. Currently, I'm
>> > contri

[openstack-dev] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting tomorrow. And it is the time to talk about
the plan of Pike. I created an etherpad for Pike ideas
https://etherpad.openstack.org/p/nova-api-pike, please free feel to add
ideas and comments.


The meeting is being held Wednesday UTC1300 and irc channel is
#openstack-meeting-4.

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.

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

Re: [openstack-dev] [ansible]Octavia ansible script

[Major Hayden]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/07/2017 12:00 AM, Santhosh Fernandes wrote:
> Can we know the status of octavia ansible script ?
> 
> Link :- https://blueprints.launchpad.net/~german-eichberger 
> 
> 
> Is there any version available for beta testing. Can you provide us link? or 
> time line of availability.

Hello Santosh,

Although I drafted the spec[0], German Eichberger has taken over the work on 
the WIP patchset[1].  He would be the best person to discuss timelines and 
remaining work to be done.

[0] 
http://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/lbaasv2.html
[1] https://review.openstack.org/#/c/417210/

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYmdSOAAoJEHNwUeDBAR+xkh0P/25yqkYIIxPuO/uvV+jNdiny
NMxNClMfNxpKagCjokJyoMvyVDVX0VR71RloEeigOrTGTP7goAotn99J0pUK+je/
X7zU7POwqV92mAj/3gU7uWm1792EZNCWNpnd9IQiik9PfEcLPmmW1FZeuxyY/l8K
ZE3VOAId0lHaZYbHXR9GCLzy5QwwXM1kg1+Ub1ivIbU3Q81Ais3L64KXLth7ahtu
5dIaCAKZ6uqOVRe336kI9aYPv5N4Fpwt5OkZUdGf4iNc/fivAjrGxaLt9H0ldZJQ
lsbOl1wtjlYJwreQWVGaNBEx/F1UZocnnvzUe9vAUIY2leTZ4eQck16fEkbkRe6b
Zl+o/GVh0mwS+IBjZcilJxQ7PoOX/07Z2wZOHuy8ihUIkM/L2ySP3TBWImv5a5H0
eQW1uK1B45j68E61oEuyW9DvNCWNTltUwD/FQNk833vFAtv35eqMRF1vhx3pPwmO
GI1SQC55n0q96DF+5JedkAVy3qXwgt4CQwxvku8meD0hFb7XpWwy5DBd5p4ZbBb4
XpjlsGkLzBK0uyLPyXaZ0LbFJ3Czp68Gbys09yLxjGI+P+PFWuWGVgoL/+FV9XA2
H7St0aFZJgM0cLFYYQF1ols48SbPUp3HchexaXgltMfGYy2A3x/nnbEJSPtH7Vp9
V9TEomffspXHgMQ2U3R5
=BmgA
-END PGP SIGNATURE-

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

[openstack-dev] [nova] Next notification meeting on 02.14.

[Balazs Gibizer]

Hi,

As we agreed last week's meeting there won't be meeting this week. The 
next notification subteam meeting will be held on 2017.02.14 17:00 UTC 
[1] on #openstack-meeting-4.


Cheers,
gibi

[1]
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170214T17




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

Re: [openstack-dev] [Oslo][all] Pike PTG idea & discussion

[Sean McGinnis]

On Mon, Feb 06, 2017 at 01:48:59PM -0600, Lance Bragstad wrote:
> Not sure how much time it would require at the PTG - but I'd really like to
> discuss the ability to add in-code descriptions of oslo.policy objects, and
> eventually whatever we need to advertise new defaults. I'm hoping this will
> help OpenStack as a whole move towards providing better policy
> out-of-the-box.
> 

I think this is a great idea. I'd like to discuss policy-in-code and see
what others are doing here as well.

> The keystone group has mentioned a few times that we'd like to vet the
> approach nova took towards moving policy into code using oslo.policy. I've
> been trying to synchronize keystone's efforts [0] [1] with John Garbutt
> (@johnthetubaguy), who is working on the nova side of things [2].
> 
> I'd be happy to help organize anything needed to make these discussions as
> productive as possible in Atlanta. We can use the cross-project policy
> meeting to prepare for this, too [3].
> 
> 
> [0] https://review.openstack.org/#/c/428453/
> [1] https://review.openstack.org/#/c/428454/
> [2] https://review.openstack.org/#/c/427872/
> [3] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting
> 

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

Re: [openstack-dev] [tripleo][ui] Now with translations :)

[Julie Pichon]

On 6 February 2017 at 16:03, Ben Nemec  wrote:
> On 02/06/2017 05:38 AM, Julie Pichon wrote:
>>
>> Hi folks,
>>
>> You may have noticed a new type of patch in our queue this morning
>> [1]. There's a nice link in the commit message [2][3] that describes
>> what to do with it (TL;DR: check the structure is correct, merge it
>> quickly - most projects have a single core approval policy for these
>> as well, which I wasn't aware of. Nice!).
>
> Can you propose adding this to the expedited approvals policy?
> https://specs.openstack.org/openstack/tripleo-specs/specs/policy/expedited-approvals.html

Done! https://review.openstack.org/#/c/430195/

TripleO UI cores, I also added you as reviewers since you are
currently the main people affected.

Thanks,

Julie

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

Re: [openstack-dev] [QA] Announcing my candidacy for PTL of the Pike cycle

[Andrea Frittoli]

On Tue, Feb 7, 2017 at 1:55 AM Ghanshyam Mann 
wrote:

> Hi Jordan,
>
> Thanks for bring it up. I know we had both side of argument on those
> changes.
>
> IMO in general, its all QA team responsibility to verify the requirement
> very strictly and make sure no changes break existing released version and
> so users. Many times QA team does not agree to development team :).
>
> But as we are working as community and one of our key goal is to smooth
> development also. But as of now, strong rejection or formal approval from
> QA team is something missing in formal guidelines or formal written.
>
> We have api-wg and its guidelines which are a great things in OpenStack
> and helped a lot to improve the APIs. But those are just guidelines and no
> hard restriction.
>
> Many of us can say if we are changing the APIs in backward incompatible
> way, then api-wg and QA agreements are great to consider and then only
> proceed but many of us can say if project team want then even disagreement
> from QA or api-wg does not matter much.
>
> As we do not have any official statement anywhere about mandatory
> agreement of QA team, i do not think we can stop any projects for such
> changes but we can always put our strong opinion and try to make project
> team understand that how harmful that changes can be.
>
> To make it in more smooth way in future, there is proposal in TC for new
> tag "supports-api-compatibility" [1] (thanks matt for that) and cdent is
> refactoring the api-wg guidelines accordingly [2].
>
> This is really nice direction and if any projects adopt to have that new
> tag, then they have to honor the API compatibility and honor the api-wg, QA
> and TC decision.
>

+1.
I think the discussion around the referenced API changes has been quite
positive, it has lead to a review of api-wg guidelines as well as the
proposal for a new tag.
As a QA team we have the responsibility - at least for the projects whose
tests are hosted in Tempest - to identity changes that may break API
compatibility and trigger such discussions in the community and help
building consensus. Ideally in future the process will be much smoother as
we keep improving guidelines and processes around API stability.


>
> My opinion on that to have a clear responsibility of QA, api-wg to make
> projects considering new tag strictly honor the compatibility guidelines.
> So that we as QA team have formal rights to stop any incompatible changes.
>
>

> I personally feel we have to have a very clear responsibility of QA team
> over API incompatible changes which will be helped by TC and all of us to
> have consensus on that and keep/make OpenStack APIs as one of the best APIs
> for users.
>
> ..1 https://review.openstack.org/#/c/418010/3
> ..2 https://review.openstack.org/#/c/421846/
>
>
> -gmann
>
> On Mon, Feb 6, 2017 at 8:14 PM, Jordan Pittier  > wrote:
>
> Hi gmann,
> Thanks for your candidacy. Let me ask one question if it's not too
> late. What's the role of the QA team when it comes to API change ? I
> have in mind the recent Glance change related to private vs shared
> image status.
>
> Someone in our community asked :
> * "I need to get an official decision from the QA team on whether
> [such a] patch is acceptable or not"
> * "what's needed is an "official" response from the QA team concerning
> the acceptability of the patch"
>
> But we didn't provide such an answer. There could be a feeling that
> the QA team is acting as a self-appointed activist judiciary.
>
> Now we have another occurrence of a disagreement between the QA team
> and a project team: https://bugs.launchpad.net/glance/+bug/1656183,
> https://review.openstack.org/#/c/420038/,
> https://review.openstack.org/#/c/425487/
>
> I have myself no strong opinion on the matter, that why I need a leader
> here :)
>
> Note, there *is* a question in this email :D
>
> Jordan
>
> On Thu, Jan 19, 2017 at 12:05 PM, Ghanshyam Mann
>  wrote:
> > Hi All,
> >
> >
> >
> > First and foremost would like to wish you all a successful 2017 ahead and
> > with this I'm announcing my PTL candidacy of the Quality Assurance team
> for
> > the Pike release cycle.
> >
> >
> >
> > I am glad to work in OpenStack community and would like to thank all the
> > contributors who supported me to explore new things which brings out my
> best
> > for the community.
> >
> >
> >
> > Let me introduce myself, briefly. I have joined the OpenStack community
> > development in 2014 during mid of Ice-House release. Currently, I'm
> > contributing in QA projects and Nova as well as a core member in Tempest.
> > Since Barcelona Summit, I volunteered  as mentor in the upstream
> training.
> > It‘s always a great experience to introduce OpenStack upstream workflow
> to
> > new contributors and encourage them.
> >
> >
> >
> > Following are my contribution activities:
> >
> > * Review:
> > http://stackalytics.com/?release=all&metric=marks&user_id=ghanshyammann
> >
> > * Commit:
> >
> http://stackalytics.com/?release=all&metric

Re: [openstack-dev] [nova] Config option cleanup burndown

[Markus Zoeller]

On 03.02.2017 21:37, Szankin, Maciej wrote:
> On 2/3/17 2:26 PM, Singh, Sarafraj wrote:
>> Matt,
>> This chart is quite accurate. We are almost finished with this work. We have 
>> ~10 outstanding patches that did not land in Ocata. There are few more 
>> TODO’s left in the code to clean up and that should be it.
>>
>> -Raj
>>
>> On 2/3/17, 2:08 PM, "Matt Riedemann"  wrote:
>>
>> This is sort of a direct question to Markus, but how accurate is this 
>> burndown chart now?
>> 
>> http://45.55.105.55:8082/config-options.html
>> 
>> I think there is still work for this in Pike, but would like to get an 
>> idea of how much of the work is left from those more involved (maybe 
>> johnthetubaguy or sfinucan can respond to that?).
>> 
>> -- 
>> 
>> Thanks,
>> 
>> Matt Riedemann
>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> It is up-to-date for the categories/tags that it tracks, but there is
> still a bit more underneath - there are few TODOs left in comments that
> still require resolving, but we are close. I did not decide to put a
> burndown chart up for them as there can be multiple reviews per file and
> the whole thing can be messy. We have an etherpad [0] that tries to keep
> track of every work item that is left for this bp. TODOs are up-to-date,
> deprecation list requires an update (which I will do this evening or
> Monday morning).
> 
> There are 50 TODOs left in code (10 [it is not a 1-1 relation, this is a
> coincidence] of them resolved in outstanding patches that Raj
> mentioned), so it leaves 40 to resolve. Some of them are invalid, as the
> code base has changed infinite number of times during this release, so I
> have a WIP patch that tries to remove all no longer valid TODOs.
> 
> [0] https://etherpad.openstack.org/p/config-options
> 
> Cheers,
> macsz
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Unfortunately, non-upstream work keeps me busy and I lost track what's
happening upstream. :(
@macsz: After you removed the no longer valid TODOs, would you ping me?
I'll try to free some hours per week for upstream again.

-- 
Regards, Markus Zoeller (markus_z)


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

Re: [openstack-dev] [telemetry][panko] status of pankoclient

[Julien Danjou]

On Tue, Feb 07 2017, Sheng Liu wrote:

Hi,

> As we have moved events related APIs to Panko and deprecated Ceilometer's
> API, the Panko will be the unique entry of event data. But I cannot find
> pankoclient in git.openstack.org and launchpad, instead, there is a
> pankoclient package in Pypi[1]. I am not sure who is the maintainer of the
> pypi lib and what status it is, but it is not convenient to maintaince and
> improve it if it only exist in Pypi. do we have any plan to add a
> pankoclient in OpenStack's git repo?

There's is no pankoclient right now. The one registered on PyPI was not
registered by the Telemetry team but by HuachaoMao and I have no clue
who is that. That does not sound nice.

There's no plan to add any client right now, because nobody proposed to
take charge of this job. 

-- 
Julien Danjou
# Free Software hacker
# https://julien.danjou.info


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

Re: [openstack-dev] [cinder] cinder 10.0.0.0rc1 (ocata)

[Dulko, Michal]

Hi,

With Cinder master being open for Pike development I ask not to merge
any changes with DB schema migrations before sanity check migration [1]
gets in. It's supposed to block going forward until all of the Ocata's
data migrations were executed and should be the first migration in
Pike.

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

Thanks,
Michal

On Mon, 2017-02-06 at 23:38 +, no-re...@openstack.org wrote:
> Hello everyone,
> 
> A new release candidate for cinder for the end of the Ocata
> cycle is available!  You can find the source code tarball at:
> 
> https://tarballs.openstack.org/cinder/
> 
> Unless release-critical issues are found that warrant a release
> candidate respin, this candidate will be formally released as the
> final Ocata release. You are therefore strongly
> encouraged to test and validate this tarball!
> 
> Alternatively, you can directly test the stable/ocata release
> branch at:
> 
> http://git.openstack.org/cgit/openstack/cinder/log/?h=stable/ocata
> 
> Release notes for cinder can be found at:
> 
> http://docs.openstack.org/releasenotes/cinder/
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev