[openstack-dev] Unsubscribe

[Henry Nash]

> 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 thought nested resource providers were already supported by
>>> placement? To the best of my knowledge, what is /not/ supported is
>>> virt drivers using these to report NUMA topologies but I doubt that
>>> affects you. The placement guys will need to weigh in on this as I
>>> could be missing something but it sounds like you can start using this
>>> functionality right now.
>> 
>> To be clear, this is what placement and nova *currently* support with
>> regards to nested resource providers:
>> 
>> 1) When creating a resource provider in placement, you can specify a
>> parent_provider_uuid and thus create trees of providers. This was
>> placement API microversion 1.14. Also included in this microversion was
>> support for displaying the parent and root provider UUID for resource
>> providers.
>> 
>> 2) The nova "scheduler report client" (terrible name, it's mostly just
>> the placement client at this point) understands how to call placement
>> API 1.14 and create resource providers with a parent provider.
>> 
>> 3) The nova scheduler report client uses a ProviderTree object [1] to
>> cache information about the hierarchy of providers that it knows about.
>> For nova-compute workers managing hypervisors, that means the
>> ProviderTree object contained in the report client is rooted in a
>> resource provider that represents the compute node itself (the
>> hypervisor). For nova-compute workers managing baremetal, that means the
>> ProviderTree object contains many root providers, each representing an
>> Ironic baremetal node.
>> 
>> 4) The placement API's GET /allocation_candidates endpoint now
>> understands the concept of granular request groups [2]. Granular request
>> groups are only relevant when a user wants to specify that child
>> providers in a provider tree should be used to satisfy part of an
>> overall scheduling request. However, this support is yet incomplete --
>> see #5 below.
> 
> Granular request groups are also usable/useful when sharing providers
> are in play. That functionality is complete on both the placement side
> and the report client side (see below).
> 
>> The following parts of the nested resource providers modeling are *NOT*
>> yet complete, however:
>> 
>> 5) GET /allocation_candidates does not currently return *results* when
>> granular request groups are specified. So, while the placement service
>> understands the *request* for granular groups, it doesn't yet have the
>> ability to constrain the returned candidates appropriately. Tetsuro is
>> actively working on this functionality in this patch series:
>> 
>> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-resource-providers-allocation-candidates
>> 
>> 
>> 6) The virt drivers need to implement the update_provider_tree()
>> interface [3] and construct the tree of resource providers along with
>> appropriate inventory records for each child provider in the tree. Both
>> libvirt and XenAPI virt drivers have patch series up that begin to take
>> advantage of the nested provider modeling. However, a number of concerns
>> [4] about in-place nova-compute upgrades when moving from a single
>> resource provider to a nested provider tree model were raised, and we
>> have begun brainstorming how to handle the migration of existing data in
>> the single-provider model to the nested provider model. [5] We are
>> blocking any reviews on patch series that modify the local provider
>> modeling until these migration concerns are fully resolved.
>> 
>> 7) The scheduler does not currently pass granular request groups to
>> placement.
> 
> The code is in place to do this [6] - so the scheduler *will* pass
> granular request groups to placement if your flavor specifies them.  As
> noted above, such flavors will be limited to exploiting sharing
> providers until Tetsuro's series merges.  But no further code work is
> required on the scheduler side.
> 
> [6] https://review.openstack.org/#/c/515811/
> 
>> Once #5 and #6 are resolved, and once the migration/upgrade
>> path is resolved, clearly we will need to have the scheduler start
>> making requests to placement that represent the granular request groups
>> and have the scheduler pass the resulting allocation candidates to its
>> filters and weighers.
>> 
>> Hope this helps highlight where we currently are and the work still left
>> to do (in Rocky) on nested resource providers.
>> 
>> Best,
>> -jay
>> 
>> 
>> [1]
>> https://github.com/openstack/nova/blob/master/nova/compute/provider_tree.py
>> 
>> [2]
>> https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/granular-resource-requests.html
>> 
>> 
>> [3]
>> https://github.com/openstack/no

[openstack-dev] [keystone] Signing off

[Henry Nash]

Hi
 
It is with a somewhat heavy heart that I have decided that it is time to hang up my keystone core status. Having been involved since the closing stages of Folsom, I've had a good run! When I look at how far keystone has come since the v2 days, it is remarkable - and we should all feel a sense 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
Twitter: @henrynash
linkedIn: www.linkedin.com/in/henrypnash
 Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



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

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

[Henry Fourie]

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 (not for usage questions)
Subject: Re: [openstack-dev] [neutron][neutron-lib]Service function defintion 
files

I think it sort of was intentional, although probably not the primary focus. I 
don’t remember if it is a stadium requirement or merely a suggestion, but I 
believe it is strongly encouraged that “official” stadium sub-projects should 
follow neutron’s release cycle whereas “unofficial” projects are free to do 
whatever they want with regard to release cycle, just like with regard to API.

The definition of “stadium” is in some sense tautological. The main benefit of 
being in the stadium is that you tell someone you’re in the stadium they 
automatically know that there’s a set of assumptions that they can make about 
the project. The requirement for being in the stadium is that you do the 
necessary work to make those assumptions valid.

If the developers don’t care whether people can validly make those assumptions, 
there’s no pressure on them to be in the stadium. If the users don’t care about 
those assumptions, there’s no reason why they should prefer stadium projects 
over non-stadium projects. It’s essentially just a label that declares that a 
specific set of requirements have been met. It’s up to each individual to 
evaluate whether they care about that specific set of requirements.

--
Paul Carver
VoIP: 732-545-7377
Cell: 908-803-1656
E: pcar...@att.com
Q Instant Message
It is difficult to make predictions. Especially about the future.


From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Friday, December 29, 2017 14:00
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][neutron-lib]Service function defintion 
files

On 28 December 2017 at 06:57, CARVER, PAUL 
mailto:pc2...@att.com>> wrote:
It was a gating criteria for stadium status. The idea was that the for a 
stadium project the neutron team would have review authority over the API but 
wouldn't necessarily review or be overly familiar with the implementation.

A project that didn't have it's API definition in neutron-lib could do anything 
it wanted with its API and wouldn't be a neutron subproject because the neutron 
team wouldn't necessarily know anything at all about it.

For a neutron subproject there would at least theoretically be members of the 
neutron team who are familiar with the API and who ensure some sort of 
consistency across APIs of all neutron subprojects.

This is also a gating criteria for publishing API documentation on 
api.openstack.org
 vs publishing somewhere else. Again, the idea being that the neutron team 
would be able, at least in some sense, to "vouch for" the OpenStack networking 
APIs, but only for "official" neutron stadium subprojects.

Projects that don't meet the stadium criteria, including having api-def in 
neutron-lib, are "anything goes" and not part of neutron because no one from 
the neutron team is assumed to know anything about them. They may work just 
fine, it's just that you can't assume that anyone from neutron has anything to 
do with them or even knows what they do.

OK - that makes logical sense, though it does seem that it would tie specific 
versions of every service in that list to a common version of neutron-lib as a 
byproduct, so it would be impossible to upgrade LBaaS without also potentially 
having to upgrade bgpvpn, for instance.  I don't know if that was the 
intention, but I wouldn't have expected it.
--
Ian.
__
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] Stepping down from core

[Henry Fourie]

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 neutrinos,

To some of you this email may not come as a surprise.

During the past few months my upstream community engagements have been more and 
more sporadic. While I tried hard to stay committed and fulfill my core 
responsibilities I feel like I failed to retain the level of quality and 
consistency that I would have liked ever since I stepped down from being the 
Neutron PTL back at the end of Ocata.

I stated many times when talking to other core developers that being core is a 
duty rather than a privilege, and I personally feel like it's way overdue for 
me to recognize on the mailing list that it's the time that I state officially 
my intention to step down due to other commitments.

This does not mean that I will disappear tomorrow. I'll continue to be on 
neutron IRC channels, support the neutron team, being the release liasion for 
Queens, participate at meetings, and be open to providing feedback to anyone 
who thinks my opinion is still valuable, especially when dealing with the 
neutron quirks for which I might be (git) blamed :)

Cheers,
Armando

__
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] No networking-sfc meetings until Jan 11

[Henry Fourie]

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)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Henry Fourie]

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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Henry Fourie]

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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Henry Nash]

Congratulations, Colleen - well deserved.

Henry
> On 2 May 2017, at 19:15, Lance Bragstad  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 impact on keystone. Her 
> reviews are meticulous and of incredible quality. She has no hesitation to 
> jump into keystone's most confusing realms and as a result has become an 
> expert on several identity topics like federation and LDAP integration.
> 
> I'd like to thank Colleen for all her hard work and upholding the stability 
> and usability of the project.
> 
> 
> Congratulations, Colleen!
> __
> 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] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Henry Fourie]

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 horizon dashboard for neutron stadium projects?

Hi neutrinos (and horizoners),

As the title says, where would we like to have horizon dashboard for neutron 
stadium projects?
There are several projects under neutron stadium and they are trying to add 
dashboard support.

I would like to raise this topic again. No dashboard support lands since then.
Also Horizon team would like to move in-tree neutron stadium dashboard (VPNaaS 
and FWaaS v1 dashboard) to outside of horizon repo.

Possible approaches


Several possible options in my mind:
(a) dashboard repository per project
(b) dashboard code in individual project
(c) a single dashboard repository for all neutron stadium projects

Which one sounds better?

Pros and Cons


(a) dashboard repository per project
  example, networking-sfc-dashboard repository for networking-sfc
  Pros
   - Can use existing horizon related project convention and knowledge
 (directory structure, testing, translation support)
   - Not related to the neutron stadium inclusion. Each project can provide its 
dashboard
 support regardless of neutron stadium inclusion.
 Cons
   - An additional repository is needed.

(b) dashboard code in individual project
  example, dashboard module for networking-sfc
  Pros:
   - No additional repository
   - Not related to the neutron stadium inclusion. Each project can provide its 
dashboard
 support regardless of neutron stadium inclusion.
 Cons:
   - Requires extra efforts to support neutron and horizon codes in a single 
repository
 for testing and translation supports. Each project needs to explore the 
way.

(c) a single dashboard repository for all neutron stadium projects
   (something like neutron-advanced-dashboard)
  Pros:
- No additional repository per project
  Each project do not need a basic setup for dashboard and possible makes 
things simple.
  Cons:
- Inclusion criteria depending on the neutron stadium inclusion/exclusion
  (Similar discussion happens as for neutronclient OSC plugin)
  Project before neutron stadium inclusion may need another implementation.


My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).

Note that as dashboard supports for feature in the main neutron repository are 
implemented in the horizon repository as we discussed several months ago.
As an example, trunk support is being development in the horizon repo.

Thanks,
Akihiro

__
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] [networking-sfc] About insertion modes and SFC Encapsulation

[Henry Fourie]

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 networking-sfc,

At the latest IRC meeting [1] it was agreed to split TAP from the possible 
insertion modes (initial spec version [2]).

I took the ARs to propose coexistence of insertion modes, correlation and (now) 
a new tap-enabled attribute, and send this email about possible directions.

Here are my thoughts, let me know yours:


1.   My expectation for future PP and PPG if TAP+insertion modes go ahead 
and nothing else changes (only relevant details outlined):

port-pair (service-function-params):
correlation:
- MPLS
- None (default)
port-pair-group (port-pair-group-params):
insertion-mode:
- L2
- L3 (default)
tap-enabled:
- False (default)
- True


2.   What I propose for future PP and PPG (only relevant details outlined):

port-pair (service-function-params):

port-pair-group (port-pair-group-params):
mode:
- L2
- L3 (default)
- MPLS
- NSH
tap-enabled:
- False (default)
- True

With what's proposed in 2.:
- every combination will be possible with no clashes and no validation required.
- port-pair-groups will always group "homogeneous" sets of port-pairs, making 
load-balacing and next-hop processing simpler and consistent.
- the "forwarding" details of a Service Function are no longer dictated both by 
port-pair and port-pair-group, but rather only by port-pair-group.

LF: agree, it appears that L2, L3, MPLS, NSH are mutually exclusive.
Agree on tap-enabled.

Are there any use cases for having next-hop SF candidates (individual 
port-pairs) supporting different SFC Encapsulation protocols?
I understand, however, that removing correlation from port-pairs might not be 
ideal given that it's a subtractive API change.

[1] 
http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-03-16-17.02.html
[2] https://review.openstack.org/#/c/442195/
[3] 
https://github.com/openstack/networking-sfc/blob/17c537b35d41a3e1fd80da790ae668e52cea6b88/doc/source/system_design%20and_workflow.rst#usage

Best regards,
Igor.
__
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] [keystone][all] Reseller - do we need it?

[Henry Nash]

Yes, that was indeed the model originally proposed (some referred to it as 
“nested domains”). Back then we didn’t have project hierarchy support in 
keystone (actually the two requirements emerged together and intertwined - and 
for a while there was a joint spec). Today, there are some interesting 
characteristics in keystone:

1) Project hierarchy support
2) Domains are actually projects under-the-hood, with a special attribute 
(is_project == true).
3) Hence domains are already part of the hierarchy - they just are only allowed 
to be the root of a tree.
4) In fact, if we really want to get technical, in keystone the project 
representing a domain does actually have a parent (the hidden “root of all 
domains” which we don’t expose at the API level)

So from the above, once can see that allowing more than one layer of domains at 
the top of the tree would be (implantation wise) relative easy.  Although this 
has traditionally been my preferred solution, just ‘cause it is alluring and 
seems easy, doesn’t mean it is necessarily the right solution.

The most common alternative proposed is to use some kind of federation. The 
most likely scenario would be that the relationship between the cloud owner and 
a reseller would be a federated one, while the relationship between a reseller 
and their customers would be a traditional one of each customer having a 
domain. Some of the challenges to this approach would be:

a) How do we continually sync the catalogs? Presumably you would want all the 
endpoints (except keystone) to be the same in each catalog? 
b) What are the problems with having the same endpoint registered in multiple 
catalogs? How would keystone middleware on a common, say, nova endpoint know 
which keystone to validate with?
c) How to stop “admin” from one keystone from being treated as general “admin” 
on, say, a nova endpoint?
d) On-boarding a reseller would be a more manual process (i.e. you need to set 
up federation mappings etc.)

In some respects, you could argue that if I were a reseller, I would like this 
federated model better. I know, 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:38, Adrian Turjak  wrote:
> 
> This actually sounds a lot like a domain per reseller, with a sub-domain per 
> reseller customer. With the reseller themselves probably also running a 
> sub-domain or two for themselves. Mayb even running their own external 
> federated user system for that specific reseller domain.
> 
> That or something like it could be doable. The reseller would be aware of the 
> resources (likely to bill) and projects (since you would still likely bill 
> project or at least tag invoice items per project), so the hidden project 
> concept doesn't really fit.
> 
> One thing that I do think is useful, and we've done for our cloud, is letting 
> users see who exactly has access to their projects. For our Horizon we have a 
> custom identity/access control panel that shows clearly who has access on 
> your project and once I add on proper inheritance support will also list 
> users who has inherited access for the project you are currently scoped to. 
> This means a customer knows and can see when an admin has added themselves to 
> their project to help debug something. Plus it even helps them in general 
> manage their own user access better.
> 
> I know we've been looking at the reseller model ourselves but haven't really 
> gotten anywhere with it, partly because the margins didn't seem worth it, but 
> also because the complexity of shoe-horning it around our existing openstack 
> deployment. Domain per reseller (reseller as domain admin) and sub-domain per 
> reseller customer (as sub-domain admin) I'm interested in!
> 
> 
> 
> On 17 Mar. 2017 10:27 pm, Henry Nash  wrote:
> OK, so I worked on the original spec for this in Keystone, based around real 
> world requirements we (IBM) saw.  For the record, here’s the particular goal 
> we wanted to achieve:
> 
> 1) A cloud owner (i.e. the enterprise owns and maintains the core of the 
> cloud), wants to attract more traffic by using third-party resellers or 
> partners.
> 2) Those resellers will sell “cloud” to their own customers and be 
> responsible for finding & managing such customers. These resellers want to be 
> able to onboard such customers and “hand them the admin keys” to they 
> respective (conceptual) pieces of the cloud. I.e. Reseller X signs up 
> Customer Y. Customer Y gets “keystone admin” for their bit of the (shared) 
> cloud, and then can create and manage their own users without either the 
> Reseller o

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

[Henry Nash]

OK, so I worked on the original spec for this in Keystone, based around real 
world requirements we (IBM) saw.  For the record, here’s the particular goal we 
wanted to achieve:

1) A cloud owner (i.e. the enterprise owns and maintains the core of the 
cloud), wants to attract more traffic by using third-party resellers or 
partners.
2) Those resellers will sell “cloud” to their own customers and be responsible 
for finding & managing such customers. These resellers want to be able to 
onboard such customers and “hand them the admin keys” to they respective 
(conceptual) pieces of the cloud. I.e. Reseller X signs up Customer Y. Customer 
Y gets “keystone admin” for their bit of the (shared) cloud, and then can 
create and manage their own users without either the Reseller or the Overall 
cloud owner being involved. In keystone terms, each actual customer gets the 
equivalent of a domain, so that their users are separate from another other 
customers’ users across all resellers.
3) Resellers will want to be able to have a view of all their customers (but 
ONLY their customers, not those of another reseller), e.g. assign quotas to 
each one…and make sure the overall quota for all their customers has not 
exceeded their own quota agreed with the overall cloud owner. Resellers may 
sell addiction services to their customers, e.g. act as support for problems, 
do backups whatever - things that might need them to have controlled access 
particular customers' pieces of the cloud - i.e. they might need roles (or at 
least some kind of access rights) on their customer’s cloud.
4) In all of the above, by default, all hardware is shared and their are no 
dedicated endpoints (e.g. nova, neutron, keystone etc. are all shared), 
although such dedication should not be prevented should a customer want it.

The above is somewhat analogous to how mobile virtual networks operators (MVNO) 
work - e.g. in the UK if I sign up for Sky Mobile, it is actually using the O2 
network. As a Sky customer, I just know Sky - I’m not aware that Sky don’t own 
the network. Sky do own there on BSS/CRM systems - but they are not core 
network components. The idea was to provide someone similar for an OpenStack 
cloud provider, where they could support VCOs (Virtual Cloud Operators) on the 
their cloud.

I agree there are multiple ways to provide such a capability - and it is often 
difficult 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  wrote:
> 
> Hey folks,
> 
> The reseller use case [0] has been popping up frequently in various 
> discussions [1], including unified limits.
> 
> For those who are unfamiliar with the reseller concept, it came out of early 
> discussions regarding hierarchical multi-tenancy (HMT). It essentially allows 
> a certain level of opaqueness within project trees. This opaqueness would 
> make it easier for providers to "resell" infrastructure, without having 
> customers/providers see all the way up and down the project tree, hence it 
> was termed reseller. Keystone originally had some ideas of how to implement 
> this after the HMT implementation laid the ground work, but it was never 
> finished.
> 
> With it popping back up in conversations, I'm looking for folks who are 
> willing to represent the idea. Participating in this thread doesn't mean 
> you're on the hook for implementing it or anything like that. 
> 
> Are you interested in reseller and willing to provide use-cases?
> 
> 
> 
> [0] 
> http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html#problem-description
>  
> <http://specs.openstack.org/openstack/keystone-specs/specs/keystone/mitaka/reseller.html#problem-description>__
> 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] [neutron][sfc] stable/ocata version

[Henry Fourie]

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 our gating on stable/ocata. This is 
due to the fact that there is no networking-sfc version tagged for ocata.
Is there any ETA for this?
Thanks
Gary

__
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] [networking-sfc] Stable/Ocata Version

[Henry Fourie]

Jeffrey,
   The branch pull is awaiting approval:
https://review.openstack.org/#/c/439200

-Louis

From: Jeffrey Zhang [mailto:zhang.lei@gmail.com]
Sent: Friday, March 03, 2017 6:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [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 
mailto:louis.fou...@huawei.com>> wrote:
Gary,
   The plan is to have a stable/ocata branch by end of month.

-Louis

From: Gary Kotton [mailto:gkot...@vmware.com<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 branch?
Thanks
Gary

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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<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

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

[Henry Fourie]

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 branch?
Thanks
Gary
__
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] [networking-sfc] What resources can and can't be reused

[Henry Fourie]

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 can receive, process and return the NSH, this 
restriction does not apply.
- Louis

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

Hi Cathy,

Relax only a couple of them. For Ocata I'm looking at disabling #6 if the 
chain/graph doesn't include sfc proxies (#6 seems to only be necessary if there 
are sfc proxies [1]). For Pike it would be interesting to make port-pair-groups 
completely reusable, as long as the flow classifiers don't make the choice of 
chain ambiguous.

[1] 
http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-01-12-17.14.log.html

Best regards,
Igor.

From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Monday, February 13, 2017 7:50 PM
To: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [networking-sfc] What resources can and can't be 
reused

Hi Igor,

Before we dive into evaluation of the rules you listed below, I would like to 
understand whether you are suggesting to enforce the rules or relax the  
rules/constraints you listed?
Could you clarify it?

Thanks,
Cathy

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 networking-sfc,

As part of my work regarding SFC Encapsulation and SFC Graphs, I exercised the 
API to understand exactly what resources can be reused, to possibly relax a few 
of the constraints when a chain is encapsulated end-to-end.
I'm requesting that the leaders and cores take a look at the list below, and 
reply if you see something that doesn't look quite right (or have any other 
comment/question). Thanks!

1. Every flow-classifier must have a logical source port.
2. The flow-classifier must be unique in its (full) definition.
3. A port-chain can have multiple flow-classifiers associated with exactly the 
same definition BUT different logical source ports.
4. The port-chains can be ambiguous, i.e. match on the same classification 
criteria, if and only if there are 0 flow classifiers associated.
5. The flow classifiers can only be used once, by a single port-chain.
6. Different port-chains cannot be associated to different flow classifiers 
that specify the same classification criteria BUT different logical source 
ports (this is https://bugs.launchpad.net/networking-sfc/+bug/1638421).
7. A port-pair's ingress cannot be in use by another port-pair's ingress.
8. A port-pair's egress cannot be in use by another port-pair's egress.
9. A port-pair can be associated to another port-pair's ingress and egress 
ports BUT swapped (i1=e2, e1=i2).
10. The port-pairs become "in use" when a port-pair-group associates them, so 
they can't be reused across port-pair-groups.
11. A port-chain can include port-pair-groups already associated to other 
port-chains, as long as not the exact same sequence as another port-chain (e.g. 
pc1: [ppg1,ppg2]; pc2: [ppg1] - is fine).

Best regards,
Igor.

__
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] [networking-sfc] What resources can and can't be reused

[Henry Fourie]

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 networking-sfc,

As part of my work regarding SFC Encapsulation and SFC Graphs, I exercised the 
API to understand exactly what resources can be reused, to possibly relax a few 
of the constraints when a chain is encapsulated end-to-end.
I'm requesting that the leaders and cores take a look at the list below, and 
reply if you see something that doesn't look quite right (or have any other 
comment/question). Thanks!


1.  Every flow-classifier must have a logical source port.
LF:  - this is only true for OVS drivers.

2.  The flow-classifier must be unique in its (full) definition.
LF: correct

3.  A port-chain can have multiple flow-classifiers associated with exactly 
the same definition BUT different logical source ports.
LF: correct


4.  The port-chains can be ambiguous, i.e. match on the same classification 
criteria, if and only if there are 0 flow classifiers associated.
LF: If a port-chain has no classifier, then there is no classification so no 
traffic flows through it.

5. The flow classifiers can only be used once, by a single port-chain.
LF: correct.


6.  Different port-chains cannot be associated to different flow 
classifiers that specify the same classification criteria BUT different logical 
source ports (this is https://bugs.launchpad.net/networking-sfc/+bug/1638421).
LF: correct

7. A port-pair's ingress cannot be in use by another port-pair's ingress.
LF: correct a SF port can only be the  ingress port of one port pair.

8. A port-pair's egress cannot be in use by another port-pair's egress.
LF: correct a SF port can only be the  egress port of one port pair.

9. A port-pair can be associated to another port-pair's ingress and egress 
ports BUT swapped (i1=e2, e1=i2).
LF: correct.

10. The port-pairs become "in use" when a port-pair-group associates them, so 
they can't be reused across port-pair-groups.
LF: correct, a port-pair can only be in one port-pair group.

11. A port-chain can include port-pair-groups already associated to other 
port-chains, as long as not the exact same sequence as another port-chain (e.g. 
pc1: [ppg1,ppg2]; pc2: [ppg1] - is fine).
LF: correct.

Best regards,
Igor.

__
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] [stadium] subprojects on independent release cycle

[Henry Fourie]

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] subprojects on independent 
release cycle



On 2 February 2017 at 16:09, Armando M. 
mailto:arma...@gmail.com>> wrote:
Hi neutrinos,

I have put a number of patches in the merge queue for a few sub-projects. We 
currently have a number of these that are on an independent release schedule. 
In particular:

  *   networking-bagpipe
  *   networking-bgpvpn
  *   networking-midonet
  *   networking-odl
  *   networking-sfc
Please make sure that between now and March 10th [1], you work to prepare at 
least one ocata release that works with neutron's [2] and cut a stable branch 
before than. That would incredibly help consumers who are interested in 
assembling these bits together and start testing ocata as soon as it's out.

Your collaboration is much appreciated.

Many thanks,
Armando

Hi neutrinos,

I did not hear anything back from the liaisons of the above mentioned project 
over the past few days. Can you clarify your plans for cutting an Ocata release?

Thanks,
Armando


[1] https://releases.openstack.org/ocata/schedule.html
[2] https://review.openstack.org/#/c/428474/

__
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] [keystone] removing Guang Yee (gyee) from keystone-core

[Henry Nash]

Thanks, Guang, for your valuable contributions.

Henry
> On 2 Feb 2017, at 05:13, Steve Martinelli  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 supports.
> 
> I'd like to publicly thank Guang for his years of service as a core member. 
> He juggled upstream and downstream responsibilities at HP while bringing real 
> world use cases to the table.
> 
> Thanks for everything Guang, o\
> 
> Steve
> __
> 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] [networking-sfc]

[Henry Fourie]

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 [mailto:bcafa...@redhat.com] 
Sent: Tuesday, January 24, 2017 5:31 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc]

On 20 January 2017 at 00:06, Michael Gale  wrote:
> Hello,
>
> Are there updated install docs for sfc? The only install steps for 
> a testbed I can find are here and they seem outdated:
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
There is also a SFC chapter in the networking guide:
http://docs.openstack.org/newton/networking-guide/config-sfc.html

Which parts do you find outdated? Some references to Ubuntu/OVS versions may 
need a cleanup, but the design and API parts should still be OK (OSC client, 
SFC graph API, symmetric ports and other goodies are still under review and not 
yed merged)

> Also from the conference videos there seems to be some Horizon menu / 
> screens that are available?
Not for networking-sfc directly, but there is a SFC tab in the tacker horizon 
plugin (or will be, someone from the tacker team can confirm
that)


--
Bernard Cafarelli

__
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] [networking-sfc]

[Henry Fourie]

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-sfc]

There is a SFC Horizon code patch available. And our presentation video GUI is 
based on that. 

Louis/Vikram,

I am on business trip and have difficulty to access some openstack links. Could 
you share the link to our SFC Horizon work?

Thanks,
Cathy

-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com]
Sent: Tuesday, January 24, 2017 9:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc]

On 20 January 2017 at 00:06, Michael Gale  wrote:
> Hello,
>
> Are there updated install docs for sfc? The only install steps for 
> a testbed I can find are here and they seem outdated:
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
There is also a SFC chapter in the networking guide:
http://docs.openstack.org/newton/networking-guide/config-sfc.html

Which parts do you find outdated? Some references to Ubuntu/OVS versions may 
need a cleanup, but the design and API parts should still be OK (OSC client, 
SFC graph API, symmetric ports and other goodies are still under review and not 
yed merged)

> Also from the conference videos there seems to be some Horizon menu / 
> screens that are available?
Not for networking-sfc directly, but there is a SFC tab in the tacker horizon 
plugin (or will be, someone from the tacker team can confirm
that)


--
Bernard Cafarelli

__
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] [networking-sfc] Does SFC support chaining of Layer 2 devices?

[Henry Fourie]

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 chaining of Layer 2 
devices?

All,
   I am exploring SFC for chaining an IDS device (strictly in L2 mode). As of 
now, it looks SFC default supports only L3 devices. SFC APIs doesn't have any 
way to specify the nature of device and without that, it seems there is no way 
an operator can spin any device/VNF except L3 mode VNFs. Is anything I am 
missing here ? Can one still spin a L2 IDS with SFC ?


--
Regards,
Vikash
__
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] PTL nominations deadline and non-candidacy

[Henry Fourie]

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 non-candidacy

Hi neutrinos,

The PTL nomination week is fast approaching [0], and as you might have guessed 
by the subject of this email, I am not planning to run for Pike. If I look back 
at [1], I would like to think that I was able to exercise the influence on the 
goals I set out with my first self-nomination [2].

That said, when it comes to a dynamic project like neutron one can't never 
claim to be *done done* and for this reason, I will continue to be part of the 
neutron core team, and help the future PTL drive the next stage of the 
project's journey.

I must admit, I don't write this email lightly, however I feel that it is now 
the right moment for me to step down, and give someone else the opportunity to 
grow in the amazing role of neutron PTL! I have certainly loved every minute of 
it!

Cheers,
Armando

[0] https://releases.openstack.org/ocata/schedule.html
[1] 
https://review.openstack.org/#/q/project:openstack/election+owner:armando-migliaccio
[2] https://review.openstack.org/#/c/223764/
__
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][networking-sfc] Next networking-sfc meeting on 1/5/2017

[Henry Fourie]

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)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Henry Gessau]

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 lieutenant, and drivers team member.

Working with the diverse and very talented contributors to Neutron has been
the best experience of my career (which started before many of you were born).
Thank you all for making the team such a great community. Because of you the
project is thriving and will continue to be successful!

I will still be around on IRC, contribute some small patches here and there,
and generally try to keep abreast of Neutron's progress. Don't hesitate to
ping 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

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

[Henry Gessau]

Gary Kotton  wrote:
> Would it be worth considering have the three patches:
> https://review.openstack.org/399891, https://review.openstack.org/398113
> and  https://review.openstack.org/398489 based one on top of the other.
> Then all sub projects could take the top of the commit and base on top of
> that. That may make the process a little more efficient.

The problem is that the ExtensionDescriptor change has its own specific order
in which the patches must be done, as explained in
http://lists.openstack.org/pipermail/openstack-dev/2016-November/108005.html

My recommendation is that ExtensionDescriptor be done first. Then we could
stage the PLURALS and _FIELD_SIZES as you suggest, but the PLURALS change is
quite independent, so it could be done in parallel with ExtensionDescriptor.

Once ExtensionDescriptor, PLURALS and _FIELD_SIZES 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"  wrote:
> 
> 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 neutron-lib.
> 
> I have submitted patches [2] for most subprojects.
> 
>  NAME_MAX_LEN  -->  NAME_FIELD_SIZE
>  TENANT_ID_MAX_LEN -->  PROJECT_ID_FIELD_SIZE
>  DESCRIPTION_MAX_LEN   -->  DESCRIPTION_FIELD_SIZE
>  LONG_DESCRIPTION_MAX_LEN  -->  LONG_DESCRIPTION_FIELD_SIZE
>  DEVICE_ID_MAX_LEN -->  DEVICE_ID_FIELD_SIZE
>  DEVICE_OWNER_MAX_LEN  -->  DEVICE_NAME_FIELD_SIZE
> 
> In alembic migration scripts, the raw numerical value shall be used.
> 
> For more information, see [3].
> 
> [1] https://review.openstack.org/399891
> [2] https://review.openstack.org/#/q/status:open+topic:use-db-field-sizes
> [3] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-October/105789.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
> 
> 
> __
> 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] [neutron] NeutronLibImpact: Removing deprecated model_base mixins from core

[Henry Gessau]

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 submitted patches [2] for the stragglers that I found.

[1] https://review.openstack.org/403329
[2] https://review.openstack.org/#/q/status:open+topic:use-lib-model_base

__
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] NeutronLibImpact: Adoption of db *_FIELD_SIZE constants from neutron-lib

[Henry Gessau]

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 neutron-lib.

I have submitted patches [2] for most subprojects.

 NAME_MAX_LEN  -->  NAME_FIELD_SIZE
 TENANT_ID_MAX_LEN -->  PROJECT_ID_FIELD_SIZE
 DESCRIPTION_MAX_LEN   -->  DESCRIPTION_FIELD_SIZE
 LONG_DESCRIPTION_MAX_LEN  -->  LONG_DESCRIPTION_FIELD_SIZE
 DEVICE_ID_MAX_LEN -->  DEVICE_ID_FIELD_SIZE
 DEVICE_OWNER_MAX_LEN  -->  DEVICE_NAME_FIELD_SIZE

In alembic migration scripts, the raw numerical value shall be used.

For more information, see [3].

[1] https://review.openstack.org/399891
[2] https://review.openstack.org/#/q/status:open+topic:use-db-field-sizes
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-October/105789.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

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

[Henry Gessau]

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 in the next Neutron team meeting [3].


[1] https://review.openstack.org/398113
[2] https://review.openstack.org/#/q/status:open+topic:ExtensionDescriptor
[3] https://wiki.openstack.org/wiki/Network/Meetings

__
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] NeutronLibImpact: Removal of PLURALS

[Henry Gessau]

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 subprojects.

This will be highlighted in the next Neutron team meeting [3].


[1] https://review.openstack.org/398489
[2] https://review.openstack.org/#/q/status:open+topic:remove-PLURALS
[3] https://wiki.openstack.org/wiki/Network/Meetings

__
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] [networking-sfc] #networking-sfc IRC channel

[Henry Fourie]

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, devs and users,

What do you think about having an IRC channel dedicated to networking-sfc's 
discussions and sync?

For the time being  I have joined #networking-sfc @ freenode, and will stay 
online to keep it open.

Best regards,
Igor.

__
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] [keystone] Stepping down from keystone core

[Henry Nash]

Echoing the comments of others. - thanks for all your hard work and expertise.

Henry
> On 23 Nov 2016, at 15:05, Lance Bragstad  wrote:
> 
> Thanks for all your hard work, Marek. It's been a pleasure working with you. 
> Best of luck and hopefully our paths cross in the future!
> 
> On Tue, Nov 22, 2016 at 7:57 PM, Steve Martinelli  <mailto:s.martine...@gmail.com>> wrote:
> Marek, thanks for everything you've done in Keystone. It was loads of fun to 
> develop some of the early federation work with you back in the Icehouse 
> release! Good luck in whatever the future holds for you! 
> 
> On Tue, Nov 22, 2016 at 5:18 PM, Marek Denis  <mailto:marek.denis+openst...@gmail.com>> wrote:
> Hi,
> 
> Due to my current responsibilities I cannot serve as keystone core anymore. I 
> also feel I should make some space for others who will surely bring new 
> quality to the OpenStack Identity Program.
> 
> It's been a great journey, I surely learned a lot and improved both my 
> technical and soft skills. I can only hope my contributions and reviews have 
> been useful and made OpenStack a little bit better.
> 
> I wish you all the best in the future.
> 
> With kind regards,
> Marek Denis
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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 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] [keystone] Pike PTL

[Henry Nash]

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  wrote:
> 
> one of these days i'll learn how to spell :)
> 
> On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli  <mailto:s.martine...@gmail.com>> wrote:
> Keystoners, 
> 
> I do not intend to run for the PTL position of the Pike development cycle. 
> I'm sending this out early so I can work with folks interested in the role, 
> If you intend to run for PTL in Pike and are interested in learning the ropes 
> (or just want to hear more about what the role means) then shoot me an email.
> 
> It's been an unforgettable ride. Being PTL a is very rewarding experience, I 
> encourage anyone interested to put your name forward. I'm not going away from 
> OpenStack, I just think three terms as PTL has been enough. It'll be nice to 
> have my evenings back :) 
> 
> To *all* the keystone contributors (cores and non-cores), thank you for all 
> your time and commitment. More importantly thank you for putting up with my 
> many questions, pings, pokes and -1s. Each of you are amazing and together 
> you make an awesome team. It has been an absolute pleasure to serve as PTL, 
> thank you for letting me do so.
> 
> stevemar
> 
> 
> 
> 
> Thanks for the idea Lana [1]
> [1] 
> http://lists.openstack.org/pipermail/openstack-docs/2016-November/009357.html 
> <http://lists.openstack.org/pipermail/openstack-docs/2016-November/009357.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

__
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] Reviews needed in neutron-lib

[Henry Gessau]

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:

https://review.openstack.org/385045
https://review.openstack.org/391354
https://review.openstack.org/387612
https://review.openstack.org/396972
https://review.openstack.org/394244
https://review.openstack.org/397035
https://review.openstack.org/346554

(Also look for patches in neutron core that remove deprecations, or that adopt
code from neutron-lib.)


Finally, do not neglect the api-ref fixes/updates in neutron-lib, most of
these are very easy to review...

https://review.openstack.org/#/q/project:openstack/neutron-lib+status:open+file:%22%255Eapi-ref/.*%22


__
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] Weekly neutron-lib meeting canceled

[Henry Gessau]

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 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] Barcelona summit neutron-lib session recap

[Henry Gessau]

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 can remove their dependency on
core neutron. No objections to the speed-up were raised during the session.

Updates to policies:
1) No more debtcollector deprecations on neutron core changes when adopting
neutron-lib code (unless it affects projects beyond those that integrate with
neutron). See below for details.
2) Provide unit test base classes and utils in neutron-lib (reverses previous
decision).
3) Spend more effort on rehoming code from neutron, less on tweaking what
is already in lib.
4) All stadium REST APIs must go in the api-ref.

The above will be detailed in the devref[1], but here is a summary:


1. No more deprecations

When a new version of neutron-lib is released the new features should be
adopted immediately by all consuming projects. One month after the release,
code will be removed from neutron core if it is available in neutron-lib.
**NOTE** This will break sub-projects that are not keeping up.
(No one at the session objected to this.)
As part of this effort we are requiring release notes in neutron-lib patches
that impact consuming projects.

2. Unit test framework

Base classes and utility functions will be provided. Some minor refactoring
for cleaner code-reuse will be needed. Base test classes for ml2 will also be
provided.

3. Rehome first, tweak later

Let's de-prioritize the tweaking of code already in neutron-lib until after
all the stadium projects have stopped importing neutron core.

3b. Shed technical debt

Rehoming ugly code will give us a ugly library. Some existing neutron code
needs to be refactored before being made available in neutron-lib.

4. Complete api-ref

All REST API extensions from stadium sub-projects must be documented in the
api-ref. The api definitions must also be added.
The existing api-ref update work will continue. We encourage developers to
look for discrepancies and propose fixes.



The following items were not addressed:
 - Not enough core reviewer attention in neutron-lib.
 - Config options in neutron-lib. There is an email thread[2] about this.


[1] https://review.openstack.org/331338
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-October/106369.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] [neutron] neutron-lib

[Henry Gessau]

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


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

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

[Henry Fourie]

+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

[Henry Gessau]

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

[Henry Gessau]

Anna Taraday  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 fixing
> synchronization issues. Usage constants everywhere can be good in this case,
> but ModelMigrationSyc did such check of this for us already.
> 
> If we want to have constants everywhere, we should guarantee that they are
> unchanged - have test in neutron-lib which verifies their values. 

Yes, we could have some tests, although a patch changing a constant would
probably also have a change to the test. :) We might need to also have a
prominent "Warning! Do not change this test!" comment for each test.

> 
> 
> On Sat, Oct 15, 2016 at 10:41 PM Henry Gessau  <mailto: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 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. Raw sizes in alembic migrations
> 
> In the alembic migrations which build the DB schema, we should use the raw
> number value of the field size.
> 
> 2. FOO_FIELD_SIZE in the sqlalchemy models
> 
> In the sqlalchemy models, we should use the _FIELD_SIZE constants
> defined in neutron_lib/db/constants.py
> 
> 3. Everywhere else, use FOO_FIELD_SIZE, or another constant (like 
> FOO_MAX_LEN)
> based on FOO_FIELD_SIZE.
> 
> 
> "Why raw numbers in alembic migrations?", you may ask. Well, we have tests
> that verify that the models match the schema generated by migrations. If 
> both
> the models and the migrations use the constants then the tests would not
> detect if a patch changes the constant value.
> 
> By using raw numbers in migrations, together with our rule of not allowing
> changes to existing migrations, we allow the tests to detect and fail on 
> any
> attempt to alter a FIELD_SIZE constant.
> 
> Let me know if this makes sense or if you think it's a terrible idea.
> 
> If there are no objections, I intend to submit a patch or patches to:
>  - replace constants with numbers in existing migrations
>  - ensure all models use the appropriate constants
> 
> Existing code uses FOO_MAX_LEN in a lot of places. In most of these 
> places it
> would make sense to simply switch to using FOO_FIELD_SIZE. However, some 
> code
> may be quite far removed from the DB and would look better by sticking to
> FOO_MAX_LEN. I added item 3. above to allow for that.


__
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

[Henry Gessau]

Ihar Hrachyshka  wrote:
> Henry Gessau  wrote:
> 
>> 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. Raw sizes in alembic migrations
>>
>> In the alembic migrations which build the DB schema, we should use the raw
>> number value of the field size.
>>
>> 2. FOO_FIELD_SIZE in the sqlalchemy models
>>
>> In the sqlalchemy models, we should use the _FIELD_SIZE constants
>> defined in neutron_lib/db/constants.py
>>
>> 3. Everywhere else, use FOO_FIELD_SIZE, or another constant (like  
>> FOO_MAX_LEN)
>> based on FOO_FIELD_SIZE.
>>
>>
>> "Why raw numbers in alembic migrations?", you may ask. Well, we have tests
>> that verify that the models match the schema generated by migrations. If  
>> both
>> the models and the migrations use the constants then the tests would not
>> detect if a patch changes the constant value.
>>
>> By using raw numbers in migrations, together with our rule of not allowing
>> changes to existing migrations, we allow the tests to detect and fail on  
>> any
>> attempt to alter a FIELD_SIZE constant.
>>
>> Let me know if this makes sense or if you think it's a terrible idea.
> 
> Not sure. I mean, if you envision that a ‘constant’ value maintained in  
> neutron-lib may be changed in the future, then it’s not safe to use it  
> anywhere, both in models and alembic scripts.
> 
> But I believe those lib constants are supposed to be unchanged, and  
> reviewers of the library should understand that; in which case we should be  
> safe to use them in alembic scripts too.
> 
> Is it that we don’t trust neutron-lib core reviewers to follow the rule?

OK, I suppose using *_FIELD_SIZE constants from neutron-lib in the alembic
scripts is safe enough.

I began thinking about this problem before I added field sizes to neutron-lib,
and it was not a matter of trust. It was more about having a mechanism to
detect a problem if someone tries to change, say, FILE_NAME_MAX_LEN from 16 to
80 without realizing it is related to a DB field. That's a hypothetical
example, but we have many constants and I did not want to count on humans to
detect every impacting case.


__
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] Database field sizes and attribute "MAX_LEN" constants

[Henry Gessau]

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. Raw sizes in alembic migrations

In the alembic migrations which build the DB schema, we should use the raw
number value of the field size.

2. FOO_FIELD_SIZE in the sqlalchemy models

In the sqlalchemy models, we should use the _FIELD_SIZE constants
defined in neutron_lib/db/constants.py

3. Everywhere else, use FOO_FIELD_SIZE, or another constant (like FOO_MAX_LEN)
based on FOO_FIELD_SIZE.


"Why raw numbers in alembic migrations?", you may ask. Well, we have tests
that verify that the models match the schema generated by migrations. If both
the models and the migrations use the constants then the tests would not
detect if a patch changes the constant value.

By using raw numbers in migrations, together with our rule of not allowing
changes to existing migrations, we allow the tests to detect and fail on any
attempt to alter a FIELD_SIZE constant.

Let me know if this makes sense or if you think it's a terrible idea.

If there are no objections, I intend to submit a patch or patches to:
 - replace constants with numbers in existing migrations
 - ensure all models use the appropriate constants

Existing code uses FOO_MAX_LEN in a lot of places. In most of these places it
would make sense to simply switch to using FOO_FIELD_SIZE. However, some code
may be quite far removed from the DB and would look better by sticking to
FOO_MAX_LEN. I added item 3. above to allow for that.


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

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

[Henry Gessau]

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: http://www.racodelavila.com/en/index.htm. The menu is here:
> http://www.racodelavila.com/en/carta-racodelavila.htm
> 
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under
> 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get a
> final count.
> 
> Here's some reviews:
> https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html
> 
> Cheers
> 
> Miguel


__
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] [networking-sfc][devstack][mitaka]

[Henry Fourie]

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


-Louis

From: Navdeep Uniyal [mailto:navdeep.uni...@neclab.eu]
Sent: Wednesday, October 12, 2016 3:06 AM
To: Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc][devstack][mitaka]

Hi Cathy,

Thanks for your reply. I have the setup done without any errors with only one 
vm in the chain. I want to move all the icmp traffic from vm1 to vm3 via vm2. 
My Flow classifier looks like:
"neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix 
10.0.0.18/32 --destination-ip-prefix 10.0.0.6/32 --protocol icmp FC1"
But using tcpdump on vm2 ingress port, I could not see any traffic. Please let 
me know how can I debug this and what could be the possible issue.


Best Regards,
Navdeep Uniyal


From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Dienstag, 11. Oktober 2016 19:50
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc][devstack][mitaka]

Hi Navdeep,

Please see inline.

Cathy

From: Navdeep Uniyal [mailto:navdeep.uni...@neclab.eu]
Sent: Tuesday, October 11, 2016 5:42 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [networking-sfc][devstack][mitaka]

Hi all,

I have been trying out networking-sfc to create service function chain in 
Openstack. I could create all the port pairs, port-pair-groups, flow classifier 
and the chain but I could not see the packets on the desired hops.
I am trying to create a simple sfc with 3 VMs(vm1 to vm3) in the setup. I just 
want to check how it works. In my setup, vm1 is the Traffic generator(iperf) 
and vm3 is the traffic receiver(iperf server). Now, the  2 vms (vm2 and 3) are 
in the same network with vm1 and I want to move the iperf traffic from 
vm1->vm2->vm3. In order to achieve this, I have created 2 port pairs of vm2  
and vm3 and both pairs are in separate port pair groups (PG1 and PG2), also 
created a Flow classifier FC1 and finally chain with PG1, PG2 and FC1.  Now my 
question is, is my setup correct in order to achieve the sfc result as I stated 
above? Do I need to include the vm1 in the port pair group?

Cathy> You only need to include VM2 in a port pair group. Traffic source and 
traffic destination do not need to be included in the chain's port pair group, 
instead their IP addresses should be included in the flow classifier so that 
the system knows which flow needs to go through the chain. Here is a link to 
thw wiki.
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

Cathy




Below is the flow classifier:

++--+
| Field  | Value
|
++--+
| description  |
  |
| destination_ip_prefix   |  |
| destination_port_range_max |  |
| destination_port_range_min |  |
| ethertype| IPv4   
  |
| id | 
e5000ade-50ad-41ed-a159-b89c4blp97ec |
| l7_parameters  | {}   
|
| logical_destination_port   |  |
| logical_source_port   | 63cdf664-dd67-455c-8345-f01ef58c23e5 |
| name| FC1 
 |
| project_id   | 
6b90cd3356144681b44274d4881c5fc7 |
| protocol  | tcp   
   |
| source_ip_prefix  | 10.0.0.18/32  
   |
| source_port_range_max  |  |
| source_port_range_min  |  |
| tenant_id | 
6b90cd3310104681b44274d4881c5fc7 |
++--+



Is there any wiki with some example case explained with testing scenario?


Best Regards,
Navdeep Uniyal
Email: navdeep.uni...@neclab.eu
-
Software Engineer
NEC Europe Ltd.
NEC Laboratories Europe
Kurfürstenanlage 36, D-69115 Heidelberg,

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  
Road, London, H

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

[Henry Gessau]

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 ( https://review.openstack.org/#/c/370805/ )
>> and make a couple of "rechecks" to see if it helps or not.
> 
> Given the fail rate, lets just go safe and double it to 4. If it's
> really a timeout issue that should move the bell curve to mostly cover
> it. Timeouts are really just supposed to be a backstop to ensure the
> tests don't deadlock forever.
> 
> The incidence rate is at that odd race rate that we'll probably have to
> merge and just see if it goes away.

Neutron also started seeing timeouts in DB migration tests today.
We're going to try a similar timeout scaling factor for these tests.


__
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] Adding ihrachys to the neutron-drivers team

[Henry Fourie]

+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 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 (I am sure 
I am forgetting some other capacity he is in) is going to put him at great 
comfort in the newly appointed role, and help him grow and become wise even 
further.

Even though we have not been meeting regularly lately we will resume our 
Thursday meetings soon [2], and having Ihar onboard by then will be highly 
beneficial.

Please, join me in welcome Ihar to the team.

Cheers,
Armando

[1] 
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
__
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] Adding ihrachys to the neutron-drivers team

[Henry Gessau]

+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 (I am sure
> I am forgetting some other capacity he is in) is going to put him at great
> comfort in the newly appointed role, and help him grow and become wise even
> further.
> 
> Even though we have not been meeting regularly lately we will resume our
> Thursday meetings soon [2], and having Ihar onboard by then will be highly
> beneficial. 
> 
> Please, join me in welcome Ihar to the team.
> 
> Cheers,
> Armando 
> 
> [1] 
> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
> 
> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
> 


__
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] [tacker] PTL candidacy

[Henry Fourie]

+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 Ocata
dev cycle.

I'm a member of the Tacker community right from its Neutron ServiceVM days.
I actively participated in its transition into NFV Orchestration area and its
graduation into big-tent. Since becoming an official project our developer
community has grown and has more diverse [1].

Newton was a packed cycle for us with many stellar achievements from the
community: VNF Scaling, Audit Events, VNF Forwarding Graph using Neutron
Networking-SFC (we are almost there!) and External Alarm-based Monitoring
using Ceilometer. As usual tons of refactoring work happened to continue
to shed the "Neutronisms" in the project.

Along the way, we have become a better openstack citizen following best
practices like Reno release-notes, better release processes, and better
python3 support. We also expanded our core-team with three new members.

My vision for Tacker Ocata is along the following workstreams identified
in the recent weekly meeting.

* Decomposed VIM drivers:
We need to enable a healthy ecosystem of VIM drivers beyond the current
default openstack VIM driver. Our user community has mixed hypervisor/cloud
technology in their deployments - with some existing pre-openstack systems
(a.la, VMware), some OpenStack based clouds, and, forward looking 
into
Containers and public clouds. All this needs an easy to add VIM driver to
bolt underneath Tacker. Luckily our architecture is designed with this in
mind right from day one. We just need to make it easy (a) for developers to
bring in new VIM drivers and (b) for deployers to quickly add new VIM
capabilities without requiring a fork-lift upgrade of Tacker for every new
VIM type.

As part of this workstream, I'd work towards bringing in a Container VIM
type interfacing with Magnum / Zun.

Lifecycle Features:
* Finish left over Newton features - VNFC and NSD
* Better integration with external EM / FCAPS systems
* Enable support for VNFs leveraging Neutron's latest VLAN aware VM feature

Project maintenance:
 * Doc: API reference guide
 * Pecan API framework
 * OSC support
 * Finish python3x TC goal

Tons of fun things to do! However, Ocata is going to be a short cycle.
So, over next few weeks, I'll help to continue to groom these topics and
zoom in on those that are implementable in one dev cycle and clearly
identify some tracks that would carry over to the next cycle.

In Ocata, given an opportunity to serve as your PTL, I'll continue my role
as the "chief enabler" for this amazing community of developers that I'm so
proud to lead over the last two cycles.

- Sridhar Ramaswamy (irc: sridhar_ram)

[1] http://stackalytics.com/?module=tacker-group&metric=commits

__
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] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

[Henry Nash]

Jay,

I agree with your distinction - and when I am referring to rolling upgrades for 
keystone I am referring to when you are running a cluster of keystones (for 
performance and/or redundancy), and you want to roll the upgrade across the 
cluster without creating downtime of the overall keystone service. Such a 
keystone cluster deployment will be common in large clouds - and prior to 
Newton, keystone did not support such a rolling upgrade (you had to take all 
the nodes down, upgrade the DB and then boot them all back up). In order to 
support such a rolling upgrade you either need 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  wrote:
> 
> On 09/01/2016 05:29 AM, Henry Nash wrote:
>> So as the person who drove the rolling upgrade requirements into
>> keystone in this cycle (because we have real customers that need it),
>> and having first written the keystone upgrade process to be
>> “versioned object ready” (because I assumed we would do this the same
>> as everyone else), and subsequently re-written it to be “DB Trigger
>> ready”…and written migration scripts for both these cases for the (in
>> fact very minor) DB changes that keystone has in Newton…I guess I
>> should also weigh in here :-)
> 
> Sorry for delayed response. PTO and all... I'd just like to make a 
> clarification here. Henry, you are not referring to *rolling upgrades* but 
> rather *online database migrations*. There's an important distinction between 
> the two concepts.
> 
> Online schema migrations, as discussed in this thread, are all about 
> minimizing the time that a database server is locked or otherwise busy 
> performing the tasks of changing SQL schemas and moving the underlying stored 
> data from their old location/name to their new location/name. As noted in 
> this thread, there's numerous ways of reducing the downtime experienced 
> during these data and schema migrations.
> 
> Rolling upgrades are not the same thing, however. What rolling upgrades refer 
> to is the ability of a *distributed system* to have its distributed component 
> services running different versions of the software and still be able to 
> communicate with the other components of the system. This time period during 
> which the components of the distributed system may run different versions of 
> the software may be quite lengthy (days or weeks long). The "rolling" part of 
> "rolling upgrade" refers to the fact that in a distributed system of 
> thousands of components or nodes, the upgraded software must be "rolled out" 
> to those thousands of nodes over a period of time.
> 
> Glance and Keystone do not participate in a rolling upgrade, because Keystone 
> and Glance do not have a distributed component architecture. Online data 
> migrations will reduce total downtime experienced during an *overall upgrade 
> procedure* for an OpenStack cloud, but Nova, Neutron and Cinder are the only 
> parts of OpenStack that are going to participate in a rolling upgrade because 
> they are the services that are distributed across all the many compute nodes.
> 
> Best,
> -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 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] [keystone] new core reviewer (rderose)

[Henry Nash]

Welcome, Ron!

Henry

> On 1 Sep 2016, at 15:44, Steve Martinelli  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 shadowing LDAP and federated users, as well as enhancing password support 
> for SQL users. Implementing these features and picking up various bugs along 
> the way has helped Ron to understand the keystone code base. As a result he 
> is able to contribute to the team with quality code reviews. 
> 
> Thanks for all your hard work Ron, we sincerely appreciate it.
> 
> Steve
> __
> 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] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

[Henry Nash]

So as the person who drove the rolling upgrade requirements into keystone in 
this cycle (because we have real customers that need it), and having first 
written the keystone upgrade process to be “versioned object ready” (because I 
assumed we would do this the same as everyone else), and subsequently 
re-written it to be “DB Trigger ready”…and written migration scripts for both 
these cases for the (in fact very minor) DB changes that keystone has in 
Newton…I guess I should also weigh in here :-)

For me, the argument comes down to:

a) Is the pain that needs to cured by the rolling upgrade requirement broadly 
in the same place in the various projects (i.e. nova, glance, keystone etc.)? 
If it is, then working towards a common solution is always preferable (whatever 
that solution is)
b) I would characterise the difference between the trigger approach, the 
versioned objects approach and the “n-app approach as: do we want a small 
amount of very nasty complexity vs. spreading that complexity out to be not as 
bad, but over a broader area. Probably fewer people can (successfully) write 
the nasty complexity trigger work, than they can, say, the “do it all in the 
app” work. LOC (which, of course, isn’t always a good measure) is also 
reflected in this characterisation, with the trigger code having probably the 
fewest LOC, and the app code having the greatest. 
c) I don’t really follow the argument that somehow the trigger code in 
migrations is less desirable because we use higher level sqla abstractions in 
our main-line code - I’ve always seen migration as different and expected that 
we might have to do strange things there. Further, we should be aware of the 
time-preiods…the migration cycle is a small % of elapsed time the cloud is 
running (well, hopefully) - so again, do we solve the “issues of migration” as 
part of the migration cycle (which is what the trigger approach does) or make 
our code be (effectively) continually migration aware (using versioned objects 
or in-app code)
d) The actual process (for an operator) is simpler for a rolling upgrade 
process with Triggers than the alternative (since you don’t require several of 
the checkpoints, e.g. when you know you can move out of compatibility mode 
etc.). Operator error is also a cause of problems in upgrades (especially as 
the complexity of a cloud increases).

From a purely keystone perspective, my gut feeling is that actually the trigger 
approach is likely to lead to a more robust, not less, solution - due to the 
fact that we solve the very specific problems of a given migration (i.e. need 
to keep column A in sync with Column B) or a short period of time, right at the 
point of pain, with well established techniques - albeit they be complex ones 
that need experienced coders in those techniques. I actually prefer the small 
locality of complexity (marked with “there be dragons there, be careful”), as 
opposed to spreading medium pain over a large area, which by definition is 
updated by many…and  may do the wrong thing inadvertently. It is simpler for 
operators.

I do recognise, however, the “let’s not do different stuff for a core project 
like keytsone” as a powerful argument. I just don’t know how to square this 
with the fact that although I started in the “versioned objects camp”, having 
worked through many of the issues have come to believe that the Trigger 
approach will be more reliable overall for this specific use case. From the 
other reaction to this thread, I don’t detect a lot of support for the Trigger 
approach becoming our overall, cross-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 2016, at 09:45, Robert Collins  wrote:
> 
> On 31 August 2016 at 01:57, Clint Byrum  wrote:
>> 
>> 
>> It's simple, these are the holy SQL schema commandments:
>> 
>> Don't delete columns, ignore them.
>> Don't change columns, create new ones.
>> When you create a column, give it a default that makes sense.
> 
> I'm sure you're aware of this but I think its worth clarifying for non
> DBAish folk: non-NULL values can change a DDL statements execution
> time from O(1) to O(N) depending on the DB in use. E.g. for Postgres
> DDL requires an exclusive table lock, and adding a column with any
> non-NULL value (including constants) requires calculating a new value
> for every row, vs just updating the metadata - see
> https://www.postgresql.org/docs/9.5/static/sql-altertable.html
> """
> When a column is added with ADD COLUMN, all existing rows in the table
> are initialized with the column's default value (NULL if no DEFAULT
> clause is specified). If there is n

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

[Henry Gessau]

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] https://review.openstack.org/360291


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

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

[Henry Gessau]

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 
>> wrote:
>>>
>>> Hi all,
>>> I wanted to report on status and answer any questions you all have about
>>> the API reference and guide publishing process.
>>>
>>> The expectation is that we provide all OpenStack API information on
>>> developer.openstack.org. In order to meet that goal, it's simplest for now
>>> to have all projects use the RST+YAML+openstackdocstheme+os-api-ref
>>> extension tooling so that users see available OpenStack APIs in a sidebar
>>> navigation drop-down list.
>>>
>>> --Migration--
>>> The current status for migration is that all WADL content is migrated
>>> except for trove. There is a patch in progress and I'm in contact with the
>>> team to assist in any way. https://review.openstack.org/#/c/316381/
>>>
>>> --Theme, extension, release requirements--
>>> The current status for the theme, navigation, and Sphinx extension tooling
>>> is contained in the latest post from Graham proposing a solution for the
>>> release number switchover and offers to help teams as needed:
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-August/101112.html I
>>> hope to meet the requirements deadline to get those changes landed.
>>> Requirements freeze is Aug 29.
>>>
>>> --Project coverage--
>>> The current status for project coverage is that these projects are now
>>> using the RST+YAML in-tree workflow and tools and publishing to
>>> http://developer.openstack.org/api-ref/ so they will be
>>> included in the upcoming API navigation sidebar intended to span all
>>> OpenStack APIs:
>>>
>>> designate http://developer.openstack.org/api-ref/dns/
>>> glance http://developer.openstack.org/api-ref/image/
>>> heat http://developer.openstack.org/api-ref/orchestration/
>>> ironic http://developer.openstack.org/api-ref/baremetal/
>>> keystone http://developer.openstack.org/api-ref/identity/
>>> manila http://developer.openstack.org/api-ref/shared-file-systems/
>>> neutron-lib http://developer.openstack.org/api-ref/networking/
>>> nova http://developer.openstack.org/api-ref/compute/
>>> sahara http://developer.openstack.org/api-ref/data-processing/
>>> senlin http://developer.openstack.org/api-ref/clustering/
>>> swift http://developer.openstack.org/api-ref/object-storage/
>>> zaqar http://developer.openstack.org/api-ref/messaging/
>>>
>>> These projects are using the in-tree workflow and common tools, but do not
>>> have a publish job in project-config in the jenkins/jobs/projects.yaml file.
>>>
>>> ceilometer
>>
>>
>> Sorry, in reviewing further today I found another project that does not have
>> a publish job but has in-tree source files:
>>
>> cinder
>>
>> Team cinder: can you let me know where you are in your publishing comfort
>> level? Please add an api-ref-jobs: line with a target of block-storage to
>> jenkins/jobs/projects.yaml in the project-config repo to ensure publishing
>> is correct.
>>
>> Another issue is the name of the target directory for the final URL. Team
>> ironic can I change your api-ref-jobs: line to bare-metal instead of
>> baremetal? It'll be better for search engines and for alignment with the
>> other projects URLs: https://review.openstack.org/354135
>>
>> I've also uncovered a problem where a neutron project's API does not have an
>> official service name, and am working on a solution but need help from the
>> neutron team: https://review.openstack.org/#/c/351407
> 
> I followed the discussion in https://review.openstack.org/#/c/351407
> and my understanding of the conclusion is to add API reference source
> of neutron stadium projects
> to neutron-lib and publish them under
> http://developer.openstack.org/api-ref/networking/ .
> I sounds reasonable to me.
> 
> We can have a dedicated pages for each stadium project like networking-sfc
> like api-ref/networking/service-function-chaining.
> At now all APIs are placed under v2/ directory, but it is not good
> both from user and
> maintenance perspectives.
> 
> 
> So, the next thing we need to clarify is what names and directory
> structure are appropropriate
> from the documentation perspective.
> My proposal is to prepare a dedicated directory per networking project
> repository.
> The directory name should be a function name rather than a project
> name. For example,
> - neutron => ???
> - neutron-lbaas => load-balancer
> - neutron-vpnaas => vpn
> - neutron-fwaas => firewall
> - neutron-dynamic-routing => dynamic-routing
> - networking-sfc => service-function-chaining
> - networking-l2gw => layer2-gateway
> - (networking-bgpvpn) => bgp-vpn
> 
> My remaining open questions are:
> 
> - Is 'v2' directory needed?
>   All networking API provided by stadium projects are extensions to
> Networking v2 API and "v2" is the only API we have now.
>   Do we place all APIs from stadium projects under 'v2' directory, or
> is 'v

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

[Henry Gessau]

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 questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Henry Gessau]

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 we
did not predict.

Most consuming subprojects have been pre-emptively updated to absorb the
change, while others will need to adjust reactively. See [2].

Note that sqlalchemy models can still access the tenant_id property as a
synonym for project_id, but in the database schema the column name is
project_id in all tables that have it.

If you encounter a problem due to this change, please reach out to us. Reply
here or use the #openstack-neutron IRC channel.

[1] https://review.openstack.org/335786
[2] https://etherpad.openstack.org/p/neutron-stadium-tenant2project

__
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][db][models]

[Henry Gessau]

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 refactoring
>> Db models. (https://bugs.launchpad.net/neutron/+bug/1597913). There are  
>> three way I can do this,
>> 1, move all models to db/models_v2.py 2, create a new dir db/models/ and  
>> move whatever models are giving issue
>> Of cyclic import to db_models.py under db/models/ tree but all in same  
>> file, 3rd is move into different files under
>> Same tree db/models. I liked second way better, please let me know which  
>> one according to experienced developers
>> is better, I’ll do that way.
> 
> I don’t think 2. is the best way forward because it still keeps all models  
> in a single file with no classification. I prefer we split models by topic,  
> so option 3.
> 
> I took the approach for security groups here:  
> https://review.openstack.org/#/c/284738/49/neutron/db/models/securitygroup.py

I also prefer this organization (option 3).


__
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] no neutron-lib meeting today

[Henry Gessau]

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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Henry Gessau]

Moshe Levi  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 model under networking_mlnx/db/models/.

> 2. mysql -e "drop database neutron; create database neutron;"
> 3. neutron-db-manage --subproject=neutron  upgrade heads

You should upgrade all heads here (leave out the --subproject option).

> 4. neutron-db-manage --subproject=networking-mlnx  revision -m "test" --expend

Hopefully you spelled it correctly: --expand. :)

> 
> Now I don't see the errors as before, but the migration script that was 
> generated 
> Looks like [3] and doesn't contain the new table.

Yes, I can reproduce this problem. We need to set up a head.py file that
includes all mlnx models. I need to remember how to correctly set up this
inclusion and I will get back to you.

> 
> Am I doing it wrong?  
> 
> [3] - 
> from alembic import op
> import sqlalchemy as sa
> 
> 
> # revision identifiers, used by Alembic.
> revision = 'cbb661581082'
> down_revision = '65b6db113427b9_initial_contract'
> 
> 
> def upgrade():
> pass
> 
> -Original Message-
> From: Henry Gessau [mailto:hen...@gessau.net] 
> Sent: Sunday, July 24, 2016 9:21 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: 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 
> contract). This is done by submitting a patch -- the contents of which used 
> to be crafted by copying a similar patch from another sub-project. The 
> patches to copy from are now out of date, so I have created a patch [2] for 
> you and we can use this as the new "template patch for initial alembic 
> migrations."
> 
> Some more comments inline ...
> 
> Moshe Levi  wrote:
>> Hi,
>>
>> I am trying to create initial db for the networking-mlnx project. 
>> I am following this neutron alembic documentation [1].
>> I added a entrypoint to networking-mlnx setup.cfg 
>> neutron.db.alembic_migrations =
>> networking-mlnx = networking_mlnx.db.migration:alembic_migrations
>> I added model.py file to networking-mlnx/networking_mlnx/db
>> And I run python setup.py develop to regenerate the entrypoint
>>
>> I am running the following commands:
>> 1. mysql -e "drop database neutron; create database neutron;"
>> 2. neutron-db-manage --subproject=neutron  upgrade heads
> 
> So far so good.
> 
>> 3. neutron-db-manage --subproject=networking-mlnx  revision -m "test" 
>> --autogenerate
> 
> Because we now require split (expand and contract) branches, you must now 
> specify --expand or --contract *instead of* --autogenerate. I will update the 
> devref about this.
> 
>> I am getting the following errors:
>> INFO  [alembic.runtime.migration] Context impl MySQLImpl.
>>
>> INFO  [alembic.runtime.migration] Will assume non-transactional DDL. 
>>
>> INFO  [alembic.autogenerate.compare] Detected removed table 
>> u'alembic_version'  
>> INFO  [alembic.autogenerate.compare] Detected removed index 
>> 'idx_autoinc_vr_id' on 'ha_router_vrid_allocations' 
>>   Generating 
>> /.autodirect/mtrswgwork/moshele/openstack/networking-mlnx/networking_mlnx/db/migration/alembic_migrations/versions/120e7e350bb1_test.py
>>  ... done
>>   OK 
>>  
>>
>> Traceback (most recent call last):   
>>  
>>
>>   File "/usr/bin/neutron-db-manage", line 10, in 
>>  
>>
>> sys.exit(main()) 
>>  
>>

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

[Henry Gessau]

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
contract). This is done by submitting a patch -- the contents of which used to
be crafted by copying a similar patch from another sub-project. The patches to
copy from are now out of date, so I have created a patch [2] for you and we
can use this as the new "template patch for initial alembic migrations."

Some more comments inline ...

Moshe Levi  wrote:
> Hi,
> 
> I am trying to create initial db for the networking-mlnx project. 
> I am following this neutron alembic documentation [1].
> I added a entrypoint to networking-mlnx setup.cfg
> neutron.db.alembic_migrations =
> networking-mlnx = networking_mlnx.db.migration:alembic_migrations
> I added model.py file to networking-mlnx/networking_mlnx/db
> And I run python setup.py develop to regenerate the entrypoint 
> 
> I am running the following commands:
> 1. mysql -e "drop database neutron; create database neutron;"
> 2. neutron-db-manage --subproject=neutron  upgrade heads

So far so good.

> 3. neutron-db-manage --subproject=networking-mlnx  revision -m "test" 
> --autogenerate

Because we now require split (expand and contract) branches, you must now
specify --expand or --contract *instead of* --autogenerate. I will update the
devref about this.

> I am getting the following errors:
> INFO  [alembic.runtime.migration] Context impl MySQLImpl. 
>   
> INFO  [alembic.runtime.migration] Will assume non-transactional DDL.  
>   
> INFO  [alembic.autogenerate.compare] Detected removed table 
> u'alembic_version'  
> INFO  [alembic.autogenerate.compare] Detected removed index 
> 'idx_autoinc_vr_id' on 'ha_router_vrid_allocations' 
>   Generating 
> /.autodirect/mtrswgwork/moshele/openstack/networking-mlnx/networking_mlnx/db/migration/alembic_migrations/versions/120e7e350bb1_test.py
>  ... done
>   OK  
>   
>  
> Traceback (most recent call last):
>   
>  
>   File "/usr/bin/neutron-db-manage", line 10, in  
>   
>  
> sys.exit(main())  
>   
>  
>   File 
> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>  line 689, in main
> return_val |= bool(CONF.command.func(config, CONF.command.name))  
>   
>  
>   File 
> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>  line 275, in do_revision 
> update_head_files(config) 
>   
>  
>   File 
> "/.autodirect/mtrswgwork/moshele/openstack/neutron/neutron/db/migration/cli.py",
>  line 398, in update_head_files   
> f.write(head_map[CONTRACT_BRANCH] + '\n') 
>   
>  
> KeyError: 'contract'
> 
> 
> And the migration script just dropping unrelated tables 

This should be fixed by env.py in [2].

> [moshele@r-dcs84 networking-mlnx]$ cat 
> /.autodirect/mtrswgwork/moshele/openstack/networking-mlnx/networking_mlnx/db/migration/alembic_migrations/versions/120e7e350bb1_test.py
> # revision identifiers, used by Alembic.
> revision = '120e7e350bb1'
> down_revision = None
> 
> from alembic import op
> import sqlalchemy as sa
> from sqlalchemy.dialects import mysql
> 
> def upgrade():
> ### commands auto generated by Alembic - please adjust! ###
> op.drop_table('alembic_version')
> op.drop_index('idx_autoinc_vr_id', 
> table_name='ha_router_vrid_allocations')
> ### end Alembic commands ###
> 
> 
> 
> It seem that the neutron alembic migration documentation [1] is out of date
> ( I don't see the --core_plugin flag in the neutron-db-manage man, but I do
> see the --subproject flag)
> 
> Does anyone know how to make it works? 

Yes, --core_plugin is defunct and I will remove it from the devref.

If you rebase on top of my patch [2] and run the revision command with
--expand y

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

[Henry Gessau]

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 consistently insightful and his
> numbers [1] are in line with others and I know will improve if given
> the responsibilities of a core reviewer. Jakub is deeply involved with
> the project's testing infrastructures and CI systems.
> 
> As a reminder the expectation from cores is found here [2], and
> specifically for cores interesting in helping out shaping Neutron's
> testing story:
> 
> * Guide community members to craft a testing strategy for features [3]
> * Ensure Neutron's testing infrastructures are sufficiently
> sophisticated to achieve the above.
> * Provide leadership when determining testing Do's & Don'ts [4]. What
> makes for an effective test?
> * Ensure the gate stays consistently green
> 
> And more tactically we're looking at finishing the Tempest/Neutron
> tests dedup [5] and to provide visual graphing for historical control
> and data plane performance results similar to [6].
> 
> [1] http://stackalytics.com/report/contribution/neutron/90
> [2] http://docs.openstack.org/developer/neutron/policies/neutron-teams.html
> [3] 
> http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
> [4] https://assafmuller.com/2015/05/17/testing-lightning-talk/
> [5] https://etherpad.openstack.org/p/neutron-tempest-defork
> [6] https://www.youtube.com/watch?v=a0qlsH1hoKs&feature=youtu.be&t=24m22s



__
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] Keystone V3 alignment: renaming tenant_id columns to project_id

[Henry Gessau]

Henry Gessau  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 currently
> out for review and will merge quite soon (shortly after N-2). This change
> renames all 'tenant_id' columns in the database to 'project_id'.
> 
> If you have any changes in flight that touch a tenant_id field, you will be
> affected. Please familiarize yourself with [3], rebase on it, and comply with
> the changes.
> 
> One patch known to be affected is [4].
> 
> The column rename change has been designed to have minimal impact on the usage
> of 'tenant_id' fields. For now 'tenant_id' is still available as a
> key/property in resource dicts and objects, and as an attribute in request
> contexts.
> 
> In the long run (Ocata or beyond) we want to end up with no usages of the term
> 'tenant', except in the API for backwards compatibility. Existing usages of
> 'tenant' in the codebase will be converted to 'project' on a case-by-case
> basis. Although the conversion has not yet commenced, any *new* fields,
> arguments, variables, etc. with 'tenant' in the name will no longer be 
> accepted.
> 
> [1] https://blueprints.launchpad.net/neutron/+spec/keystone-v3
> [2]
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/moving-to-keystone-v3.html
> [3] https://review.openstack.org/335786
> [4] https://review.openstack.org/244680

This work also affects repos that integrate with neutron and have tables in
the Neutron database. We have started to submit patches for the neutron-fwaas,
-lbaas, and -vpnaas repos, and we are keeping track of the progress with an
etherpad [5].

I have listed all the Neutron Stadium projects there, as well as all the
projects that I could find hosted on git.openstack.org that integrate with the
Neutron DB. Please help by signing up for a project.

If you encounter any problem or issues, please ask us for help. Either reply
to this email thread, or find me (HenryG) or Darek (dasm) in the Neutron IRC
channel.

[5] https://etherpad.openstack.org/p/neutron-stadium-tenant2project


__
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] Keystone V3 alignment: renaming tenant_id columns to project_id

[Henry Gessau]

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
renames all 'tenant_id' columns in the database to 'project_id'.

If you have any changes in flight that touch a tenant_id field, you will be
affected. Please familiarize yourself with [3], rebase on it, and comply with
the changes.

One patch known to be affected is [4].

The column rename change has been designed to have minimal impact on the usage
of 'tenant_id' fields. For now 'tenant_id' is still available as a
key/property in resource dicts and objects, and as an attribute in request
contexts.

In the long run (Ocata or beyond) we want to end up with no usages of the term
'tenant', except in the API for backwards compatibility. Existing usages of
'tenant' in the codebase will be converted to 'project' on a case-by-case
basis. Although the conversion has not yet commenced, any *new* fields,
arguments, variables, etc. with 'tenant' in the name will no longer be accepted.

[1] https://blueprints.launchpad.net/neutron/+spec/keystone-v3
[2]
http://specs.openstack.org/openstack/neutron-specs/specs/newton/moving-to-keystone-v3.html
[3] https://review.openstack.org/335786
[4] https://review.openstack.org/244680


__
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] New Python35 Jobs coming

[Henry Gessau]

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 voting python35 tests restricted to >=
> master/Newton on all projects that had python34 testing.
> 
> The expectation is that in many cases python35 tests will just work if
> python34 testing was also working. If this is the case for your project
> you can propose a change to openstack-infra/project-config to make these
> jobs voting against your project. You should only need to edit
> jenkins/jobs/projects.yaml and zuul/layout.yaml and remove the '-nv'
> portion of the python35 jobs to do this.
> 
> We do however expect that there will be a large group of failed tests
> too. If your project has a specific tox.ini py34 target to restrict
> python3 testing to a specific list of tests you will need to add a tox
> target for py35 that does the same thing as the py34 target. We have
> also seen bug reports against some projects whose tests rely on stable
> error messages from Python itself which isn't always the case across
> version changes so these tests will need to be updated as well.
> 
> Note this change will not add python35 jobs for cases where projects
> have special tox targets. This is restricted just to the default py35
> unittesting.
> 
> As always let us know if you questions,
> Clark

How soon can projects replace py34 with py35?

I tried py35 for neutron locally, and it ran without errors.


__
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] [keystone] cinder quota behavior differences after Keystone mitaka upgrade

[Henry Nash]

Hi Matt,

So the keystone changes were intentional. From Mitaka onwards, a domain is 
represented as a project which is “acting as a domain” (it has an attribute 
“is_domain” set to true). The situation you describe, where what were top level 
projects now have the project acting as the default domain as their parent, is 
what I would expect to happen after the update.

During Mitaka development, we  worked with the cinder folks - who were to 
re-designing their quota code anyway - and this was modified to take account of 
the project structure. I’m not sure if the quota semantics you see 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 Jun 2016, at 17:13, Matt Fischer  wrote:
> 
> We upgraded our dev environment last week to Keystone stable/mitaka. Since 
> then we're unable to show or set quotas on projects of which the admin is not 
> a member. Looking at the cinder code, it seems that cinder is pulling a 
> project list and attempting to determine a hierarchy.  On Liberty Keystone, 
> projects seem to lack parents:
> 
>  id=9e839870dd0d4a2f96f9d71b7e7c5a4e, is_domain=False, links={u'self': 
> u'https://liberty-endpoint:5000/v3/projects/9e839870dd0d4a2f96f9d71b7e7c5a4e' 
> <https://liberty-endpoint:5000/v3/projects/9e839870dd0d4a2f96f9d71b7e7c5a4e'>},
>  name=admin, parent_id=None, subtree=None>
> 
> In Mitaka, it seems that projects are children of the default domain:
> 
>  id=4764ba822ecb43e582794b875751924c, is_domain=False, links={u'self': 
> u'http://mitaka-endpoint:5000/v3/projects/4764ba822ecb43e582794b875751924c' 
> <http://mitaka-endpoint:5000/v3/projects/4764ba822ecb43e582794b875751924c'>}, 
> name=admin, parent_id=default, subtree=None>
> 
> In Liberty since all projects were parentless, the authorize_* code blocks 
> were skipped since both conditionals were false:
> 
> https://github.com/openstack/cinder/blob/stable/liberty/cinder/api/contrib/quotas.py#L174-L191
>  
> <https://github.com/openstack/cinder/blob/stable/liberty/cinder/api/contrib/quotas.py#L174-L191>
> 
> But now in Mitaka, the code is run, and it fails out since the projects are 
> "brothers", both with the parent of the default domain, but not 
> hierarchically related.
> 
> Previously it was a useful ability for us to be able to (as admins) set and 
> view  quotas for cinder projects. Now we need to scope into the user's 
> project to even be able to view their quotas, much less change them. This 
> seems broken, but I'm not sure where the issue is or why the keystone 
> behavior changed. Is this the expected behavior?
> 
> __
> 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] [keystone] Changing the project name uniqueness constraint

[Henry Nash]

Hi

So following discussion on this, I have modified the spec to try and take 
account of the various concerns etc. See: 
https://review.openstack.org/#/c/318605/

For reference, here is an extract from this spec that summarizes the level of 
compatibility being proposed (A “3.6 client” refers to a Mitaka or earlier 
client speaking either directly to keystone server, or via our client 
libraries):

Summary of Compatibility Impacts
-

Here is a summary of the impact on clients when the server they are talking to
is upgraded to Newton:

* For a 3.6 client the names of project entities created before the server
  upgrade will not change (i.e. they will not contain the path).
* For either a 3.6 or a 3.7 client, any projects entities after the server is
  upgraded will be returned with names including the path.
* A 3.6 client will continue to be able to scope an auth to a project that
  existed before the upgrade without specifying a path, wherever that project
  exists in the hierarchy. To scope to a project created after the upgrade then
  the name (by definition) includes the path.
* Code written that extracts the project name from any of the project APIs that
  returns project entities, and then plugs that name into an auth scope will
  continue to work unmodifed, irrespective of the version of the client or
  server
* A 3.7 client will always see project names that include the path,
  irrespective of whether those projects were created before or after the
  server was upgraded. The implication of this is that once a client has
  upgraded to 3.7, then if the name of the project is being entered by a user
  (say for auth scope), then this name must always contain the path. While,
  technically, we could try to maintain 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:22, Morgan Fainberg  wrote:
> 
> On Jun 14, 2016 00:46, "Henry Nash"  <mailto:henryna...@mac.com>> wrote:
> 
> 
>> On 14 Jun 2016, at 07:34, Morgan Fainberg > <mailto:morgan.fainb...@gmail.com>> wrote:
>> 
>> 
>> 
>> On Mon, Jun 13, 2016 at 3:30 PM, Henry Nash > <mailto:henryna...@mac.com>> wrote:
>> So, I think it depends what level of compatibility we are aiming at. Let me 
>> articulate them, and we can agree which we want:
>> 
>> C1) In all version of the our APIs today (v2 and v3.0 to v3.6), you have 
>> been able to issue an auth request which used project/tenant name as the 
>> scoping directive (with v3 you need a domain component as well, but that’s 
>> not relevant for this discussion). In these APIs, we absolutely expect that 
>> if you could issue an auth request to. say project “test”, in, say, v3.X, 
>> then you could absolutely issue the exact same command at V3.(X+1). This has 
>> remained true, even when we introduced project hierarchies, i.e.: if I 
>> create:
>> 
>> /development/myproject/test
>> 
>> ...then I can still scope directly to the test project by simply specifying 
>> “test” as the project name (since, of course, all project names must still 
>> be unique in the domain). We never want to break this for so long as we 
>> formally support any APIs that once allowed this.
>> 
>> C2) To aid you issuing an auth request scoped by project (either name or 
>> id), we support a special API as part of the auth url (GET/auth/projects) 
>> that lists the projects the caller *could* scope to (i.e. those they have 
>> any kind of role on). You can take the “name” or “id” returned by this API 
>> and plug it directly into the auth request. Again for any API we currently 
>> support, we can’t break this.
>> 
>> C3) The name attribute of a project is its node-name in the hierarchy. If we 
>> decide to change this in a future API, we would not want a client using the 
>> existing API to get surprised and suddenly receive a path instead of the 
>> just the node-name (e.g. what if this was a UI of some type). 
>> 
>> Given all the above, there is no solution that can keep the above all true 
>> and allow more than one project of the same name in, say, v3.7 of the API. 
>> Even if we relaxed C2 and C2 -  C1 can never be guaranteed to be still 
>> supported. Neither of the original proposed solutions can address this 
>> (since it is a data modelling problem, not an API problem).
>> 
>> However, given that we will have, for the first time, the ability to 
>> microversion the Identity API starting with 3.7, there are things we 

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

[Henry Nash]

…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  wrote:
> 
> Quick question: why do we need the service type or name in there? You really 
> should know what API you're talking to already and it's just something that 
> makes it more difficult to handle all the different APIs in a common way.
> 
> On Jun 18, 2016 8:25 PM, "Steve Martinelli"  <mailto:s.martine...@gmail.com>> wrote:
> Looks like Manila is using the service name instead of type 
> (X-OpenStack-Manila-API-Version) according to this link anyway: 
> http://docs.openstack.org/developer/manila/devref/api_microversion_dev.html 
> <http://docs.openstack.org/developer/manila/devref/api_microversion_dev.html>
> Keystone can follow the cross project spec and use the service type (Identity 
> instead of Keystone).
> 
> On Jun 17, 2016 12:44 PM, "Ed Leafe" mailto:e...@leafe.com>> 
> wrote:
> On Jun 17, 2016, at 11:29 AM, Henry Nash  <mailto:henryna...@mac.com>> wrote:
> 
> > We are currently in the process of implementing microversion support in 
> > keystone - and are obviously trying to follow the cross-projec spec for 
> > this 
> > (http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
> >  
> > <http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html>).
> >
> > One thing I noticed was that the header specified in this spec is of the 
> > form:
> >
> > OpenStack-API-Version: [SERVICE_TYPE] [X,Y]
> >
> > for example:
> >
> > OpenStack-API-Version: identity 3.7
> >
> > However, from what i can see of the current implementations I have seen of 
> > microversioning in OpenStack (Nova, Manilla), they use service-specific 
> > headers, e.g.
> >
> > X-OpenStack-Nova-API-Version: 2.12
> >
> > My question is whether there a plan to converge on the generalized header 
> > format….or are we keep with the service-specific headers? I’d obviously 
> > like to implement the correct one for keystone.
> 
> Yes, the plan is to converge on the more generic headers. The Nova headers 
> (don’t know about Manilla) pre-date the API WG spec, and were the motivation 
> for development of that spec. We’ve even made it possible to accept both 
> header formats [0] until things can be migrated to the recommended format.
> 
> [0] https://review.openstack.org/#/c/300077/ 
> <https://review.openstack.org/#/c/300077/>
> 
> -- Ed Leafe
> 
> 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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 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] Version header for OpenStack microversion support

[Henry Nash]

Hi

We are currently in the process of implementing microversion support in 
keystone - and are obviously trying to follow the cross-projec spec for this 
(http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
 
<http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html>).
 

One thing I noticed was that the header specified in this spec is of the form:

OpenStack-API-Version: [SERVICE_TYPE] [X,Y]

for example:

OpenStack-API-Version: identity 3.7

However, from what i can see of the current implementations I have seen of 
microversioning in OpenStack (Nova, Manilla), they use service-specific 
headers, e.g.

X-OpenStack-Nova-API-Version: 2.12

My question is whether there a plan to converge on the generalized header 
format….or are we keep with the service-specific headers? I’d obviously like to 
implement the correct 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/listinfo/openstack-dev

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

[Henry Nash]

> On 14 Jun 2016, at 07:34, Morgan Fainberg  wrote:
> 
> 
> 
> On Mon, Jun 13, 2016 at 3:30 PM, Henry Nash  <mailto:henryna...@mac.com>> wrote:
> So, I think it depends what level of compatibility we are aiming at. Let me 
> articulate them, and we can agree which we want:
> 
> C1) In all version of the our APIs today (v2 and v3.0 to v3.6), you have been 
> able to issue an auth request which used project/tenant name as the scoping 
> directive (with v3 you need a domain component as well, but that’s not 
> relevant for this discussion). In these APIs, we absolutely expect that if 
> you could issue an auth request to. say project “test”, in, say, v3.X, then 
> you could absolutely issue the exact same command at V3.(X+1). This has 
> remained true, even when we introduced project hierarchies, i.e.: if I create:
> 
> /development/myproject/test
> 
> ...then I can still scope directly to the test project by simply specifying 
> “test” as the project name (since, of course, all project names must still be 
> unique in the domain). We never want to break this for so long as we formally 
> support any APIs that once allowed this.
> 
> C2) To aid you issuing an auth request scoped by project (either name or id), 
> we support a special API as part of the auth url (GET/auth/projects) that 
> lists the projects the caller *could* scope to (i.e. those they have any kind 
> of role on). You can take the “name” or “id” returned by this API and plug it 
> directly into the auth request. Again for any API we currently support, we 
> can’t break this.
> 
> C3) The name attribute of a project is its node-name in the hierarchy. If we 
> decide to change this in a future API, we would not want a client using the 
> existing API to get surprised and suddenly receive a path instead of the just 
> the node-name (e.g. what if this was a UI of some type). 
> 
> Given all the above, there is no solution that can keep the above all true 
> and allow more than one project of the same name in, say, v3.7 of the API. 
> Even if we relaxed C2 and C2 -  C1 can never be guaranteed to be still 
> supported. Neither of the original proposed solutions can address this (since 
> it is a data modelling problem, not an API problem).
> 
> However, given that we will have, for the first time, the ability to 
> microversion the Identity API starting with 3.7, there are things we can do 
> to start us down this path. Let me re-articulate the options I am proposing:
> 
> Option 1A) In v3.7 we add a ‘path_name' attribute to a project entity, which 
> is hence returned by any API that returns a project entity. The ‘path_name' 
> attribute will contain the full path name, including the project itself. 
> (Note that clients speaking 3.6 and earlier will not see this new attribute). 
> Further, for clients speaking 3.7 and later, we add support to allow a 
> ‘path_name' (as an alternative to ‘name' or ‘id') to be used in auth scoping. 
> We do not (yet) relax any uniqueness constraints, but mark API 3.6 and 
> earlier as deprecated, as well as using the ‘name’ attribute in the auth 
> request. (we still support all these, we just mark them as deprecated). At 
> some time in the future (e.g. 3.8), we remove support for using ‘name’ for 
> auth, insisting on the use of ‘path_name’ instead. Sometime later (e.g. 3.10) 
> we remove support for 3.8 and earlier. Then and only then, do we relax the 
> uniqueness constraint allowing projects with duplicate node-names (but with 
> different parents).
> 
> Option 1B) The same as 1A, but we insist on path_name use in auth in v3.7 
> (i.e. no grace-period for still using just ’name', instead relying on the 
> fact that 3.6 clients will still work just fine). Then later (e.g. perhaps 
> v3.9), we remove support for v3.6 and before…and relax the uniqueness 
> constraint.
> 
> 
> Let say the assumption that we are "removing" 3.6 should be stopped right 
> now. I don't want to embark on the "when we remove this" as an option or 
> discuss how we remove previous versions. Please lets assume for the sake of 
> this conversation unless we have a major API version increase (API v4 and do 
> not expose v4 projects via v3 API) this is unlikely happen. Deprecated or 
> not, planning the removal of current supported API auth functionality is not 
> on the table. In v3 we are not going to "relax" the uniqueness constraint in 
> the foreseeable future. Just assume v3.6 is going to live forever for now and 
> we can revisit when/if limits on microversion lower bounds is addressed in 
> OpenStack with TC direction/guidance.

Why should we not be able to remove a microversion (once keystone properly 
supports microversioni

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

[Henry Nash]

 by 3.7 (since the ‘name’ attribute of a project entity may not 
contain what they expect). For 1A no changes are required at all for a client 
to work with 3.7 and maintain the current experience, although changes ARE of 
course required to start moving away from using the non-pathed ‘name’ 
attribute, but that doesn’t have to be done straight away, we give them a grace 
cycle. For 1B, you need to make changes to support 3.7 (since a path is 
required for auth).

As I have said before, my preference is Option 1, since I think it results in a 
more logical end position, and neither 1 or 2 get us there any more quickly. 
For option 1, I prefer the more gradual approach of 1A, just so that we give 
clients a grace period. Given we 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


> On 10 Jun 2016, at 18:48, Morgan Fainberg  wrote:
> 
> 
> 
> On Fri, Jun 10, 2016 at 6:37 AM, Henry Nash  <mailto:henryna...@mac.com>> wrote:
> On further reflection, it seems to me that we can never simply enable either 
> of these approaches in a single release. Even a v4.0 version of the API 
> doesn’t help - since presumably a sever supporting v4 would want to be able 
> to support v3.x for a signification time; and, already discussed, as soon as 
> you allow multiple none-names to have the same name, you can no longer 
> guarantee to support the current API.
> 
> Hence the only thing I think we can do (if we really do want to change the 
> current functionality) is to do this over several releases with a typical 
> deprecation cycle, e.g.
> 
> 1) At release 3.7 we allow you to (optionally) specify path names for 
> auth….but make no changes to the uniqueness constraints. We also change the 
> GET /auth/projects to return a path name. However, you can still auth exactly 
> the way we do today (since there will always only be a single project of a 
> given node-name). If however, you do auth without a path (to a project that 
> isn’t a top level project), we log a warning to say this is deprecated (2 
> cycles, 4 cycles?)
> 2) If you connect with a 3.6 client, then you get the same as today for GET 
> /auth/projects and cannot use a path name to auth.
> 3) At sometime in the future, we deprecate the “auth without a path” 
> capability. We can debate as to whether this has to be a major release.
> 
> If we take this gradual approach, I would be pushing for the “relax project 
> name constraints” approach…since I believe this leads to a cleaner eventual 
> 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
> 
> 
> How do you handle relaxed project name constraints without completely 
> breaking 3.6 auth - regardless of future microversion that requires the full 
> path. This is a major api change and will result in very complex matrix of 
> project name mapping (old projects that can be accessed without the full 
> path, new that must always have the path)?
> 
> Simply put, I do not see relaxing project name constraints as viable without 
> a major API change and projects that simply are unavailable for scoping a 
> token to under the base api version (pre-microversions) of 3.6
> 
> I am certain that if all projects post API version 3.6 are created with the 
> full-path name only and that is how they are represented to the user for 
> auth, we get both things for free. Old projects pre-full-path would need 
> optional compatibility for deconstructing a full-path for them.  Basically 
> you end up with "path" and "name", in old projects these differ, in new 
> projects they are the same.  No conflicts, not breaking "currently working 
> auth", no "major API version" needed.
> 
> --Morgan
>  
>> On 7 Jun 2016, at 09:47, Henry Nash > <mailto:henryna...@mac.com>> wrote:
>> 
>> OK, so thanks for the feedback - understand the message.
>> 
>> However, in terms of compatibility, the one thing that concerns me about the 
>> hierarchical naming approach is that even with microversioing, we might 
>> still surprise a client. An unmodified client (i.e. doesn’t understand 3.7) 
>> would still see a change in the data being returned (the project names have 
>> suddenly become full path names). We have to return this even if they don’t 
>> ask for 3.7, since otherwise there is no difference between this approach 
>> and relaxing the project naming in terms of trying to preven

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

[Henry Fourie]

+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 
contributor to the design/coding/testing of SFC CLI,  SFC Horizon, as well as 
ONOS controller support for SFC functionality. He has been great at helping out 
with bug fixes, testing, and reviews of all components of networking-sfc. He is 
also actively providing guidance to the users on their SFC setup, testing, and 
usage. Mohan showed a very good understanding of the networking-sfc design, 
code base, and its usage scenarios. Networking-sfc could use more cores as our 
user base and features have grown and I think he'd be a valuable addition.


Please respond with your +1 votes to approve this change or -1 votes to oppose.

Thanks,
Cathy
__
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] [keystone] Changing the project name uniqueness constraint

[Henry Nash]

On further reflection, it seems to me that we can never simply enable either of 
these approaches in a single release. Even a v4.0 version of the API doesn’t 
help - since presumably a sever supporting v4 would want to be able to support 
v3.x for a signification time; and, already discussed, as soon as you allow 
multiple none-names to have the same name, you can no longer guarantee to 
support the current API.

Hence the only thing I think we can do (if we really do want to change the 
current functionality) is to do this over several releases with a typical 
deprecation cycle, e.g.

1) At release 3.7 we allow you to (optionally) specify path names for auth….but 
make no changes to the uniqueness constraints. We also change the GET 
/auth/projects to return a path name. However, you can still auth exactly the 
way we do today (since there will always only be a single project of a given 
node-name). If however, you do auth without a path (to a project that isn’t a 
top level project), we log a warning to say this is deprecated (2 cycles, 4 
cycles?)
2) If you connect with a 3.6 client, then you get the same as today for GET 
/auth/projects and cannot use a path name to auth.
3) At sometime in the future, we deprecate the “auth without a path” 
capability. We can debate as to whether this has to be a major release.

If we take this gradual approach, I would be pushing for the “relax project 
name constraints” approach…since I believe this leads to a cleaner eventual 
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  wrote:
> 
> OK, so thanks for the feedback - understand the message.
> 
> However, in terms of compatibility, the one thing that concerns me about the 
> hierarchical naming approach is that even with microversioing, we might still 
> surprise a client. An unmodified client (i.e. doesn’t understand 3.7) would 
> still see a change in the data being returned (the project names have 
> suddenly become full path names). We have to return this even if they don’t 
> ask for 3.7, since otherwise there is no difference between this approach and 
> relaxing the project naming in terms of trying to prevent auth breakages.
> 
> In more detail:
> 
> 1) Both approaches were planned to return the path name (instead of the node 
> name) in GET /auth/projects - i.e. the API you are meant to use to find out 
> what you can scope to
> 2) Both approaches were planned to accept the path name in the auth request 
> block
> 3) The difference in hierarchical naming is the if I do a regular GET 
> /project(s) I also see the full path name as the “project name”
> 
> if we don’t do 3), then code that somehow authenticates, and then uses the 
> regular GET /project(s) calls to find a project name and then re-scopes (or 
> re-auths) to that name, will fail if the project they want is not a top level 
> project. However, the flip side is that if there is code that uses these same 
> calls to, say, display projects to the user (e.g. a home grown UI) - then it 
> might get confused until it supports 3.7 (i.e. asking for the old 
> microversion won’t help it) since 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 > <mailto:mord...@inaugust.com>> wrote:
>> 
>> On 06/04/2016 01:53 AM, Morgan Fainberg wrote:
>>> 
>>> On Jun 3, 2016 12:42, "Lance Bragstad" >> <mailto:lbrags...@gmail.com>
>>> <mailto:lbrags...@gmail.com <mailto:lbrags...@gmail.com>>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash >>> <mailto:henryna...@mac.com>
>>> <mailto:henryna...@mac.com <mailto:henryna...@mac.com>>> wrote:
>>>>> 
>>>>> 
>>>>>> On 3 Jun 2016, at 16:38, Lance Bragstad >>>>> <mailto:lbrags...@gmail.com>
>>> <mailto:lbrags...@gmail.com <mailto:lbrags...@gmail.com>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash >>>>> <mailto:henryna...@mac.com>
>>> <mailto:henryna...@mac.com <mailto:henryna...@mac.com>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On 3 Jun 2016, at 01:22, Adam Young >>>>>>> <mailto:ayo...@redhat.com>
>>> <mailto:ayo...@redhat.com <mailto:ayo...@redhat.com>>> wrote:
>>>>>>>> 
>

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

[Henry Fourie]

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 (not for usage questions)
Subject: Re: [openstack-dev] [neutron][SFC]

Thanks Mohan,

After setting service_plugins and adding sfc tables to neutrondb, I can create 
port-pair, port-pair-group but classifier creation still claim a 
logical-source-port parameter.

neutron flow-classifier-create  --ethertype IPv4  --source-ip-prefix 
55.55.55.2/32  --destination-ip-prefix 
55.55.55.9/32  --protocol tcp  --source-port 22:22  
--destination-port 1:65000 FC1
ERROR:
neutron flow-classifier-create: error: argument --logical-source-port is 
required
Try 'neutron help flow-classifier-create' for more information.

Please someone can explain what does --logical-source-port correspond to ?
Does the classifier require port-create like SF ?

Regards,


On 9 June 2016 at 09:21, Mohan Kumar 
mailto:nmohankumar1...@gmail.com>> wrote:
Alioune,

networking-sfc  resources not installed / not reachable , If installation is 
okay, Possibly you may missed service_plugins entry in neutron.conf ( in case 
of manual networking-sfc installation)

it should be ,

service_plugins = 
neutron.services.l3_router.l3_router_plugin.L3RouterPlugin,networking_sfc.services.flowclassifier.plugin.FlowClassifierPlugin,networking_sfc.services.sfc.plugin.SfcPlugin

and restart q-svc services in screen -x

Thanks.,
Mohankumar.N

On Thu, Jun 9, 2016 at 12:58 AM, Alioune 
mailto:baliou...@gmail.com>> wrote:
I've switched from devstack to a normal deployment of openstack/mitaka and 
neutron-l2 agent is working fine with sfc. I can boot instances, create ports.
However I can not create neither flow-classifier nor port-pair ...

neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix 
22.1.20.1/32 --destination-ip-prefix 
172.4.5.6/32 --protocol tcp --source-port 23:23 
--destination-port 100:100 FC1

returns: neutron flow-classifier-create: error: argument --logical-source-port 
is required
Try 'neutron help flow-classifier-create' for more information.

 neutron port-pair-create --ingress=p1 --egress=p2 PP1
404 Not Found

The resource could not be found.

Neutron server returns request_ids: ['req-1bfd0983-4a61-4b32-90b3-252004d90e65']

neutron --version
4.1.1

p1,p2,p3,p4 have already been created, I can ping instances attached to these 
ports.
Since I've not installed networking-sfc, are there additional config to set in 
neutron config files ?
Or is it due to neutron-client version ?

Regards

On 8 June 2016 at 20:31, Mohan Kumar 
mailto:nmohankumar1...@gmail.com>> wrote:

neutron agent not able to fetch details from ovsdb . Could you check below 
options 1.restart ovsdb-server and execute ovs_vsctl list-br  2.   execute ovs- 
vsctl list-br manually and try to check error.

3. Could be ovs cleanup issue , please check the output of sudo service 
openvswitch restart and /etc/init.d/openvswich** restart , both should be same

Thanks.,
Mohankumar.N
On Jun 7, 2016 6:04 PM, "Alioune" 
mailto:baliou...@gmail.com>> wrote:
Hi Mohan/Cathy
 I've installed now ovs 2.4.0 and followed 
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining but I got 
this error :
Regards,

+ neutron-ovs-cleanup
2016-06-07 11:25:36.465 22147 INFO neutron.common.config [-] Logging enabled!
2016-06-07 11:25:36.468 22147 INFO neutron.common.config [-] 
/usr/local/bin/neutron-ovs-cleanup version 7.1.1.dev4
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl [-] Unable 
to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 
'list-br'].
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl Traceback 
(most recent call last):
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl   File 
"/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 63, in run_vsctl
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl 
log_fail_as_error=False).rstrip()
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl   File 
"/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl raise 
RuntimeError(m)
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl RuntimeError:
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl Command: 
['sudo', 'ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 
'list-br']
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl Exit code: 1
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl
2016-06-07 11:25:36.512 22147 CRITICAL neutron [-] RuntimeError:
Command: [

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

[Henry Gessau]

One of the goals of neutron-lib is to reduce the chances of a code change in
neutron core breaking other repos. We want to get to a point where no repo
imports anything from neutron core.

So if there is some value shared between neutron core and one or more other
repos, then the value should go in neutron-lib.

Your question seems to be around "neutron reference implementation", but I
don't think that is relevant to what goes into neutron-lib.

You could argue that the values in neutron_lib/constants.py are big mix of
unrelated items, and that we may want to divide them up into separate
_constants.py modules. But then I could argue that would proliferate the
number of imports required for many repos.

Gal Sagie  wrote:
> For example references to the various different agents which are an
> implementation details to me
> 
> On Wed, Jun 8, 2016 at 8:51 PM, Henry Gessau  <mailto:hen...@gessau.net>> wrote:
> 
> Gal Sagie mailto:gal.sa...@gmail.com>> 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 reference implementation and are not really "generic" 
> Neutron
> > parts.
> 
> Can you give specific examples of 'not really generic' constants?
> 
> > I am wondering if this is the right approach, especially since i think 
> an
> > end goal is to split between the two (some day..)
> >
> > My suggestion would be to at least split these two in the neutron-lib, 
> but maybe
> > i miss understood the scope of the lib


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

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

[Henry Gessau]

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 reference implementation and are not really "generic" Neutron
> parts.

Can you give specific examples of 'not really generic' constants?

> I am wondering if this is the right approach, especially since i think an
> end goal is to split between the two (some day..)
> 
> My suggestion would be to at least split these two in the neutron-lib, but 
> maybe
> i miss understood the scope of the lib


__
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] [keystone] Changing the project name uniqueness constraint

[Henry Nash]

OK, so thanks for the feedback - understand the message.

However, in terms of compatibility, the one thing that concerns me about the 
hierarchical naming approach is that even with microversioing, we might still 
surprise a client. An unmodified client (i.e. doesn’t understand 3.7) would 
still see a change in the data being returned (the project names have suddenly 
become full path names). We have to return this even if they don’t ask for 3.7, 
since otherwise there is no difference between this approach and relaxing the 
project naming in terms of trying to prevent auth breakages.

In more detail:

1) Both approaches were planned to return the path name (instead of the node 
name) in GET /auth/projects - i.e. the API you are meant to use to find out 
what you can scope to
2) Both approaches were planned to accept the path name in the auth request 
block
3) The difference in hierarchical naming is the if I do a regular GET 
/project(s) I also see the full path name as the “project name”

if we don’t do 3), then code that somehow authenticates, and then uses the 
regular GET /project(s) calls to find a project name and then re-scopes (or 
re-auths) to that name, will fail if the project they want is not a top level 
project. However, the flip side is that if there is code that uses these same 
calls to, say, display projects to the user (e.g. a home grown UI) - then it 
might get confused until it supports 3.7 (i.e. asking for the old microversion 
won’t help it) since 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  wrote:
> 
> On 06/04/2016 01:53 AM, Morgan Fainberg wrote:
>> 
>> On Jun 3, 2016 12:42, "Lance Bragstad" > <mailto:lbrags...@gmail.com>
>> <mailto:lbrags...@gmail.com <mailto:lbrags...@gmail.com>>> wrote:
>>> 
>>> 
>>> 
>>> On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash >> <mailto:henryna...@mac.com>
>> <mailto:henryna...@mac.com <mailto:henryna...@mac.com>>> wrote:
>>>> 
>>>> 
>>>>> On 3 Jun 2016, at 16:38, Lance Bragstad >>>> <mailto:lbrags...@gmail.com>
>> <mailto:lbrags...@gmail.com <mailto:lbrags...@gmail.com>>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash >>>> <mailto:henryna...@mac.com>
>> <mailto:henryna...@mac.com <mailto:henryna...@mac.com>>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 3 Jun 2016, at 01:22, Adam Young >>>>>> <mailto:ayo...@redhat.com>
>> <mailto:ayo...@redhat.com <mailto: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 of this is to
>> better support project hierarchies, which as they stand today are
>> restrictive in that all project names within a domain must be unique,
>> irrespective of where in the hierarchy that projects sits (unlike, say,
>> the unix directory structure where a node name only has to be unique
>> within its parent). Such a restriction is particularly problematic when
>> enterprise start modelling things like test, QA and production as
>> branches of a project hierarchy, e.g.:
>>>>>>>> 
>>>>>>>> /mydivsion/projectA/dev
>>>>>>>> /mydivsion/projectA/QA
>>>>>>>> /mydivsion/projectA/prod
>>>>>>>> /mydivsion/projectB/dev
>>>>>>>> /mydivsion/projectB/QA
>>>>>>>> /mydivsion/projectB/prod
>>>>>>>> 
>>>>>>>> Obviously the idea of a project name (née tenant) being unique
>> has been around since near the beginning of (OpenStack) time, so we must
>> be cautions. There are two alternative specs proposed:
>>>>>>>> 
>>>>>>>> 1) Relax project name
>> constraints: https://review.openstack.org/#/c/310048/ 
>>>>>>>> 2) Hierarchical project
>> naming: https://review.openstack.org/#/c/318605/
>>>>>>>> 
>>>>>>>> First, here’s what they have in common:
>>>>>>>> 
>>>>>>>> a) They both solve the above problem
>>>>>>>> b) They both allow

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

[Henry Fourie]

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 
supported in stable/mitaka?
Thanks
Gary
__
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] [keystone] Changing the project name uniqueness constraint

[Henry Nash]

Both proposals allow you to provide a path as the project name in auth (so you 
can still use domain name + project path name). The difference between the two 
is whether you formally represent the path in the name attribute of a project, 
i.e. when it is returned by GET /project.  The relax name 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  wrote:
> 
> 
> On Jun 3, 2016 12:42, "Lance Bragstad"  <mailto:lbrags...@gmail.com>> wrote:
> >
> >
> >
> > On Fri, Jun 3, 2016 at 11:20 AM, Henry Nash  > <mailto:henryna...@mac.com>> wrote:
> >>
> >>
> >>> On 3 Jun 2016, at 16:38, Lance Bragstad  >>> <mailto:lbrags...@gmail.com>> wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash  >>> <mailto:henryna...@mac.com>> wrote:
> >>>>
> >>>>
> >>>>> On 3 Jun 2016, at 01:22, Adam Young  >>>>> <mailto: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 of this is 
> >>>>>> to better support project hierarchies, which as they stand today are 
> >>>>>> restrictive in that all project names within a domain must be unique, 
> >>>>>> irrespective of where in the hierarchy that projects sits (unlike, 
> >>>>>> say, the unix directory structure where a node name only has to be 
> >>>>>> unique within its parent). Such a restriction is particularly 
> >>>>>> problematic when enterprise start modelling things like test, QA and 
> >>>>>> production as branches of a project hierarchy, e.g.:
> >>>>>>
> >>>>>> /mydivsion/projectA/dev
> >>>>>> /mydivsion/projectA/QA
> >>>>>> /mydivsion/projectA/prod
> >>>>>> /mydivsion/projectB/dev
> >>>>>> /mydivsion/projectB/QA
> >>>>>> /mydivsion/projectB/prod
> >>>>>>
> >>>>>> Obviously the idea of a project name (née tenant) being unique has 
> >>>>>> been around since near the beginning of (OpenStack) time, so we must 
> >>>>>> be cautions. There are two alternative specs proposed:
> >>>>>>
> >>>>>> 1) Relax project name constraints: 
> >>>>>> https://review.openstack.org/#/c/310048/ 
> >>>>>> <https://review.openstack.org/#/c/310048/> 
> >>>>>> 2) Hierarchical project naming: 
> >>>>>> https://review.openstack.org/#/c/318605/ 
> >>>>>> <https://review.openstack.org/#/c/318605/>
> >>>>>>
> >>>>>> First, here’s what they have in common:
> >>>>>>
> >>>>>> a) They both solve the above problem
> >>>>>> b) They both allow an authorization scope to use a path rather than 
> >>>>>> just a simple name, hence allowing you to address a project anywhere 
> >>>>>> in the hierarchy
> >>>>>> c) Neither have any impact if you are NOT using a hierarchy - i.e. if 
> >>>>>> you just have a flat layer of projects in a domain, then they have no 
> >>>>>> API or semantic impact (since both ensure that a project’s name must 
> >>>>>> still be unique within a parent)
> >>>>>>
> >>>>>> Here’s how the differ:
> >>>>>>
> >>>>>> - Relax project name constraints (1), keeps the meaning of the ‘name’ 
> >>>>>> attribute of a project to be its node-name in the hierarchy, but 
> >>>>>> formally relaxes the uniqueness constraint to say that it only has to 
> >>>>>> be unique within its parent. In other words, let’s really model this a 
> >>>>>> bit like a unix directory tree.
> >>>
> >>> I think I lean towards relaxing the project name constraint. The reason 
> >>> is beca

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

[Henry Gessau]

Carl Baldwin  wrote:
> On Fri, Jun 3, 2016 at 2:26 PM, Henry Gessau  wrote:
>> 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.
> 
> To me, this is a nonsensical outcome and tells me that subnets
> probably shouldn't really have owners distinct from the network's.

Right. So are you saying we should prevent that?



__
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] Elevating context to remove subnets created by admin

[Henry Gessau]

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 messed things up for the user.

[1] https://bugs.launchpad.net/neutron/+bug/1588228

__
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] [keystone] Changing the project name uniqueness constraint

[Henry Nash]

> On 3 Jun 2016, at 16:38, Lance Bragstad  wrote:
> 
> 
> 
> On Fri, Jun 3, 2016 at 3:20 AM, Henry Nash  <mailto:henryna...@mac.com>> wrote:
> 
>> On 3 Jun 2016, at 01:22, Adam Young > <mailto: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 of this is to better 
>>> support project hierarchies, which as they stand today are restrictive in 
>>> that all project names within a domain must be unique, irrespective of 
>>> where in the hierarchy that projects sits (unlike, say, the unix directory 
>>> structure where a node name only has to be unique within its parent). Such 
>>> a restriction is particularly problematic when enterprise start modelling 
>>> things like test, QA and production as branches of a project hierarchy, 
>>> e.g.:
>>> 
>>> /mydivsion/projectA/dev
>>> /mydivsion/projectA/QA
>>> /mydivsion/projectA/prod
>>> /mydivsion/projectB/dev
>>> /mydivsion/projectB/QA
>>> /mydivsion/projectB/prod
>>> 
>>> Obviously the idea of a project name (née tenant) being unique has been 
>>> around since near the beginning of (OpenStack) time, so we must be 
>>> cautions. There are two alternative specs proposed:
>>> 
>>> 1) Relax project name constraints:  
>>> <https://review.openstack.org/#/c/310048/>https://review.openstack.org/#/c/310048/
>>>  <https://review.openstack.org/#/c/310048/> 
>>> 2) Hierarchical project naming:  
>>> <https://review.openstack.org/#/c/318605/>https://review.openstack.org/#/c/318605/
>>>  <https://review.openstack.org/#/c/318605/>
>>> 
>>> First, here’s what they have in common:
>>> 
>>> a) They both solve the above problem
>>> b) They both allow an authorization scope to use a path rather than just a 
>>> simple name, hence allowing you to address a project anywhere in the 
>>> hierarchy
>>> c) Neither have any impact if you are NOT using a hierarchy - i.e. if you 
>>> just have a flat layer of projects in a domain, then they have no API or 
>>> semantic impact (since both ensure that a project’s name must still be 
>>> unique within a parent)
>>> 
>>> Here’s how the differ:
>>> 
>>> - Relax project name constraints (1), keeps the meaning of the ‘name’ 
>>> attribute of a project to be its node-name in the hierarchy, but formally 
>>> relaxes the uniqueness constraint to say that it only has to be unique 
>>> within its parent. In other words, let’s really model this a bit like a 
>>> unix directory tree.
> 
> I think I lean towards relaxing the project name constraint. The reason is 
> because we already expose `domain_id`, `parent_id`, and `name` of a project. 
> By relaxing the constraint we can give the user everything the need to know 
> about a project without really changing any of these. When using 3.7, you 
> know what domain your project is in, you know the identifier of the parent 
> project, and you know that your project name is unique within the parent.  
>>> - Hierarchical project naming (2), formally changes the meaning of the 
>>> ‘name’ attribute to include the path to the node as well as the node name, 
>>> and hence ensures that the (new) value of the name attribute remains unique.
> 
> Do we intend to *store* the full path as the name, or just build it out on 
> demand? If we do store the full path, we will have to think about our current 
> data model since the depth of the organization or domain would be limited by 
> the max possible name length. Will performance be something to think about 
> building the full path on every request?   
I now mention this issue in the spec for hierarchical project naming (the relax 
naming approach does not suffer this issue). As you say, we’ll have to change 
the DB (today it is only 64 chars) if we do store the full path . This is 
slightly problematic since the maximum depth of hierarchy is controlled by a 
config option, and hence could be changed. We will absolutely have be able to 
build the path on-the-fly in order to support legacy drivers (who won’t be able 
to store more than 64 chars). We may need to do some performance tests to 
ascertain if we can get away with building the path on-the-fly in all cases and 
avoid changing the table.  One additional point is that, of course, the API 
will return this path whenever it returns a project - so clients will need to 
be aw

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

[Henry Nash]

> On 3 Jun 2016, at 01:22, Adam Young  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 of this is to better support 
>> project hierarchies, which as they stand today are restrictive in that all 
>> project names within a domain must be unique, irrespective of where in the 
>> hierarchy that projects sits (unlike, say, the unix directory structure 
>> where a node name only has to be unique within its parent). Such a 
>> restriction is particularly problematic when enterprise start modelling 
>> things like test, QA and production as branches of a project hierarchy, e.g.:
>> 
>> /mydivsion/projectA/dev
>> /mydivsion/projectA/QA
>> /mydivsion/projectA/prod
>> /mydivsion/projectB/dev
>> /mydivsion/projectB/QA
>> /mydivsion/projectB/prod
>> 
>> Obviously the idea of a project name (née tenant) being unique has been 
>> around since near the beginning of (OpenStack) time, so we must be cautions. 
>> There are two alternative specs proposed:
>> 
>> 1) Relax project name constraints:  
>> <https://review.openstack.org/#/c/310048/>https://review.openstack.org/#/c/310048/
>>  <https://review.openstack.org/#/c/310048/> 
>> 2) Hierarchical project naming:  
>> <https://review.openstack.org/#/c/318605/>https://review.openstack.org/#/c/318605/
>>  <https://review.openstack.org/#/c/318605/>
>> 
>> First, here’s what they have in common:
>> 
>> a) They both solve the above problem
>> b) They both allow an authorization scope to use a path rather than just a 
>> simple name, hence allowing you to address a project anywhere in the 
>> hierarchy
>> c) Neither have any impact if you are NOT using a hierarchy - i.e. if you 
>> just have a flat layer of projects in a domain, then they have no API or 
>> semantic impact (since both ensure that a project’s name must still be 
>> unique within a parent)
>> 
>> Here’s how the differ:
>> 
>> - Relax project name constraints (1), keeps the meaning of the ‘name’ 
>> attribute of a project to be its node-name in the hierarchy, but formally 
>> relaxes the uniqueness constraint to say that it only has to be unique 
>> within its parent. In other words, let’s really model this a bit like a unix 
>> directory tree.
>> - Hierarchical project naming (2), formally changes the meaning of the 
>> ‘name’ attribute to include the path to the node as well as the node name, 
>> and hence ensures that the (new) value of the name attribute remains unique.
>> 
>> While whichever approach we chose would only be included in a new 
>> microversion (3.7) of the Identity API, although some relevant APIs can 
>> remain unaffected for a client talking 3.6 to a Newton server, not all can 
>> be. As pointed out be jamielennox, this is a data modelling problem - if a 
>> Newton server has created multiple projects called “dev” in the hierarchy, a 
>> 3.6 client trying to scope a token simply to “dev” cannot be answered 
>> correctly (and it is proposed we would have to return an HTTP 409 Conflict 
>> error if multiple nodes with the same name were detected). This is true for 
>> both approaches.
>> 
>> Other comments on the approaches:
>> 
>> - Having a full path as the name seems duplicative with the current project 
>> entity - since we already return the parent_id (hence parent_id + name is, 
>> today, sufficient to place a project in the hierarchy).
> 
> The one thing I like is the ability to specify just the full path for the 
> OS_PROJECT_NAME env var, but we could make that a separate variable.  Just as 
> DOMAIN_ID + PROJECT_NAME is unique today, OS_PROJECT_PATH should be able to 
> fully specify a project unambiguously.  I'm not sure which would have a 
> larger impact on users.
> 
Agreed - and this could be done for both approaches (since this is all part of 
the “auth data flow").
> 
>> - In the past, we have been concerned about the issue of what we do if there 
>> is a project further up the tree that we do not have any roles on. In such 
>> cases, APIs like list project parents will not display anything other than 
>> the project ID for such projects. In the case of making the name the full 
>> path, we would be effectively exposing the name of all projects above us, 
>> irrespective of whether we had roles on them. Maybe this is OK, maybe it 
>> isn’t.
> 
> I think it is OK.  If this info needs to be hidden from a user, the project 
> 

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

[Henry Nash]

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 of this is to better support 
project hierarchies, which as they stand today are restrictive in that all 
project names within a domain must be unique, irrespective of where in the 
hierarchy that projects sits (unlike, say, the unix directory structure where a 
node name only has to be unique within its parent). Such a restriction is 
particularly problematic when enterprise start modelling things like test, QA 
and production as branches of a project hierarchy, e.g.:

/mydivsion/projectA/dev
/mydivsion/projectA/QA
/mydivsion/projectA/prod
/mydivsion/projectB/dev
/mydivsion/projectB/QA
/mydivsion/projectB/prod

Obviously the idea of a project name (née tenant) being unique has been around 
since near the beginning of (OpenStack) time, so we must be cautions. There are 
two alternative specs proposed:

1) Relax project name constraints: https://review.openstack.org/#/c/310048/ 
<https://review.openstack.org/#/c/310048/> 
2) Hierarchical project naming: https://review.openstack.org/#/c/318605/ 
<https://review.openstack.org/#/c/318605/>

First, here’s what they have in common:

a) They both solve the above problem
b) They both allow an authorization scope to use a path rather than just a 
simple name, hence allowing you to address a project anywhere in the hierarchy
c) Neither have any impact if you are NOT using a hierarchy - i.e. if you just 
have a flat layer of projects in a domain, then they have no API or semantic 
impact (since both ensure that a project’s name must still be unique within a 
parent)

Here’s how the differ:

- Relax project name constraints (1), keeps the meaning of the ‘name’ attribute 
of a project to be its node-name in the hierarchy, but formally relaxes the 
uniqueness constraint to say that it only has to be unique within its parent. 
In other words, let’s really model this a bit like a unix directory tree.
- Hierarchical project naming (2), formally changes the meaning of the ‘name’ 
attribute to include the path to the node as well as the node name, and hence 
ensures that the (new) value of the name attribute remains unique.

While whichever approach we chose would only be included in a new microversion 
(3.7) of the Identity API, although some relevant APIs can remain unaffected 
for a client talking 3.6 to a Newton server, not all can be. As pointed out be 
jamielennox, this is a data modelling problem - if a Newton server has created 
multiple projects called “dev” in the hierarchy, a 3.6 client trying to scope a 
token simply to “dev” cannot be answered correctly (and it is proposed we would 
have to return an HTTP 409 Conflict error if multiple nodes with the same name 
were detected). This is true for both approaches.

Other comments on the approaches:

- Having a full path as the name seems duplicative with the current project 
entity - since we already return the parent_id (hence parent_id + name is, 
today, sufficient to place a project in the hierarchy).
- In the past, we have been concerned about the issue of what we do if there is 
a project further up the tree that we do not have any roles on. In such cases, 
APIs like list project parents will not display anything other than the project 
ID for such projects. In the case of making the name the full path, we would be 
effectively exposing the name of all projects above us, irrespective of whether 
we had roles on them. Maybe this is OK, maybe it isn’t.
- While making the name the path keeps it unique, this is fine if clients 
blindly use this attribute to plug back into another API to call. However if, 
for example, you are Horizon and are displaying them in a UI then you need to 
start breaking down the path into its components, where you don’t today.
- One area where names as the hierarchical path DOES look right is calling the 
/auth/projects API - where what the caller wants is a list of projects they can 
scope to - so you WANT this to be the path you can put in an auth request.

Given that neither can fully protect a 3.6 client, my personal preference is to 
go with the cleaner logical approach which I believe is the Relax project name 
constraints (1), with the addition of changing GET /auth/projects to return the 
path (since this is a specialised API that happens before authentication) - but 
I am open to persuasion (as the song goes).

There are those that might say that perhaps we just can’t change this. I would 
argue that since this ONLY affects people who actually create hierarchies and 
that today such hierarchical use is in its infancy, then now IS the time to 
change this. If we leave it too long, then it will become really hard to change 
what will by then have become a tough restriction.

Henry


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst

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

[Henry Fourie]

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 Pfaff; OpenStack Development Mailing 
List; disc...@openvswitch.org
Subject: Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
mailto:jmcdow...@paloaltonetworks.com>> wrote 
on 05/26/2016 11:08:43 AM:

> From: John McDowall 
> mailto:jmcdow...@paloaltonetworks.com>>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff mailto:b...@ovn.org>>, 
> "disc...@openvswitch.org"
> mailto:disc...@openvswitch.org>>, Justin Pettit 
> mailto:jpet...@ovn.org>>,
> "OpenStack Development Mailing List"  d...@lists.openstack.org>, Russell Bryant 
> mailto:russ...@ovn.org>>
> Date: 05/26/2016 11:09 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> My (incomplete) throughts about the flow-classifier are:
>
> 1)  ACL’s are more about denying access, while the flow classifier
> is more about steering selected traffic to a path, so we would need
> to deny-all except allowed flows.
> 2)  The networking-sfc team has done a nice job with the drivers so
> ovn has its own flow-classifier driver which allows us to align the
> flow-classifier with the matches supported in ovs/ovn, which could
> be an advantage.

The ACL table has a very simple flow-classifier structure and I'd
like to see if that can be re-used for the purpose of the SFC classifier
(read that I feel the Logical_Flow_Classifier table is too complex).
My initial thoughts were to look at extending the action column and
using the external-ids field to differentiate between legacy ACLs and
those that are used to intercept traffic and route it to an SFC.

>
> What were your thoughts on the schema it adds a lot of tables and a
> lot of commands – cannot think of anyway around it

In this case, I think that the other tables are reasonable and I'm
uncomfortable trying to stretch the existing tables to cover that
information...

Ryan

>
> Regards
>
> John
>
> From: Ryan Moats mailto:rmo...@us.ibm.com>>
> Date: Wednesday, May 25, 2016 at 9:12 PM
> To: John McDowall 
> mailto:jmcdow...@paloaltonetworks.com>>
> Cc: Ben Pfaff mailto:b...@ovn.org>>, 
> "disc...@openvswitch.org" <
> disc...@openvswitch.org>, Justin Pettit 
> mailto:jpet...@ovn.org>>, OpenStack
> Development Mailing List 
> mailto:openstack-dev@lists.openstack.org>>,
>  Russell Bryant <
> russ...@ovn.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall 
> mailto:jmcdow...@paloaltonetworks.com>> wrote 
> on 05/25/2016
> 07:27:46 PM:
>
> > From: John McDowall 
> > mailto:jmcdow...@paloaltonetworks.com>>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" 
> > mailto:disc...@openvswitch.org>>, "OpenStack
> > Development Mailing List" 
> > mailto:openstack-dev@lists.openstack.org>>,
> >  Ben
> > Pfaff mailto:b...@ovn.org>>, Justin Pettit 
> > mailto:jpet...@ovn.org>>, Russell Bryant
> > mailto:russ...@ovn.org>>
> > Date: 05/25/2016 07:28 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Ok – I will let the experts weigh in on load balancing.
> >
> > In the meantime I have attached a couple of files to show where I am
> > going. The first is sfc_dict.py and is a representation of the dict
> > I am passing from SFC to OVN. This will then translate to the
> > attached ovn-nb schema file.
> >
> > One of my concerns is that SFC almost doubles the size of the ovn-nb
> > schema but I could not think of any other way of doing it.
> >
> > Thoughts?
> >
> > John
>
> The dictionary looks fine for a starting point, and the more I look
> at the classifier, the more I wonder if we can't do something with
> the current ACL table to avoid duplication in the NB database
> definition...
>
> Ryan
>
> > From: Ryan Moats mailto:rmo...@us.ibm.com>>
> > Date: Wednesday, May 25, 2016 at 7:27 AM
> > To: John McDowall 
> > mailto:jmcdow...@paloaltonetworks.com>>
> > Cc: "disc...@openvswitch.org" 
> > mailto:disc...@openvswitch.org>>, OpenStack
> > Development Mailing List 
> > mailto:openstack-dev@lists.openstack.org>>,
> >  Ben Pfaff <
> > b...@ovn.org>, Justin Pettit 
> > mailto:jpet...@ovn.org>>, Russell Bryant <
> russ...@ovn.org
> > >
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > John McDowall 
> > mailto:jmcdow...@paloaltonetworks.com>> 
> > wrote on 05/24/2016
> > 06:33:05 PM:
> >
> > > From: John McDowall 
> > > mailto:jmcdow...@paloaltonetworks.com>>
> > > To: Ryan Moats/Omaha/IBM@IBMUS
> > > Cc: "dis

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

[Henry Gessau]

Thierry Carrez  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, 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 attend, and
>>> make updates to topics that you would like to work on.
>>
>> Thanks for organizing this! I am happy to see a sprint in Europe :)
>> Unfortunately the 15th is bank holidays in some European countries and
>> at least in Italy most people organize their holidays around those days.
>> I will try to change my plans and do my best to attend.
> 
> For reference, Assumption (Aug 15) is a nationwide public holiday in the 
> following countries in Europe:
> 
> Andorra, Austria, Belgium, Croatia, Cyprus, France, Greece, Italy, 
> Lithuania, Luxembourg, Republic of Macedonia, Malta, Republic of 
> Moldova, Monaco, Poland (Polish Army Day), Portugal, Romania, Slovenia, 
> and Spain.
> 
> Beyond people generally organizing summer vacation around that date, 
> it's also peak-season for European travel, which can make flight prices 
> go up :)
> 
> But then, no date is perfect.
> 

After some discussions I have decided to keep this week but change it slightly
to the end of the week, Wednesday to Friday.

I other words, August 17-19. Same location.
I have updated the wiki and the etherpad.

-- 
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/listinfo/openstack-dev

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

[Henry Gessau]

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 attend, and
make updates to topics that you would like to work on.


[1] https://wiki.openstack.org/wiki/Sprints#Newton_sprints



__
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] [keystone] New Core Reviewer (sent on behalf of Steve Martinelli)

[Henry Nash]

Congratulations - thanks for your continued commitment to OpenStack and 
keystone.

Henry

> On 25 May 2016, at 23:58, Rodrigo Duarte  wrote:
> 
> Thank you all, it's a privilege to be part of a team from where I've learned 
> so much. =)
> 
>> On Wed, May 25, 2016 at 1:05 PM, Brad Topol  wrote:
>> CONGRATULATIONS Rodrigo!!! Very well deserved!!!
>> 
>> --Brad
>> 
>> 
>> Brad Topol, Ph.D.
>> IBM Distinguished Engineer
>> OpenStack
>> (919) 543-0646
>> Internet: bto...@us.ibm.com
>> Assistant: Kendra Witherspoon (919) 254-0680
>> 
>> Lance Bragstad ---05/25/2016 09:09:55 AM---Congratulations 
>> Rodrigo! Thank you for all the continued and consistent reviews.
>> 
>> From: Lance Bragstad 
>> To: "OpenStack Development Mailing List (not for usage questions)" 
>> 
>> Date: 05/25/2016 09:09 AM
>> Subject: Re: [openstack-dev] [keystone] New Core Reviewer (sent on behalf of 
>> Steve Martinelli)
>> 
>> 
>> 
>> 
>> Congratulations Rodrigo!
>> 
>> Thank you for all the continued and consistent reviews.
>> 
>> On Tue, May 24, 2016 at 1:28 PM, Morgan Fainberg  
>> wrote:
>> I want to welcome Rodrigo Duarte (rodrigods) to the keystone core team. 
>> Rodrigo has been a consistent contributor to keystone and has been 
>> instrumental in the federation implementations. Over the last cycle he has 
>> shown an understanding of the code base and contributed quality reviews.
>> 
>> I am super happy (as proxy for Steve) to welcome Rodrigo to the Keystone 
>> Core team.
>> 
>> Cheers,
>> --Morgan
>> 
>> __
>> 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 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
> 
> 
> 
> -- 
> Rodrigo Duarte Sousa
> Senior Quality Engineer @ Red Hat
> MSc in Computer Science
> http://rodrigods.com
> __
> 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] [neutron] [networking-sfc] Adding use case to wiki?

[Henry Fourie]

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] [neutron] [networking-sfc] Adding use case to wiki?

Hi networking-sfc,

As discussed at the last meeting I was to add the SFC Encapsulation use case to 
the networking-sfc wiki:
#action paul, john igor to add use-cases to wiki

Where exactly is the place to insert use cases in the wiki? Is there one 
already?
None of these seem to have any section for that purpose:
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
https://wiki.openstack.org/wiki/Neutron/APIForServiceChaining

Best regards,
Igor.

__
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][TC] support of NSH in networking-SFC

[Henry Fourie]

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, 2016 5:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][TC] support of NSH in networking-SFC

In a nutshell, you’ve got it, you can’t add an API without a reference 
implementation, including data-plane, which has to be open-source (though does 
not have to itself be openstack.)

o   Especially as Stadium, can we let Neutron to lead the industry, given broad 
enough community interest?

You can do anything you want outside the stadium, which is where 
experimental/incubation is meant to happen.  Inside the stadium means, 
“official openstack project”, which means it has an open-source implementation.

If all backends are closed-source, it’s not open as openstack defines it: 
https://governance.openstack.org/reference/opens.html

There isn’t any wiggle room there. This isn’t a neutron argument; feel free to 
take it up with the TC.

Thanks,
doug



On May 20, 2016, at 6:37 PM, Elzur, Uri 
mailto:uri.el...@intel.com>> wrote:

Hi Armando, Cathy, All

First I apologize for the delay, returning from a week long international trip. 
(yes, I know,  a lousy excuse on many accounts…)

If I’m attempting to summarize all the responses, it seems like
• A given abstraction in Neutron is allowed (e.g. in support of SFC), 
preferably not specific to a given technology e.g. NSH for SFC
• A stadium project is not held to the same tests (but we do not have a 
“formal” model here, today) and therefore can support even a specific 
technology e.g. NSH (definitely better with abstractions to meet Neutron 
standards for future integration)

However,
• There still is a chicken and egg phenomenon… how can a technology 
become main stream with OPEN SOURCE support  if we can’t get an OpenStack to 
support the required abstractions before the technology was adopted elsewhere??
o   Especially as Stadium, can we let Neutron to lead the industry, given broad 
enough community interest?
• BTW,  in this particular case, there originally has been a direct ODL 
access as a NSH solution (i.e. NO OpenStack option), then we got Tacker (now an 
Neutron Stadium project, if I get it right) to support SFC and NSH, but we are 
still told that networking-sfc (another Neutron Stadium project ) can’t do the 
same….
• Also regarding the  following comment made on another message in this 
thread, “As to OvS features, I guess the OvS ml is a better place, but wonder 
if the Neutron community wants to hold itself hostage to the pace of other 
projects who are reluctant to adopt a feature”, what I mean is again, that 
chicken and egg situation as above. Personally, I think OpenStack Neutron 
should allow mechanisms that are of interest / value to the networking 
community at large, to “ experiment with the abstraction” as you stated, 
independent of other organizations/projects…

SOOO, is the bottom line that we agree that supporting NSH explicitly in 
networking-sfc can be added now?


Thx

Uri (“Oo-Ree”)
C: 949-378-7568

From: Armando M. [mailto:arma...@gmail.com]
Sent: Friday, May 13, 2016 5:14 PM
To: Cathy Zhang mailto:cathy.h.zh...@huawei.com>>
Cc: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC



On 13 May 2016 at 16:01, Cathy Zhang 
mailto:cathy.h.zh...@huawei.com>> wrote:
Hi Uri,

Current networking-sfc API allows the user to specify the data path SFC 
encapsulation mechanism and NSH could be one of the encapsulation options.
But since OVS release has not supported the NSH yet, we have to wait until  NSH 
is added into OVS and then start to support the NSH encapsulation mechanism in 
the data path.

One can support NSH whichever way they see fit. NSH in OVS is not something 
Neutron can do anything about. Neutron is about defining abstractions that can 
apply to a variety of technologies and experiment with what open source 
component is available on the shelves. Anyone can take the abstraction and 
deliver whatever technology stack they want with it and we'd happily gather any 
feedback to iterate on the abstraction to address more and more use case.


AFAIK, it is the position of Neutron to have any OVS related new features 
developed inside the OVS community.

Thanks,
Cathy

From: Elzur, Uri [mailto:uri.el...@intel.com]
Sent: Friday, May 13, 2016 3:02 PM
To: OpenStack Development Mailing List (not for usage questions); Armando M
Subject: [openstack-dev] [Neutron] support of NSH in networking-SFC

Hi Armando

As an industry we are working on SFC for 3 years or so (more?). Still to date, 
we are told 

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

[Henry Gessau]

+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 reviews (3rd place in the top); kilo: 16
> reviews.
> 
> Brian helped the project with stabilizing liberty neutron/DVR jobs, and
> with other L3 related stable matters. In his stable reviews, he shows
> attention to details.
> 
> If Brian is added to the team, I will make sure he is aware of all stable
> policy intricacies.
> 
> Side note: recently I added another person to the team (Cedric Brandilly),
> and now I realize that I haven’t followed the usual approval process. That
> said, the person also has decent stable review stats, and is aware of the
> policy. If someone has doubts about that addition to the team, please ping
> me and we will discuss how to proceed.
> 
> Ihar


__
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] [keystone][api][v3]

[Henry Nash]

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  wrote:
> 
> Hi
> 
> This depends on the policy rule for the get_user call - which is defined by 
> your policy.json file for your keystone. In the default one supplied you need 
> admin to do this, unlike change password where the owner (I.e. A user with an 
> uncooked token) can execute. You could change my the  rule 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  wrote:
>> 
>> HI 
>> is there any way to retrieve default_project_id of login user from unscoped 
>> token ?
>> as I know I  able to retrieve all projects which user can access but I can't 
>> tell  which one is user default project.
>> 
>> Many thanks in advance.
>> __
>> 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 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] [keystone][api][v3]

[Henry Nash]

Hi

This depends on the policy rule for the get_user call - which is defined by 
your policy.json file for your keystone. In the default one supplied you need 
admin to do this, unlike change password where the owner (I.e. A user with an 
uncooked token) can execute. You could change my the  rule 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  wrote:
> 
> HI 
> is there any way to retrieve default_project_id of login user from unscoped 
> token ?
> as I know I  able to retrieve all projects which user can access but I can't 
> tell  which one is user default project.
> 
> Many thanks in advance.
> __
> 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] [all] summit session recap - getting API Docs off WADL and into RST

[Henry Gessau]

Sean Dague  wrote:
> Part of the cross project session track -
> https://etherpad.openstack.org/p/newton-api-docs-rst
> 
> The first half of the session was spent going over the background issues
> and the work so far. The TL;DR
> 
> * We need to get off WADL, it's a dead spec, and it's use is inhibiting
> contributions
> * We *need* to get up to date docs to our users, ASAP. The API
> References are way out of data and inaccurate in most places (and
> missing entirely for 50% of our projects with REST APIs)
> * Swagger (OpenAPI) was looked at, but there are hard problems in our
> legacy APIs that aren't possible to solve within the spec at hand
> * Nova team started building some semistructured tooling based on RST /
> Sphinx to move forward.
> 
> We then looked at the sphinx extension work in the Nova api-ref tree.
> 
> Question: why not https://pythonhosted.org/sphinxcontrib-httpdomain/?
> Answer: we have some specific needs on formating, headers where it
> doesn't fit (see etherpad for full answer).
> 
> Next Steps:
> 
> * Nova team is doing a doc sprint to try to get through verification of
> the content we've got
> * Once that is done (under control) sdague to work on splitting out
> sphinx extension into a dedicated project to make it easy for others to
> consume / contribute
> * Cinder, Ironic, and Keystone ready to get started on similar conversion

Neutron too. Akihiro Motoki and I are the contacts.

Thanks for this initiative. With the focus on RST we will have many more
developers contributing to docs, I am sure.


__
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] Easing contributions to central documentation

[Henry Gessau]

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 the documentation to RST, the most common complaint at the
> recent summit involves the review process, particularly the lengthy amount of
> time patches sit in the review queue with -1s for various "conventions"
> problems such as structure, formatting, grammar, spelling, etc. Unlike most
> OpenStack developers that focus on a particular project, the documentation
> team covers all projects and lacks the capacity to understand each one enough
> to contribute and maintain technically accurate documentation in a timely
> manner. However, covering all projects enables the documentation team to
> organize and present the documentation to various audiences, primarily
> operators and users, that consume OpenStack as a coherent product. In other
> words, the entire process relies on developers contributing to the central
> documentation. So, before developer frustrations drive some or all projects to
> move their documentation in-tree which which negatively impacts the goal of
> presenting a coherent product, I suggest establishing an agreement between
> developers and the documentation team regarding the review process. 
> 
> As much as the documentation team wants to present OpenStack as a coherent
> product, it contains many projects with different contribution processes. In
> some cases, individual developers prefer to contribute in unique ways. Thus,
> the conventional "one-size-fits-all" approach that the documentation team
> historically takes with reviewing contributions from developers yields various
> levels of frustration among projects and developers. I ran a potential
> solution by various developers during the recent summit and received enough
> positive feedback to discuss it with a larger audience. So, here goes...
> 
> A project or individual developer decides the level of documentation team
> involvement with reviewing patches. The developer adds a WIP to the
> documentation patch while adding content to prevent premature reviews by the
> documentation team. Once the content achieves a sufficient level of technical
> accuracy, the developer removes the WIP and adds a comment in the review
> indicating of the following preferences:
> 
> 1) The documentation team should review the patch for compliance with
> conventions (proper structure, format, grammar, spelling, etc.) and provide
> feedback to the developer who updates the patch.
> 2) The documentation team should modify the patch to make it compliant and ask
> the developer for a final review to prior to merging it.
> 3) The documentation team should only modify the patch to make it build (if
> necessary) and quickly merge it with a documentation bug to resolve any
> compliance problems in a future patch by the documentation team.
> 
> What do you think?

I think this is fantastic and I particularly like option (2).

Thanks for this initiative.



__
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] neutron-lib report from the summit

[Henry Gessau]

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 using it now.

Only the very obvious and easy items have been added to neutron-lib:
  - Common constants
  - Common exceptions
  - Attribute converters and validators
  - Common hacking checks, including one to aid decoupling (N530)

Adding database and DB model support

We are leaning towards a common pattern for interacting with neutron resources
using oslo versioned objects (OVOs). The OVO work in neutron core needs to
mature a bit before we start moving it to neutron-lib.

Some basic DB utility methods will be added to allow sub-projects to add and
update their own tables.

Architecture decisions
--
  - Should there be more than one library, with smaller pieces?
  - Decide what is useful before just trying to do  everything.
  - Decide on Callbacks: OVO integration, or something else?
  - OVOs are new in neutron core, which means they are inherently unstable
(undergoing changes) and buggy. The goal is for neutron-lib to contain
stable and proven code, yet OVOs are permeating many of the things we
want in neutron-lib. How do we reconcile this?

Documentation
-
We need to write API documentation. Contributions are welcome.
We need to expand the devref with details on how to use the lib, how to add
things, how to work on dependent code without being blocked, etc.

Work planned for Newton (and beyond)
---
  - DB common utils (for operations not requiring OVO)
  - DB common framework with OVO integration
  - DB alembic migration interface
  - RPC common framework and utilities
  - Finalize Callbacks
  - Context support
  - Policy support
  - Config support, on top of oslo.config?
  - Agent common utils/framework?
  - Extensions common utils/framework?

We should try to determine the priority of these planned items.

We should have a Release Cadence strategy. We can decide on publishing a
release at each weekly meeting, or have a regular cadence, or have a process
similar to oslo libraries.


__
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] [networking-sfc] Network-sfc project f2f2 meet-up place and time

[Henry Fourie]

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: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project 
f2f2 meet-up place and time

On 4/26/2016 00:35, Akihiro Motoki wrote:
> Hi Cathy and folks interested in SFC and classifers!
>
> Can't we use a different room like Salon D?
> Salon C is a lunch room and at that time there are no sessions in other rooms.
> It would be great if we can use Salon D or E (after looking at the 
> first day's session) I think we can gather more easily and concentrate 
> the discussion if we use some different space.
> Thought?
>

Akihiro,

Unless I've misunderstood the emails, the plan for Tuesday is a social lunch 
for the SFC team to get together. The plan for Wednesday is a working lunch to 
discuss flow classifiers in various projects and figure out how to converge on 
a single flow classifier API/model that can be shared by everything that needs 
to specify flows.

If that's correct, then meeting in Salon C for lunch on Tuesday makes sense. 
For Wednesday we probably ought to grab boxed lunches and find a quiet room.


__
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] [neutron] OSC transition

[Henry Gessau]

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:
http://lists.openstack.org/pipermail/openstack-dev/2016-April/093139.html
https://review.openstack.org/309587


Na Zhu  wrote:
> Dear All,
> 
> 
> I have a question about OSC transition, recently, the community approves
> moving bgp out of neutron, as a service like other *aas. The BGP CLIs need be
> removed from neutronclient. Because of OSC transition, I can not just move the
> BGP CLIs code from python-neutronclient repo to neutron-dynamic-routing repo.
> I have to refactor the code and do transition to OSC plugin system.
>  
> From the
> link 
> _http://docs.openstack.org/developer/python-openstackclient/plugins.html_, the
> client has a separate repo, take designate as example, the CLI repo is
> python-designateclient, the project repo is designate. So for BGP, should I
> create a repo for CLI, or leverage project repo neutron-dynamic-routing?
> 
> 
> 
> 
> Regards,
> Juno Zhu
> IBM China Development Labs (CDL) Cloud IaaS Lab
> Email: na...@cn.ibm.com
> 5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New
> District, Shanghai, China (201203)
> 
> 
> __
> 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] [Neutron] Neutron lib hack has broken all decomposed projects

[Henry Gessau]

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 , and is working its
> way through CI now.  About to lose connectivity for my flight to the summit…
>
> doug
>
>
>> On Apr 24, 2016, at 9:24 AM, Doug Wiegley > > wrote:
>>
>> Reverted the neutron change that started using this, which is the quickest
>> path to unbreaking the children. We’ll have to unwind those child projects
>> first.
>>
>> doug
>>
>>
>>> On Apr 24, 2016, at 8:09 AM, Gary Kotton >> > wrote:
>>>
>>> Another example is Lbaas - https://review.openstack.org/#/c/309766/
>>>
>>> I have posted https://review.openstack.org/309770
>>>
>>> Its either that or we skip the current neutron-lib in the requirements file.
>>>
>>> Neutron lib cores please look ASAP as the whole community is kind of stuck
>>> at the moment…
>>>
>>> From: Gary Kotton mailto:gkot...@vmware.com>>
>>> Reply-To: OpenStack List >> >
>>> Date: Sunday, April 24, 2016 at 4:48 PM
>>> To: OpenStack List >> >
>>> Subject: [openstack-dev] [Neutron] Neutron lib hack has broken all
>>> decomposed projects
>>>
>>> Hi,
>>> Commit 4b17f1da1a5f65f0c4db395034ed732174a19315 has broken the pep8 of all
>>> of the decomposed projects.
>>> Do we need this hacking check? Can we have it reverted
>>> An example of this is - 
>>> OVN
>>> - 
>>> http://logs.openstack.org/35/299835/3/check/gate-networking-ovn-pep8/3ad066e/console.html
>>> Thanks
>>> Gary
>>> __
>>> 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 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] [keystone] Newton midycle planning

[Henry Nash]

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  wrote:
> 
> On Wed, Apr 13, 2016 at 9:07 PM, Morgan Fainberg  <mailto:morgan.fainb...@gmail.com>> wrote:
> It is that time again, the time to plan the Keystone midcycle! Looking at the 
> schedule [1] for Newton, the weeks that make the most sense look to be (not 
> in preferential order):
> 
> R-14 June 27-01
> R-12 July 11-15
> R-11 July 18-22
> 
> They all work equally well for me at this point, but I'd be interested to try 
> one of the earlier options.
>  
> 
> As usual this will be a 3 day event (probably Wed, Thurs, Fri), and based on 
> previous attendance we can expect ~30 people to attend. Based upon all the 
> information (other midcycles, other events, the US July4th holiday), I am 
> thinking that week R-12 (the week of the newton-2 milestone) would be the 
> best offering. Weeks before or after these three tend to push too close to 
> the summit or too far into the development cycle.
> 
> I am trying to arrange for a venue in the Bay Area (most likely will be South 
> Bay, such as Mountain View, Sunnyvale, Palo Alto, San Jose) since we have 
> done east coast and central over the last few midcycles.
> 
> Please let me know your thoughts / preferences. In summary:
> 
> * Venue will be Bay Area (more info to come soon)
> 
> * Options of weeks (in general subjective order of preference): R-12, R-11, 
> R-14
> 
> Cheers,
> --Morgan
> 
> [1] http://releases.openstack.org/newton/schedule.html 
> <http://releases.openstack.org/newton/schedule.html>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> <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 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] Proposing Hirofumi Ichihara to Neutron Core Reviewer Team

[Henry Gessau]

+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 has been contributing neutron actively in the recent two
> releases constantly.
> He was involved in key features in API/DB areas in Mitaka such as
> tagging support and network availability zones.
> I believe his knowledge and involvement will be great addition to our team.
> He have been reviewing constantly [1] and I expect he continue to work
> for Newton or later.
> 
> Existing API/DB core reviews (and other Neutron core reviewers),
> please vote +1/-1 for the addition of Hirofumi to the team.
> 
> Thanks!
> Akihiro
> 
> 
> [1] http://stackalytics.com/report/contribution/neutron/90


__
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] unit test failures due to new release of Routes package (v2.3)

[Henry Gessau]

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: http://paste.openstack.org/show/492384/
> 
> I update the requirements.txt to use 'Routes<2.0,>=1.12.3' and all the tests
> work fine.
> I see there was a new release (v2.3 ) of Routes on 28th March 2016 [1], which
> seems to have caused the issue, specifically:
>  - Concatenation fix when using submappers with path prefixes. Multiple
> submappers combined the path prefix inside the controller argument in
> non-obvious ways. The controller argument will now be properly carried through
> when using submappers. PR #28[2].
> 
> Is anyone else noticing the test failures?
> Should I submit this requirements.txt change as a patch or should we pass the
> required two args as the patch? I can do the requirement.txt change. For the
> latter, somebody who knows what goes on in the extensions.py __init__() should
> take a look.
> 
> I assume this will also affect the stable branches, since the Routes package
> versin in requirements.txt in previous versions was same as in master.
> 
> --
> Aditya
> [1] 
> https://routes.readthedocs.org/en/latest/changes.html#release-2-3-march-28-2016
> [2] 
> https://github.com/bbangert/routes/pull/28/files?diff=unified#diff-b54de741c3f86d76eb4bce4a223054aaL154



__
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