Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Hi KaiQiang, Thank you for your reply. As for 1), You are correct in that Magnum does support 2 flavors(one is for master node and the other is for minion nodes). What I want to address is whether we should support 2 or N Nova flavors ONLY for minion nodes. As for 2), We have made Magnum

Re: [openstack-dev] [infra][devstack] stable/kilo devstack fails with pkg_resources.ContextualVersionConflict

On Tue, Apr 19, 2016 at 01:14:34PM +0200, Lajos Katona wrote: > Hi, > > In our internal CI system we realized that stable/kilo devstack fails with > the following stack trace: > It seems that the root cause is that testresources has a new version 2.0.0 > from 18 April. > > I tried to find

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On Wed, Apr 20, 2016, at 08:44 PM, Tony Breeds wrote: > On Thu, Apr 21, 2016 at 02:09:24PM +1200, Robert Collins wrote: > > > I also argued at the time that we should aim for entirely automated > > check-and-update. This has stalled on not figuring out how to run e.g. > > Neutron unit tests

Re: [openstack-dev] [Neutron] L3 HA testing on scale

Indeed it will be a terrific contribution. Edgar On Apr 20, 2016, at 4:10 AM, Dina Belova > wrote: Folks, I think Ann's report is super cool and 100% worth publishing on OpenStack

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On Thu, Apr 21, 2016 at 02:09:24PM +1200, Robert Collins wrote: > I also argued at the time that we should aim for entirely automated > check-and-update. This has stalled on not figuring out how to run e.g. > Neutron unit tests against requirements changes - our coverage is just > too low at the

Re: [openstack-dev] summit tools

On Wed, Apr 20, 2016 at 12:14 PM Neil Jerram wrote: > A couple of questions about our Austin-related planning tools... > > - Can one's calendar at > > https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-25 > be exported as .ics, or otherwise

Re: [openstack-dev] [glance] weekly meeting on apr 21st

Just wanted to let everyone know: I am officially cancelling the meeting for Apr 21st (no agenda). Also, we won't have weekly meeting during the summit week ie on Apr 28th. Next meeting will be on May 5th. See you all online then. On 4/20/16 1:27 PM, Nikhil Komawar wrote: > Hi all, > > Last

Re: [openstack-dev] [neutron] [networking-sfc] A standards-compliant SFC API

Just a quick glance over the proposal seems like the networking-sfc also does the same. In addition, networking-sfc is successfully integrated with ONOS[1] and planned for ODL[2], OVN [3] & Tacker[4] (without any issues with the existing API's so far). In addition, If we feel the existing

Re: [openstack-dev] [keystone] Liberty - problem with assignment LDAP backend - Groups

On 04/20/2016 09:10 PM, Dmitry Sutyagin wrote: Another correction - the issue is observed in Kilo, not Liberty, sorry for messing this up. (though this part of the code is identical in L) On Wed, Apr 20, 2016 at 5:50 PM, Dmitry Sutyagin >

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On 18 April 2016 at 03:13, Doug Hellmann wrote: > I am organizing a summit session for the cross-project track to > (re)consider how we manage our list of global dependencies [1]. > Some of the changes I propose would have a big impact, and so I > want to ensure everyone

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On 20 April 2016 at 05:44, Clint Byrum wrote: > Excerpts from Michał Jastrzębski's message of 2016-04-18 10:29:20 -0700: >> What I meant is if you have liberty Nova and liberty Cinder, and you >> want to upgrade Nova to Mitaka, you also upgrade Oslo to Mitaka and >> Cinder which

[openstack-dev] [QA] Meeting Thursday April 21st at 9:00 UTC

Hello everyone, Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, April 21st at 9:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_April_21st_2016_.280900_UTC.29

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On 20 April 2016 at 04:47, Clark Boylan wrote: > On Tue, Apr 19, 2016, at 08:14 AM, Doug Hellmann wrote: >> Excerpts from Jeremy Stanley's message of 2016-04-19 15:00:24 +: >> > On 2016-04-19 09:10:11 -0400 (-0400), Doug Hellmann wrote: >> > [...] >> > > We have the

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On 20 April 2016 at 03:00, Jeremy Stanley wrote: > On 2016-04-19 09:10:11 -0400 (-0400), Doug Hellmann wrote: > [...] >> We have the global list and the upper constraints list, and both >> are intended to be used to signal to packaging folks what we think >> ought to be used.

Re: [openstack-dev] [keystone] Liberty - problem with assignment LDAP backend - Groups

Another correction - the issue is observed in Kilo, not Liberty, sorry for messing this up. (though this part of the code is identical in L) On Wed, Apr 20, 2016 at 5:50 PM, Dmitry Sutyagin wrote: > Correction: > > group_dns = [u'CN=GroupX,OU=Groups,OU=SomeOU,DC=zzz'] >

Re: [openstack-dev] [keystone] Liberty - problem with assignment LDAP backend - Groups

Correction: group_dns = [u'CN=GroupX,OU=Groups,OU=SomeOU,DC=zzz'] ra.user_dn.upper() = 'CN=GROUPX,OU=GROUPS,OU=SOMEOU,DC=ZZZ' So this could work if only: - string in group_dns was str, not unicode - text was uppercase Now the question is - should it be so? On Wed, Apr 20, 2016 at 5:41 PM,

[openstack-dev] [keystone] Liberty - problem with assignment LDAP backend - Groups

Hi everybody, I am observing the following issue: LDAP backend is enabled for identity and assignment, domain specific configs disabled. LDAP section configured - users, groups, projects and roles are mapped. I am able to use identity v3 api to list users, groups, to verify that a user is in a

Re: [openstack-dev] [tricircle] http response code

Yes, Tricircle follows HTTP guideline from OpenStack API working group: https://specs.openstack.org/openstack/api-wg/guidelines/http.html If something is not followed the guideline, please report a bug to track the issue. Best Regards Chaoyi Huang ( Joe Huang ) From: Shinobu Kinjo

[openstack-dev] [release][oslo] oslo.i18n 3.6.0 release (newton)

We are tickled pink to announce the release of: oslo.i18n 3.6.0: Oslo i18n library This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.i18n With package available at: https://pypi.python.org/pypi/oslo.i18n Please

[openstack-dev] [release][oslo] oslo.log 3.5.0 release (newton)

We are tickled pink to announce the release of: oslo.log 3.5.0: oslo.log library This release is part of the newton release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.log With package available at: https://pypi.python.org/pypi/oslo.log Please

[openstack-dev] [release][stable][oslo] oslo.db 1.7.5 release (kilo)

We are psyched to announce the release of: oslo.db 1.7.5: oslo.db library This release is part of the kilo stable release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.db Please report issues through launchpad: http://bugs.launchpad.net/oslo.db For

Re: [openstack-dev] [python-keystoneclient] Return request-id to caller

On Wed, Apr 13, 2016 at 6:07 AM, David Stanek wrote: > On Wed, Apr 13, 2016 at 3:26 AM koshiya maho > wrote: > >> >> My request to all keystone cores to give their suggestions about the same. >> >> > I'll test this a little and see if I can see

[openstack-dev] [nova] api-ref content verification phase doc push

This morning we finally cleaned up the last warnings in api-ref, so now we can enforce errors on warnings. Woot! That went much faster than I anticipated, and puts us at a really good place for summit. The next phase is the content verification phase. This patch is merging a set of comments at

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Its new enough that people haven't thought to ask until recently. The recent interest is starting in the topic due to Magnum getting mature enough folks are starting to deploy it and finding out it doesn't solve a bunch of issues they had thought it would. Its pretty natural. Don't just blow it

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

I think Magnum much is much closer to Sahara or Trove in its workings. Heat's orchestration. Thats what the COE does. Sahara is and has plugins to deploy various Hadoopy like clusters, get them assembled into something useful, and has a few abstraction api's like "submit a job to the deployed

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

> -Original Message- > From: Keith Bray [mailto:keith.b...@rackspace.com] > Sent: April-20-16 6:13 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified > abstraction for all COEs > > Magnum doesn¹t

Re: [openstack-dev] summit tools

On Wed, Apr 20, 2016 at 04:13:38PM +, Neil Jerram wrote: > A couple of questions about our Austin-related planning tools... > > - Can one's calendar at > https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-25 > be exported as .ics, or otherwise integrated into a wider

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

If Magnum will be focused on installation and management for COE it will be unclear how much it is different from Heat and other generic orchestrations. It looks like most of the current Magnum functionality is provided by Heat. Magnum focus on deployment will potentially lead to another

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

+1 to plugins. it has suited nova/trove/sahara/etc well. Thanks, Kevin From: Keith Bray [keith.b...@rackspace.com] Sent: Wednesday, April 20, 2016 3:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev]

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

On Wed, Apr 20, 2016 at 3:10 PM, Boden Russell wrote: > Today there are a number of places in nova, neutron and perhaps > elsewhere that employ backoff + timeout strategies (see [1] - [4]). > While we are working towards a unified approach in neutron for RPC [5], > it appears

Re: [openstack-dev] [neutron] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

On 4/20/2016 8:25 AM, Miguel Angel Ajo Pelayo wrote: Inline update. On Mon, Apr 11, 2016 at 4:22 PM, Miguel Angel Ajo Pelayo wrote: On Mon, Apr 11, 2016 at 1:46 PM, Jay Pipes wrote: On 04/08/2016 09:17 AM, Miguel Angel Ajo Pelayo wrote: [...] Yes,

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Magnum doesn¹t have to preclude tight integration for single COEs you speak of. The heavy lifting of tight integration of the COE in to OpenStack (so that it performs optimally with the infra) can be modular (where the work is performed by plug-in models to Magnum, not performed by Magnum itself.

Re: [openstack-dev] [python-keystoneclient] Return request-id to caller

On Wed, Apr 20, 2016 at 6:31 AM, Duncan Thomas wrote: > On 20 April 2016 at 08:08, koshiya maho > wrote: > > >> This design was discussed, reviewed and approved in cross-projects [1] and >> already implemented in nova, cinder and neutron. >>

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Thierry Carrez wrote: Adrian Otto wrote: This pursuit is a trap. Magnum should focus on making native container APIs available. We should not wrap APIs with leaky abstractions. The lowest common denominator of all COEs is an remarkably low value API that adds considerable complexity to Magnum

[openstack-dev] [magnum] Seek advices for a licence issue

Hi Mark, I have went though the announcement in details, From my point of view, it seems to resolve the license issue that was blocking us in before. I have included the Magnum team in ML to see if our team members have any comment. Thanks for the support from foundation. Best regards,

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Feel free to take the following (if its similar to what u are thinking) https://github.com/openstack/anvil/blob/master/anvil/utils.py#L90 IMHO though if its a decorator, the retrying library can already perform this: https://pypi.python.org/pypi/retrying And a couple of the oslo-cores (jd,

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Excerpts from Chris Dent's message of 2016-04-20 22:16:10 +0100: > > Will the already existing retrying[1] do the job or is it missing > features (the namespacing thing seems like it could be an issue) > or perhaps too generic? > > [1] https://pypi.python.org/pypi/retrying > Yes, please, let's

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Will the already existing retrying[1] do the job or is it missing features (the namespacing thing seems like it could be an issue) or perhaps too generic? [1] https://pypi.python.org/pypi/retrying -- Chris Dent (�s°□°)�s�喋擤ォ�http://anticdent.org/ freenode: cdent

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Boden, Are you thinking of implementing something which would perform exponentially backed off calls to some arbitrary function till that method returns with something other than a timeout? I think that would be very versatile, and useful in a wide variety of places. Thanks, -amrith >

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

tl;dr: You're right, but the point I was making was that all distros are understaff. Longer version: On 04/19/2016 06:24 PM, Ian Cordasco wrote: >> You can also add "Ubuntu" in the list here, as absolutely all OpenStack >> dependencies are maintained mostly by me, within Debian, and then later >

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

On Wed, 2016-04-20 at 14:10 -0600, Boden Russell wrote: > Anyone adverse to me crafting an initial oslo patch to kick-off the > details on this one? Have you evaluated any existing solutions in this space? A quick search on PyPi turns up "backoff", which seems to provide several backoff

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Sounds good to me Boden. -- Dims On Wed, Apr 20, 2016 at 4:10 PM, Boden Russell wrote: > Today there are a number of places in nova, neutron and perhaps > elsewhere that employ backoff + timeout strategies (see [1] - [4]). > While we are working towards a unified approach in

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On Wed, Apr 20, 2016 at 10:28 AM, Dean Troyer wrote: > On Wed, Apr 20, 2016 at 9:43 AM, Doug Hellmann > wrote: > >> Cliff looks for commands on demand. If we modify it's command loader to >> support some "built in" commands, and then implement the

Re: [openstack-dev] [tripleo] Proposed changes to TripleO project tags

On Wed, Apr 20, 2016 at 6:16 AM, Steven Hardy wrote: > All, > > We discussed some changes to our release cycle in the weekly meeting > yesterday, namely to align with the intended direction of the puppet > community to adopt the new cycle-trailing tag[1]. > > We have also

[openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Today there are a number of places in nova, neutron and perhaps elsewhere that employ backoff + timeout strategies (see [1] - [4]). While we are working towards a unified approach in neutron for RPC [5], it appears such logic could benefit the greater community as a reusable oslo implementation.

Re: [openstack-dev] [neutron] [networking-sfc] A standards-compliant SFC API

Thanks for the feedback Armando, Adding missing tag. Best regards, Igor. From: Armando M. [mailto:arma...@gmail.com] Sent: Wednesday, April 20, 2016 6:03 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev]

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

Hi Hongbin. On Wed, Apr 20, 2016 at 8:13 PM, Hongbin Lu wrote: > > > > > From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) > [mailto:li-gong.d...@hpe.com] > Sent: April-20-16 3:39 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject:

Re: [openstack-dev] [Magnum]Cache docker images

Hi. On Wed, Apr 20, 2016 at 5:43 PM, Fox, Kevin M wrote: > If the ops are deploying a cloud big enough to run into that problem, I > think they can deploy a scaled out docker registry of some kind too, that > the images can point to? Last I looked, it didn't seem very

Re: [openstack-dev] [Magnum]Cache docker images

From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: April-20-16 9:39 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum]Cache docker images Hongbin, Both of approaches you suggested may only work for one binary format. If you try to

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

> -Original Message- > From: Ian Cordasco [mailto:sigmaviru...@gmail.com] > Sent: April-20-16 1:56 PM > To: Adrian Otto; OpenStack Development Mailing List (not for usage > questions) > Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified > abstraction for all COEs > >

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

I'll go ahead and be the guy to ask for N flavors. :) AZ zones are kind of restrictive in what they can do, so we usually use flavors, which are much more flexable. I can totally see a project with 3 different types of flavors and want them all in the same k8s cluster managed by labels.

Re: [openstack-dev] [ironic-staging-drivers] Tests at the gates

On 04/20/2016 04:57 PM, Vasyl Saienko wrote: > Hello Ironic-staging-drivers team, > > At the moment there is no tests for ironic-staging-drivers at the gates. > I think we need to have a simple test that install drivers with theirs > dependencies and ensures that ironic-conductor is able to

Re: [openstack-dev] [puppet] Stepping down from puppet-openstack-core

> On Apr 18, 2016, at 8:37 AM, Sebastien Badia wrote: > > Hello here, > > I would like to ask to be removed from the core reviewers team on the > Puppet for OpenStack project. > > I lack dedicated time to contribute on my spare time to the project. And I > don't work anymore on

Re: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes

From: Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) [mailto:li-gong.d...@hpe.com] Sent: April-20-16 3:39 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Magnum] Magnum supports 2 Nova flavor to provision minion nodes Hi Folks, We are considering

Re: [openstack-dev] [tripleo][heat] Summit session clashes

[snip] I need to be at both of those Heat ones anyway, so this doesn't really help me. I'd rather have the DLM session in this slot instead. (The only sessions I can really skip are the Release Model, Functional Tests and DLM.) That would give us: HeatTripleO

[openstack-dev] [release][quality] hacking 0.11.0 release

We are content to announce the release of: hacking 0.11.0: OpenStack Hacking Guideline Enforcement With package available at: https://pypi.python.org/pypi/hacking For more details, please see below. Changes in hacking 0.10.1..0.11.0 - c3b03a9 Updated from

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

-Original Message- From: Adrian Otto Reply: OpenStack Development Mailing List (not for usage questions) Date: April 19, 2016 at 19:11:07 To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [heat]informal meetup during summit

On 4/20/16 1:00 PM, Rico Lin wrote: Hi team Let plan for more informal meetup(relax) time! Let all heaters and any other projects can have fun and chance for technical discussions together. After discuss in meeting, we will have a pre-meetup-meetup on Friday morning to have a cup of cafe or

Re: [openstack-dev] [ironic] upgrade support between which versions of ironic?

On Wed, Apr 20, 2016 at 5:38 AM, Mathieu Mitchell wrote: > > > On 2016-04-19 11:29 PM, Tan, Lin wrote: > >> I agree this is reasonable to support all these cases in “cold upgrades” >> but in supports-rolling-upgrade (live upgrade in another word) case it is >> different

[openstack-dev] [Freezer] No IRC meeting next week and summit details

Hello, There will be no IRC meeting next week due to the OpenStack summit. Feel free to join us at one of the four Design summit session we will be holding: - Wed: 9:50 - 10:30: Backup your OpenStack infrastructure [1] - Wed: 11:00 - 11:40: Backup as a service [2] - Wed: 11:50 - 12:30:

Re: [openstack-dev] [openstack-operators] [glance] [Austin summit] Glance session for operator feedback

NOTE: this is a operator focused session and has been tagged for ops for it to appear in cross track! On 4/20/16 1:39 PM, Nikhil Komawar wrote: > Hi all, > > At the Austin summit, I've scheduled a Glance work session [1] for > gathering input on Glance deployments and feedback surrounding the

[openstack-dev] [openstack-operators] [glance] [Austin summit] Glance session for operator feedback

Hi all, At the Austin summit, I've scheduled a Glance work session [1] for gathering input on Glance deployments and feedback surrounding the same. Also, I've taken the liberty to propose a few topics related to the same at the discussion etherpad [2]. These are general discussion items that you

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On Wed, Apr 20, 2016 at 9:43 AM, Doug Hellmann wrote: > Cliff looks for commands on demand. If we modify it's command loader to > support some "built in" commands, and then implement the commands in OSC > that way, we can avoid scanning the real plugin system until we hit

[openstack-dev] [glance] weekly meeting on apr 21st

Hi all, Last week when I asked if we needed a meeting for this week, the poll [1] resulted in "maybe". I currently do not see any 'specific' agenda [2] items posted for this week's meeting. I am assuming everyone is busy going into the summit and the updates can be shared then or the meeting

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On 2016-04-19 11:30:38 -0500 (-0500), Ian Cordasco wrote: [...] > I've argued with different downstream distributors about their own > judgment of what portions of the patch to apply in order to fix an > issue with an assigned CVE. It took much longer than should have > been necessary in at least

Re: [openstack-dev] [Fuel] snapshot tool

Dmitry, I mean, currently shotgun fetches services' configuration along with astute.yaml. These files contain passwords, keys, tokens. I beleive, these should be sanitized. Or, better yet, there should be an option to sanitize sensitive data from fetched files. Aleksandr, Currently Fuel has a

Re: [openstack-dev] [neutron][sfc] A standards-compliant SFC API

On 20 April 2016 at 09:31, Duarte Cardoso, Igor < igor.duarte.card...@intel.com> wrote: > Dear OpenStack Community, > > > > We've been investigating options in/around OpenStack for supporting > Service Function Chaining. The networking-sfc project has made significant > progress in this space,

[openstack-dev] [heat]informal meetup during summit

Hi team Let plan for more informal meetup(relax) time! Let all heaters and any other projects can have fun and chance for technical discussions together. After discuss in meeting, we will have a pre-meetup-meetup on Friday morning to have a cup of cafe or some food. Would like to ask if anyone

Re: [openstack-dev] [TripleO]: landing code faster

On 04/20/2016 11:44 AM, Dan Prince wrote: We've had a run of really spotty CI in TripleO. This is making it really hard to land patches if reviewers aren't online. Specifically we seem to get better CI results when the queue is less full (nights and weekends)... often when core reviewers aren't

[openstack-dev] [neutron][sfc] A standards-compliant SFC API

Dear OpenStack Community, We've been investigating options in/around OpenStack for supporting Service Function Chaining. The networking-sfc project has made significant progress in this space, and we see lots of value in what has been completed. However, when we looked at the related IETF

Re: [openstack-dev] [neutron][release] neutron *-aas release notes are not linked.

Excerpts from Akihiro Motoki's message of 2016-04-20 13:20:40 +0900: > Hi, > > I noticed Mitaka release notes for neutron *-aas [1,2,3] are not > referred to from anywhere. > Neutron has four deliverables (neutron, lbaas, fwaas, vpnaas), > but only the release note of the main neutron repo is

[openstack-dev] summit tools

A couple of questions about our Austin-related planning tools... - Can one's calendar at https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-25 be exported as .ics, or otherwise integrated into a wider calendaring system? - Is the app working for anyone else? All I get

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

So, location of unified api is an interesting topic... Can things be arranged in such a way that the abstraction largely exists only on the client in its own project? So, what about a change of ideas The three pain points in the abstraction are: * Authentication * Connectivity *

Re: [openstack-dev] [neutron][release] neutron *-aas release notes are not linked.

On 20 April 2016 at 00:39, Andreas Jaeger wrote: > On 2016-04-20 06:20, Akihiro Motoki wrote: > > Hi, > > > > I noticed Mitaka release notes for neutron *-aas [1,2,3] are not > > referred to from anywhere. > > Neutron has four deliverables (neutron, lbaas, fwaas, vpnaas), > > but

Re: [openstack-dev] [Magnum]Cache docker images

If the ops are deploying a cloud big enough to run into that problem, I think they can deploy a scaled out docker registry of some kind too, that the images can point to? Last I looked, it didn't seem very difficult. The native docker registry has ceph support now, so if your running ceph for

Re: [openstack-dev] [Swift] Erasure coding and geo replication

There's no significant change with the global EC clusters story in the 2.7 release. That's something we're discussing next week at the summit. --John On 19 Apr 2016, at 22:47, Mark Kirkwood wrote: > Hi, > > Has the release of 2.7 significantly changed the assessment here? > > Thanks > > Mark

[openstack-dev] [TripleO]: landing code faster

We've had a run of really spotty CI in TripleO. This is making it really hard to land patches if reviewers aren't online. Specifically we seem to get better CI results when the queue is less full (nights and weekends)... often when core reviewers aren't around. One thing that would help is if

[openstack-dev] [ironic-staging-drivers] Tests at the gates

Hello Ironic-staging-drivers team, At the moment there is no tests for ironic-staging-drivers at the gates. I think we need to have a simple test that install drivers with theirs dependencies and ensures that ironic-conductor is able to start. It may be performed in the following way. Each

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

Excerpts from Steve Baker's message of 2016-04-20 16:38:25 +1200: > On 20/04/16 06:17, Monty Taylor wrote: > > On 04/19/2016 10:16 AM, Daniel P. Berrange wrote: > >> On Tue, Apr 19, 2016 at 09:57:56AM -0500, Dean Troyer wrote: > >>> On Tue, Apr 19, 2016 at 9:06 AM, Adam Young

[openstack-dev] Neutron: No DVR meeting for this week and week after.

Hi Folks, We will not be having our regular DVR meeting this week and for next week. We will resume our meeting on May 4th 2016. Thanks. Swaminathan Vasudevan Systems Software Engineer (TC) HP Networking Hewlett-Packard 8000 Foothills Blvd M/S 5541 Roseville, CA - 95747 tel: 916.785.0937 fax:

Re: [openstack-dev] [Fuel][plugins] VIP addresses and network templates

Many thanks Alexey! That's exactly the information I needed. Simon On Wed, Apr 20, 2016 at 1:19 PM, Aleksey Kasatkin wrote: > Hi Simon, > > When network template is in use, network roles to endpoints mapping is > specified in section "roles" (in the template). So,

Re: [openstack-dev] [glance] Image import: operator plugins

On 20/04/16 11:39 +0100, stuart.mcla...@hp.com wrote: Hi, As part of Glance's image import [1] work we need to define how operators can run site specific code as part of the import process. For example an operator may want to perform some site-specific validation on the image bits. Note that

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

On Tue, Apr 19, 2016 at 12:24 PM, Ian Cordasco wrote: > > > -Original Message- > From: Thomas Goirand > Reply: OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > Date: April 18, 2016 at 17:21:36

Re: [openstack-dev] [neutron] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

On Wed, Apr 20, 2016 at 4:25 PM, Miguel Angel Ajo Pelayo < majop...@redhat.com> wrote: > Inline update. > > On Mon, Apr 11, 2016 at 4:22 PM, Miguel Angel Ajo Pelayo > wrote: > > On Mon, Apr 11, 2016 at 1:46 PM, Jay Pipes wrote: > >> On 04/08/2016 09:17

Re: [openstack-dev] [Magnum]Cache docker images

Hongbin, Both of approaches you suggested may only work for one binary format. If you try to use docker on a different system architecture, the pre-cache of images makes it even more difficult to get the correct images built and loaded. I suggest we take an approach that allows the Baymodel

Re: [openstack-dev] [neutron] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

Inline update. On Mon, Apr 11, 2016 at 4:22 PM, Miguel Angel Ajo Pelayo wrote: > On Mon, Apr 11, 2016 at 1:46 PM, Jay Pipes wrote: >> On 04/08/2016 09:17 AM, Miguel Angel Ajo Pelayo wrote: [...] >> Yes, Nova's conductor gathers information about the

Re: [openstack-dev] Kolla multinode , multi-region deployment support

On Wed, 2016-04-20 at 06:57 +, Steven Dake (stdake) wrote: > Grzegorz, > > This is a technical question about our roadmap and should be sent to > the openstack-dev mailing list.  As such, ccing openstack-dev so > everyone can benefit from my thinking on this matter and others can > weigh in.

Re: [openstack-dev] [ironic] upgrade support between which versions of ironic?

On 2016-04-19 11:29 PM, Tan, Lin wrote: I agree this is reasonable to support all these cases in “cold upgrades” but in supports-rolling-upgrade (live upgrade in another word) case it is different and complicated and not necessary, During rolling upgrade, we will have old/new services

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

I think this is an interesting topic. What do you mean exactly by FC ? (feature chaining?) I believe we have three things to look at: (sorry for the TL) 1) The generalization of traffic filters / traffic classifiers. Having common models, some sort of common API or common API structure

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

Sorry, I just saw, FC = flow classifier :-), I made it a multi purpose abrev. now ;) On Wed, Apr 20, 2016 at 2:12 PM, Miguel Angel Ajo Pelayo wrote: > I think this is an interesting topic. > > What do you mean exactly by FC ? (feature chaining?) > > I believe we have three

[openstack-dev] [telemetry][nova] Versioned notification with JSON schema

Hi, Just want to give telemetry a heads up that top of the versioned notification transformation in nova [1] we are planning to provide JSON schemas for the versioned notifications [2]. I hope telemetry project has a view how they want to consume those schemas. Any comments are welcome in the

Re: [openstack-dev] [devstack] openstack client slowness / client-as-a-service

On 04/19/2016 11:03 PM, Dean Troyer wrote: > > > On Tue, Apr 19, 2016 at 8:17 PM, Adam Young > wrote: > > Maybe it is time to revamp Devstack. Is there some way that, > without a major rewrite, it could take better advantage of the CLI? >

Re: [openstack-dev] [Cinder] API features discoverability

On 19 April 2016 at 23:42, Michał Dulko wrote: > On 04/18/2016 09:17 AM, Ramakrishna, Deepti wrote: > > Hi Michal, > > > > This seemed like a good idea when I first read it. What more, the server > code for extension listing [1] does not do any authorization, so it can be

Re: [openstack-dev] [python-keystoneclient] Return request-id to caller

On 20 April 2016 at 08:08, koshiya maho wrote: > This design was discussed, reviewed and approved in cross-projects [1] and > already implemented in nova, cinder and neutron. > At this point if we change the implementation then it will not be > consistent across core

Re: [openstack-dev] [Fuel][plugins] VIP addresses and network templates

Hi Simon, When network template is in use, network roles to endpoints mapping is specified in section "roles" (in the template). So, "default_mapping" from network role description is overridden in the network template. E.g.: network_assignments: monitoring: ep: br-mon ...

Re: [openstack-dev] [Neutron] L3 HA testing on scale

Folks, I think Ann's report is super cool and 100% worth publishing on OpenStack performance-docs . This is really good information to share community-wide. Ann, please think if you would like to contribute to performance documentation.

Re: [openstack-dev] [tripleo][heat] Summit session clashes

How about move functional tests to wed 3:30? If not, I will sync with you guys later :) Best Regards, Ethan Lynn xuanlangj...@gmail.com > On Apr 20, 2016, at 18:46, Thomas Herve wrote: > > On Wed, Apr 20, 2016 at 12:14 PM, Ethan Lynn wrote: >>

Re: [openstack-dev] [tricircle] http response code

This might be answer for your question. https://github.com/openstack/tricircle/blob/master/tricircle/api/controllers/pod.py Cheers, S On Wed, Apr 20, 2016 at 6:37 PM, 李戈 wrote: > Hi > I read api source code recently and have a question. Do we uniform the > "http

Re: [openstack-dev] [tripleo][heat] Summit session clashes

On Wed, Apr 20, 2016 at 12:14 PM, Ethan Lynn wrote: > Could we move Functional Tests to Thursday? I have a hands-on workshop at > wed 4:30-6:00 pm. Sorry, I don't have anything to switch it with. -- Thomas

[openstack-dev] [glance] Image import: operator plugins

Hi, As part of Glance's image import [1] work we need to define how operators can run site specific code as part of the import process. For example an operator may want to perform some site-specific validation on the image bits. Note that I'm not so much interested in what we use to do this (ie

  1   2   >