[openstack-dev] Unsubscribe

> On 5 Jun 2018, at 14:56, Eric Fried wrote: > > To summarize: cyborg could model things nested-wise, but there would be > no way to schedule them yet. > > Couple of clarifications inline. > > On 06/05/2018 08:29 AM, Jay Pipes wrote: >> On 06/05/2018 08:50 AM, Stephen Finucane wrote: >>> I

[openstack-dev] [keystone] Signing off

of pride in that.   Thanks to all the hard work, commitment, humour and support from all the keystone folks over the years - I am sure we will continue to interact and meet among the many other open source projects that many of us are becoming involved with. Ad astra!   Best regards,   Henry

Re: [openstack-dev] [neutron][neutron-lib]Service function defintion files

Armando, I agree with Paul. My understanding was that the API definition files for stadium projects were to be included in neutron-lib to ensure suitable oversight. - Louis From: CARVER, PAUL [mailto:pc2...@att.com] Sent: Friday, December 29, 2017 11:35 AM To: OpenStack Development Mailing List

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

Armando, Appreciate all the hard work and sage advice. Best wishes. - Louis From: Armando M. [mailto:arma...@gmail.com] Sent: Friday, December 15, 2017 11:01 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] Stepping down from core Hi

[openstack-dev] No networking-sfc meetings until Jan 11

There will no networking-sfc meetings until Jan 11. Seasons greetings. https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting - Louis __ OpenStack Development Mailing List (not for usage questions)

[openstack-dev] networking-sfc meetings cancelled this week

All, networking-sfc meetings will resume on May 18. - Louis __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[openstack-dev] [networking-sfc] No networking-sfc meeting today

All, There will be no networking-sfc meetings for the next two weeks. Will resume on May 18. - Louis __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [keystone] Colleen Murphy for core

Congratulations, Colleen - well deserved. Henry > On 2 May 2017, at 19:15, Lance Bragstad <lbrags...@gmail.com> wrote: > > Hey folks, > > During today's keystone meeting we added another member to keystone's core > team. For several releases, Colleen's had a profound

Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

Akihiro, Option (a) would have my vote. - Louis -Original Message- From: Akihiro Motoki [mailto:amot...@gmail.com] Sent: Monday, April 10, 2017 8:09 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have

Re: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation

Igor, Inline. -Louis From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com] Sent: Monday, March 20, 2017 8:02 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation Hi

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

, for sure, that nobody outside of my VCO can get access (i.e. since I have my own keystone, and token obtained from a different reseller’s keystone has no chance of getting in). However, I don’t believe we have every explored how to solve the various issues above. Henry > On 17 Mar 2017, at 10

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

cult to decide what should be within the “Openstack” scope, and what should be provided outside of it. Henry > On 16 Mar 2017, at 21:10, Lance Bragstad <lbrags...@gmail.com> wrote: > > Hey folks, > > The reseller use case [0] has been popping up frequently in various >

Re: [openstack-dev] [neutron][sfc] stable/ocata version

Gary, Awaiting approval: https://review.openstack.org/#/c/439200 -Louis From: Gary Kotton [mailto:gkot...@vmware.com] Sent: Saturday, March 04, 2017 11:01 PM To: OpenStack List Subject: [openstack-dev] [neutron][sfc] stable/ocata version Hi, We are pretty blocked at the moment with

Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

] [networking-sfc] Stable/Ocata Version any update for releasing stable/ocata branch or tag? It is Mar already. On Tue, Feb 21, 2017 at 1:23 AM, Henry Fourie <louis.fou...@huawei.com<mailto:louis.fou...@huawei.com>> wrote: Gary, The plan is to have a stable/ocata branch by end of month. -

Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

Gary, The plan is to have a stable/ocata branch by end of month. -Louis From: Gary Kotton [mailto:gkot...@vmware.com] Sent: Sunday, February 19, 2017 4:29 AM To: OpenStack List Subject: [openstack-dev] [networking-sfc] Stable/Ocata Version Hi, When will this repo have a stable/ocata

Re: [openstack-dev] [networking-sfc] What resources can and can't be reused

Igor, For #6, the requirement on source-port for a flow-classifier is only for the OVS driver. This is not a restriction for other backend drivers. In the case where there is no need for a sfc proxy to re-classify traffic returned from the egress port of a SF, i.e., the SF is NSH-aware and it

Re: [openstack-dev] [networking-sfc] What resources can and can't be reused

Igor, See inline. -Louis From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com] Sent: Monday, February 13, 2017 11:12 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [networking-sfc] What resources can and can't be reused Hi

Re: [openstack-dev] [neutron] [stadium] subprojects on independent release cycle

Armando, networking-sfc will cut a stable/ocata branch by March 10. -Louis From: Armando M. [mailto:arma...@gmail.com] Sent: Wednesday, February 08, 2017 8:16 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [stadium]

Re: [openstack-dev] [keystone] removing Guang Yee (gyee) from keystone-core

Thanks, Guang, for your valuable contributions. Henry > On 2 Feb 2017, at 05:13, Steve Martinelli <s.martine...@gmail.com> wrote: > > Due to inactivity and a change in his day job, Guang was informed that he > would be removed from keystone-core, a change he understands and

Re: [openstack-dev] [networking-sfc]

Michael, Regarding horizon support for networking-sfc, the screens shown on the demo were developed in an earlier patch that was not merged. https://review.openstack.org/#/c/258430/ This work is still in progress. - Louis -Original Message- From: Bernard Cafarelli

Re: [openstack-dev] [networking-sfc]

Cathy, I believe Mohan Kumar did that work. - Louis -Original Message- From: Cathy Zhang Sent: Tuesday, January 24, 2017 5:39 PM To: OpenStack Development Mailing List (not for usage questions); Henry Fourie; Vikram Choudhary Cc: Cathy Zhang Subject: RE: [openstack-dev] [networking

Re: [openstack-dev] [networking-sfc] Does SFC support chaining of Layer 2 devices?

Vikash, Unclear what you mean by SFC spinning an L2 IDS? What is the behavior of L2 IDS devices? -Louis From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com] Sent: Wednesday, January 18, 2017 10:49 PM To: openstack-dev Subject: [openstack-dev] [networking-sfc] Does SFC support

Re: [openstack-dev] [neutron] PTL nominations deadline and non-candidacy

Armando Appreciate your efforts, leadership and guidance. -Louis From: Armando M. [mailto:arma...@gmail.com] Sent: Monday, January 09, 2017 6:11 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] PTL nominations deadline and

[openstack-dev] [Neutron][networking-sfc] Next networking-sfc meeting on 1/5/2017

All, As many people will be away over the holiday season we will have the next networking-sfc meeting on 1/5/2017. Best wishes for the season. -Louis __ OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [Neutron] Stepping down from core

I've already communicated this in the neutron meeting and in some neutron policy patches, but yesterday the PTL actually updated the gerrit ACLs so I thought I'd drop a note here too. My work situation has changed and leaves me little time to keep up with my duties as core reviewer, DB

Re: [openstack-dev] [neutron] NeutronLibImpact: Adoption of db *_FIELD_SIZE constants from neutron-lib

ZES are done, then we will be in a position to remove attributes.py from core neutron. That is the aim of this little dance. > Thanks > Gary > > > > > On 11/26/16, 9:03 AM, "Henry Gessau" <hen...@gessau.net> wrote: > > The following _MAX_LEN constants

[openstack-dev] [neutron] NeutronLibImpact: Removing deprecated model_base mixins from core

The deprecated model_base mixins are be being removed from neutron/db/model_base.py and neutron/db/models_v2.py in [1]. The mixins from neutron_lib.db.model_base should be used instead. All subproject maintainers should update their code to use the model_base mixins from neutron-lib. I have

[openstack-dev] [neutron] NeutronLibImpact: Adoption of db *_FIELD_SIZE constants from neutron-lib

The following _MAX_LEN constants are being removed from neutron/api/v2/attributes.py in [1]. The corresponding DB field size constants from neutron_lib.db.constants should be used instead. All subproject maintainers should update their code to use the the db *_FIELD_SIZE constants from

[openstack-dev] [neutron] NeutronLibImpact: Adoption of ExtensionDescriptor from neutron-lib

The ExtensionDescriptor class has been rehomed to neutron-lib and is being removed from neutron core, see [1]. All subproject maintainers should update their code to use the ExtensionDescriptor class from neutron-lib. I have submitted patches [2] for most subprojects. This will be highlighted

[openstack-dev] [neutron] NeutronLibImpact: Removal of PLURALS

The PLURALS dict in neutron.api.v2.attributes is written to but never used. Before rehoming neutron.api.v2.attributes to neutron-lib I am removing all references to PLURALS [1]. All subproject maintainers should remove the use of PLURALS from their code. I have submitted patches [2] for most

Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

Igor +1 -Louis From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com] Sent: Wednesday, November 23, 2016 3:26 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [networking-sfc] #networking-sfc IRC channel Hi networking-sfc's leaders,

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

Echoing the comments of others. - thanks for all your hard work and expertise. Henry > On 23 Nov 2016, at 15:05, Lance Bragstad <lbrags...@gmail.com> wrote: > > Thanks for all your hard work, Marek. It's been a pleasure working with you. > Best of luck and hopeful

Re: [openstack-dev] [keystone] Pike PTL

Steve, It’s been a pleasure working with you as PTL - an excellent tenure. Enjoy taking some time back! Henry > On 21 Nov 2016, at 19:38, Steve Martinelli <s.martine...@gmail.com> wrote: > > one of these days i'll learn how to spell :) > > On Mon, Nov 21, 2016 at 12:52

[openstack-dev] [neutron] Reviews needed in neutron-lib

During the meeting today I promised to provide a list of reviews in neutron-lib that need review attention. The following are patches that "rehome" code from neutron core into neutron-lib and are therefore important to keep up the velocity of neutron-lib adoption:

[openstack-dev] [neutron] Weekly neutron-lib meeting canceled

See https://review.openstack.org/395034 We now have a slot in the main neutron project meeting. If we do need extra meeting time for neutron-lib we can set up something based on who wants to attend and when. __ OpenStack

[openstack-dev] [neutron] Barcelona summit neutron-lib session recap

Ocata neutron-lib session recap --- tl;dr: - Speed up moving common code into neutron-lib - Sub-project maintainers must keep up and should contribute The session consisted of announcing the goals around speeding up the neutron-lib work so that consuming projects

Re: [openstack-dev] [neutron] neutron-lib

Gary Kotton wrote: > Would it be possible to cut a new version of neutron-lib. This will enable us > to proceed with the integration into the various projects? https://review.openstack.org/392009 __

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

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

[openstack-dev] [Neutron] Next neutron-lib meeting is November 9

Due to the summit. __ OpenStack Development Mailing 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] Database field sizes and attribute "MAX_LEN" constants

Anna Taraday <akamyshnik...@mirantis.com> wrote: > Henry, thanks for taking care of this! > > In my opinion, it is just safe to use raw values in migration, because > migration is a strict point in time. > > I remember how many patches I send in havana in Neutron for

Re: [openstack-dev] [Neutron] Database field sizes and attribute "MAX_LEN" constants

Ihar Hrachyshka <ihrac...@redhat.com> wrote: > Henry Gessau <hen...@gessau.net> wrote: > >> Hi neutrinos, >> >> In Neutron many attributes are stored in database fields. The size of these >> fields therefore determines the maximum length of the attrib

[openstack-dev] [Neutron] Database field sizes and attribute "MAX_LEN" constants

Hi neutrinos, In Neutron many attributes are stored in database fields. The size of these fields therefore determines the maximum length of the attribute values. I would like to get some consistency in place around how we define the constants and where they are used. Here are my thoughts... 1.

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

Thanks for organizing this Miguel! I plan to attend. Miguel Lavalle wrote: > Dear Neutrinos, > > I am organizing a social event for the team on Thursday 27th at 19:30. After > doing some Google research, I am proposing Raco de la Vila, which is located > in Poblenou:

Re: [openstack-dev] [networking-sfc][devstack][mitaka]

Navdeep, Post port-chain, port-pair-group, port-pair config to questions at https://launchpad.net/networking-sfc Use these commands to determine traffic flow and post results also. sudo ovs-ofctl -O openflow13 dump-flows br-int sudo ovs-ofctl -O Openflow13 dump-groups br-int -

Re: [openstack-dev] [oslo.db] [release] opportunistic tests breaking randomly

Sean Dague wrote: > On 09/15/2016 09:20 AM, Roman Podoliaka wrote: >> Sean, >> >> So currently we have a default timeout of 160s in Nova. And >> specifically for migration tests we set a scaling factor of 2. Let's >> maybe give 2.5 or 3 a try (

Re: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

+1 From: Armando M. [mailto:arma...@gmail.com] Sent: Saturday, September 17, 2016 9:41 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team Hi folks, I would like to propose Ihar to become a member of

Re: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

+1000! Armando M. wrote: > Hi folks, > > I would like to propose Ihar to become a member of the Neutron drivers team > [1]. > > Ihar wide knowledge of the Neutron codebase, and his longstanding duties as > stable core, downstream package whisperer, release and oslo liaison

Re: [openstack-dev] [tacker] PTL candidacy

+1 From: Sridhar Ramaswamy [mailto:sric...@gmail.com] Sent: Friday, September 16, 2016 3:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [tacker] PTL candidacy Hi Tackers, I would like to announce my candidacy to continue as Tacker PTL for the

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

to have code that can work on different DB versions (either explicitly or via versioned objects), or you hide the schema changes by “data synchronisation via Triggers”, which is where this whole thread came from. Henry > On 14 Sep 2016, at 23:08, Jay Pipes <jaypi...@gmail.com> wrote: >

Re: [openstack-dev] [keystone] new core reviewer (rderose)

Welcome, Ron! Henry > On 1 Sep 2016, at 15:44, Steve Martinelli <s.martine...@gmail.com> wrote: > > I want to welcome Ron De Rose (rderose) to the Keystone core team. In a short > time Ron has shown a very positive impact. Ron has contributed feature work > for shadowi

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

-project solution. The actual migrations in Keystone needed for Newton are minor, so one possibility is we use keystone as a guinea pig for this approach in Newton…if we had to undo this in a subsequent release, we are not talking about rafts of migration code to redo. Henry > On 1 Sep 2

Re: [openstack-dev] [neutron] neutronclient check queue is broken

Akihiro Motoki wrote: > In the neutronclient check queue, > gate-neutronclient-test-dsvm-functional is broken now [1]. > Please avoid issuing 'recheck'. > > [1] https://bugs.launchpad.net/python-neutronclient/+bug/1616749 The fix [2] has merged. Carry on. [2]

Re: [openstack-dev] [OpenStack-docs] [neutron] [api] [doc] API reference for neutron stadium projects (re: API status report)

Akihiro Motoki wrote: > this mail focuses on neutron-specific topics. I dropped cinder and ironic > tags. > > 2016-08-11 23:52 GMT+09:00 Anne Gentle : >> >> >> On Wed, Aug 10, 2016 at 2:49 PM, Anne Gentle >>

Re: [openstack-dev] [Neutron] Team and Driver meetings for the week of Aug 15th

Armando M. wrote: > Hi Neutrinos, > > The meetings will be cancelled due to the mid-cycle. The neutron-lib meeting will also skip next week. __ OpenStack Development Mailing List (not for usage

[openstack-dev] [Neutron] Be prepared for bumps in the road -- tenant_id columns have been renamed to project_id

Hello neutrinos and especially maintainers of consuming projects. The patch [1] to rename all tenant_id columns to project_id in the Neutron DB has merged. Although we have tried our best to check for dependencies and side effects, this is a very fundamental change and there may be consequences

Re: [openstack-dev] {neutron][db][models]

Ihar Hrachyshka wrote: > Manjeet S wrote: > >> Hello Team, >> >> I have a question regarding centralizing all db models in neutron. As you >> all know >> Oslo versioned object work is under progress and I also had a ticket >> opened for

[openstack-dev] [Neutron] no neutron-lib meeting today

Myself and dougwig will be unable to attend today. We'll resume as usual next week. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [neutron] how to create initial db migration script to sub-project

Moshe Levi <mosh...@mellanox.com> wrote: > Hi Henry, > > Thank for the reply. > > I tried to do the following with your commit [2]: Note I just updated my patch for a minor problem. > 1. I create models.py in networking_mlnx/db. Nit: I would recommend creating all mod

Re: [openstack-dev] [neutron] how to create initial db migration script to sub-project

Hi Moshe, It has been a while since a neutron sub-project initialized new alembic migrations, so the devref is out of date, sorry. Let me help you get this sorted out and then I can update the devref with the latest info. First you need to create the initial migration for each branch (expand and

Re: [openstack-dev] [Neutron] Proposing Jakub Libosvar for testing core

Big +1 from me. Assaf Muller wrote: > As Neutron's so called testing lieutenant I would like to propose > Jakub Libosvar to be a core in the testing area. > > Jakub has demonstrated his inherent interest in the testing area over > the last few years, his reviews are

Re: [openstack-dev] [neutron] Keystone V3 alignment: renaming tenant_id columns to project_id

Henry Gessau <hen...@gessau.net> wrote: > In accordance with the Blueprint [1] and the spec [2], we are in the process > of deprecating the use of the term 'tenant' in favor of 'project'. > > The code change [3] with the biggest impact on Neutron developers is currentl

[openstack-dev] [neutron] Keystone V3 alignment: renaming tenant_id columns to project_id

In accordance with the Blueprint [1] and the spec [2], we are in the process of deprecating the use of the term 'tenant' in favor of 'project'. The code change [3] with the biggest impact on Neutron developers is currently out for review and will merge quite soon (shortly after N-2). This change

Re: [openstack-dev] New Python35 Jobs coming

Clark Boylan wrote: > The infra team is working on taking advantage of the new Ubuntu Xenial > release including running unittests on python35. The current plan is to > get https://review.openstack.org/#/c/336272/ merged next Tuesday (July > 5, 2016). This will add non

Re: [openstack-dev] [cinder] [keystone] cinder quota behavior differences after Keystone mitaka upgrade

are what was intended (I’ll let the cinder team comment). Code can, if desired, distinguish the case of top projects that are at the top level, vs projects somewhere way down the hierarchy, by looking at the parent and seeing if it is a project acting as a domain. Henry keystone core > On 27

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

the ability to access projects created before the server upgrade via their non-path name, it would get very confusing for users having to remember which projects you could or couldn't access this way. Feel free to raise any concerns you have about the above. Henry > On 14 Jun 2016, at 16

Re: [openstack-dev] Version header for OpenStack microversion support

…I think it is so you can have a header in a request that, once issued, can be passed for service to service, e.g.: OpenStack-API-Version: identity 3.7, compute 2.11 Henry > On 18 Jun 2016, at 11:32, Jamie Lennox <jamielen...@gmail.com> wrote: > > Quick question: why do we n

[openstack-dev] Version header for OpenStack microversion support

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

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

> On 14 Jun 2016, at 07:34, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > > > > On Mon, Jun 13, 2016 at 3:30 PM, Henry Nash <henryna...@mac.com > <mailto:henryna...@mac.com>> wrote: > So, I think it depends what level of compatibility we are aimin

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

need multiple cycles to achieve any of the options, let’s decide the final conceptual model we want - and then move towards it. Options 1's conceptual mode is that ‘name’ remains the same, and we add separate ‘path’ attribute, Option 2’s other redefines ‘name’ to always be a full path. Henry

Re: [openstack-dev] [neutron][networking-sfc] Proposing Mohan Kumar for networking-sfc core

+1 From: Cathy Zhang Sent: Monday, June 13, 2016 11:36 AM To: openstack-dev@lists.openstack.org; Cathy Zhang Subject: [openstack-dev] [neutron][networking-sfc] Proposing Mohan Kumar for networking-sfc core Mohan has been working on networking-sfc project for over one year. He is a key

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

solution (and there is no particular advantage with the hierarchical naming approach) - and (until the end of the deprecation) there is no break to the existing API. Henry > On 7 Jun 2016, at 09:47, Henry Nash <henryna...@mac.com> wrote: > > OK, so thanks for the feedback - underst

Re: [openstack-dev] [neutron][SFC]

Alioune, The logical-source-port refers to a Neutron port of the VM that originates the traffic that is to be processed by the port-chain. -Louis From: Alioune [mailto:baliou...@gmail.com] Sent: Thursday, June 09, 2016 6:50 AM To: Mohan Kumar Cc: OpenStack Development Mailing List

Re: [openstack-dev] [Neutron] neutron-lib and dependencies in neutron reference implementation

o separate _constants.py modules. But then I could argue that would proliferate the number of imports required for many repos. Gal Sagie <gal.sa...@gmail.com> wrote: > For example references to the various different agents which are an > implementation details to me > > On Wed, J

Re: [openstack-dev] [Neutron] neutron-lib and dependencies in neutron reference implementation

Gal Sagie wrote: > Hello all, > > I have recently came across some missing constants in neutron-lib and sent > a patch but i wanted to try and understand the scope of the lib. > > I see that the Neutron lib consist of many definitions which are actually > part of the

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

all the names include the hierarchical path. Just want to make sure we understand the implications…. Henry > On 4 Jun 2016, at 08:34, Monty Taylor <mord...@inaugust.com> wrote: > > On 06/04/2016 01:53 AM, Morgan Fainberg wrote: >> >> On Jun 3, 2016 12:42, "Lanc

Re: [openstack-dev] [Neutron][Networking-SFC] Stable/mitaka version

Gary, Yes, it will be. -Louis From: Gary Kotton [mailto:gkot...@vmware.com] Sent: Monday, June 06, 2016 2:39 AM To: OpenStack List Subject: [openstack-dev] [Neutron][Networking-SFC] Stable/mitaka version Hi, In git the project has a stable/liberty and trunk version. Will this be

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

constraints works like the linux dir tree. If I do an ‘ls’ I get the node names of the all entities in that directory, but I can still do 'cd /a/b/c' to jump right to where I want. Henry > On 3 Jun 2016, at 23:53, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > > > On

Re: [openstack-dev] [Neutron] Elevating context to remove subnets created by admin

Carl Baldwin <c...@ecbaldwin.net> wrote: > On Fri, Jun 3, 2016 at 2:26 PM, Henry Gessau <hen...@gessau.net> wrote: >> Darek Smigiel <smigiel.dari...@gmail.com> wrote: >>> strange, that owner is not able to just get rid of *his* network and >>> s

Re: [openstack-dev] [Neutron] Elevating context to remove subnets created by admin

Darek Smigiel wrote: > strange, that owner is not able to just get rid of *his* network and subnets. But not all the subnets are his, and consequently the network is partially not his. Why did the admin create a subnet on the user's network in [1]? IMO the admin

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

> On 3 Jun 2016, at 16:38, Lance Bragstad <lbrags...@gmail.com> wrote: > > > > On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash <henryna...@mac.com > <mailto:henryna...@mac.com>> wrote: > >> On 3 Jun 2016, at 01:22, Adam Young <ayo...@redhat.com &g

Re: [openstack-dev] [keystone] Changing the project name uniqueness constraint

> On 3 Jun 2016, at 01:22, Adam Young <ayo...@redhat.com> wrote: > > On 06/02/2016 07:22 PM, Henry Nash wrote: >> Hi >> >> As you know, I have been working on specs that change the way we handle the >> uniqueness of project names in Newton. The goal o

[openstack-dev] [keystone] Changing the project name uniqueness constraint

have become a tough restriction. Henry __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listin

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

Ryan, I agree that having rules in the ACL table with actions that would steer the packets to SFC Processing would be a good approach. -Louis From: Ryan Moats [mailto:rmo...@us.ibm.com] Sent: Tuesday, May 31, 2016 10:18 AM To: John McDowall Cc: Justin Pettit; Russell Bryant; Ben

Re: [openstack-dev] [Neutron] Mid-cycle development sprint (NOTE: DATE CHANGE!)

Thierry Carrez <thie...@openstack.org> wrote: > Rossella Sblendido wrote: >> On 05/26/2016 10:47 PM, Henry Gessau wrote: >>> I am happy to announce that the location logistics for the Neutron mid-cycle >>> have been finalized. The mid-cycle will take place in Cork,

[openstack-dev] [Neutron] Mid-cycle development sprint

I am happy to announce that the location logistics for the Neutron mid-cycle have been finalized. The mid-cycle will take place in Cork, Ireland on August 15-17. I have updated the wiki [1] where you will find a link to an etherpad with all the details. There you can add yourself if you plan to

Re: [openstack-dev] [keystone] New Core Reviewer (sent on behalf of Steve Martinelli)

Congratulations - thanks for your continued commitment to OpenStack and keystone. Henry > On 25 May 2016, at 23:58, Rodrigo Duarte <rodrigodso...@gmail.com> wrote: > > Thank you all, it's a privilege to be part of a team from where I've learned > so much. =) > >>

Re: [openstack-dev] [neutron] [networking-sfc] Adding use case to wiki?

Igor, Add them here https://wiki.openstack.org/wiki/Neutron/ServiceChainUseCases -Louis From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com] Sent: Monday, May 23, 2016 9:14 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev]

Re: [openstack-dev] [Neutron][TC] support of NSH in networking-SFC

Doug, Networking-sfc API currently has two reference SFC implementations that are open source: the OVS driver and the ONOS driver. Work is also in progress for an ODL SFC driver and an OVN driver. -Louis From: Doug Wiegley [mailto:doug...@parksidesoftware.com] Sent: Friday, May 20,

Re: [openstack-dev] [neutron][stable] proposing Brian Haley for neutron-stable-maint

+1 for Brian. (And retroactive +1 for Cedric.) Ihar Hrachyshka wrote: > Hi stable-maint-core and all, > > I would like to propose Brian for neutron specific stable team. > > His stats for neutron stable branches are (last 120 days): > > mitaka: 19 reviews; liberty: 68

Re: [openstack-dev] [keystone][api][v3]

Oops "uncooked"! I meant unscoped! (thank you Apple's auto-correct spell checker!) Sent from my iPad > On 11 May 2016, at 10:25, Henry Nash <henryna...@mac.com> wrote: > > Hi > > This depends on the policy rule for the get_user call - which is defined by &

Re: [openstack-dev] [keystone][api][v3]

for get_user to be the same if you want to allow users to read their own user record. Henry Sent from my iPad > On 11 May 2016, at 09:49, Ehsan Qarekhani <qarekh...@gmail.com> wrote: > > HI > is there any way to retrieve default_project_id of login user from unscoped >

Re: [openstack-dev] Easing contributions to central documentation

Matt Kassawara wrote: > At each summit, I speak with a variety of developers from different projects > about the apparent lack of contributions to the central documentation. At > previous summits, the most common complaint involved using DocBook. After > converting most of

[openstack-dev] [Neutron] neutron-lib report from the summit

At the Newton summit in Austin we held a session on the next steps for neutron-lib. Here is a report on what was discussed at the session. Etherpad: https://etherpad.openstack.org/p/newton-neutron-lib-next-steps Progress so far --- The package is on PyPI and sub-projects should be

Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project f2f2 meet-up place and time

All, Please use the networking-sfc etherpad to record discussions at the meetups: https://etherpad.openstack.org/p/networking-sfc-austin-summit-meeting - Louis -Original Message- From: Paul Carver [mailto:pcar...@paulcarver.us] Sent: Tuesday, April 26, 2016 10:20 AM To:

Re: [openstack-dev] [neutron] OSC transition

Adding the [neutron] tag. I believe that the OSC extension for neutron-dynamic-routing should live in the python-neutronclient repo. Keep in touch with Richard Theis as he is the one leading the transition to OSC. He is rtheis on IRC. See:

Re: [openstack-dev] [Neutron] Neutron lib hack has broken all decomposed projects

This was a learning experience and we found out the hard way about an extra dependency we had not anticipated. Thanks Gary for spotting it early and hopefully the revert will merge soon. Doug Wiegley wrote: > That revert is https://review.openstack.org/#/c/309776 ,

Re: [openstack-dev] [keystone] Newton midycle planning

Hi Morgan, Great to be planning this ahead of time!!! For me either of the July dates are fine - I would have a problem with the June date. Henry > On 14 Apr 2016, at 14:57, Dolph Mathews <dolph.math...@gmail.com> wrote: > > On Wed, Apr 13, 2016 at 9:07 PM, Morgan Fainber

Re: [openstack-dev] [Neutron] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

+1, Hirofumi will make a great addition. Akihiro Motoki wrote: > Hi Neutrinos, > > As the API Lieutenant of Neutron team, > I would like to propose Hirofumi Ichihara (irc: hichihara) as a member of > Neutron core reviewer team mainly focuing on the API/DB area. > > Hirofumi

Re: [openstack-dev] [neutron] unit test failures due to new release of Routes package (v2.3)

https://launchpad.net/bugs/1563028 https://review.openstack.org/298855 Aditya Vaja wrote: > Hi, > > I'm seeing unit test failures when I test locally after a fresh git clone of > neutron master. > > $ ./run_tests.sh -V -f > > log excerpt:

Re: [openstack-dev] [Neutron] Plan for changes affecting DB schema

na...@vn.fujitsu.com <na...@vn.fujitsu.com> wrote: > Two weeks ago, I received an information about changing affecting DB schema > [1] from Henry Gessau just a day before the deadline. I was so surprised about > this and could not change my plan for my patch sets. Do yo

  1   2   3   4   >